From xliu at openjdk.org  Sat Apr  1 00:47:23 2023
From: xliu at openjdk.org (Xin Liu)
Date: Sat, 1 Apr 2023 00:47:23 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <V50O8_kFBuE3U46ga88HINRP59Pk_IJKCLAf9DAEDEY=.520967d8-41b8-43d8-a196-5f90815fd77b@github.com>

On Thu, 30 Mar 2023 23:36:20 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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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 feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/escape.cpp line 639:

> 637:     call->add_req(selector);
> 638: 
> 639:     for (uint i = 1; i < ophi->req(); i++) {

Comparing to new_phi and selector, I think this is the heavy-lifting work. You "replace" all appearances of ptn with SPSO. This logic almost overlaps the 'scalar replacement' part in MacroExpand. 

Do you consider to perform the transformation in MacroExpand? Your prior changes have already removed NSR marks, ME/SR will consider 'ptn'.

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

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


From iris at openjdk.org  Sat Apr  1 02:51:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 1 Apr 2023 02:51:21 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]
In-Reply-To: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
Message-ID: <9xeOR9nFP1Pv9OxHLOkbzYTOjIkJxOZnB9M4zKAxJgU=.1d896a82-0139-434b-a6a3-ce4650914727@github.com>

On Fri, 31 Mar 2023 22:07:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert removing @see tags where the URL was not the same as the @spec URL

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367798667


From jjg at openjdk.org  Tue Apr  4 00:13:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Apr 2023 00:13:20 GMT
Subject: Integrated: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <cU6-hY-ZFAn7XQ83SgGaTT-BsgqIhTus_Sj-XdFSzPE=.21e82408-ae57-4f06-9e51-cebd10d1efa5@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

This pull request has now been integrated.

Changeset: c6bd489c
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6bd489cc8d30fb6eec865b3dab1cf861e25c8d7
Stats:     270 lines in 60 files changed: 268 ins; 2 del; 0 mod

8305206: Add @spec tags in java.base/java.* (part 1)

Reviewed-by: alanb, naoto, darcy, lancea, dfuchs, iris, mchung

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

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


From alanb at openjdk.org  Tue Apr  4 18:23:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:23:10 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <Gdwpun5rMVvm5SiUmgJ7ZIp3Kw6jUr3Ig90saDGXjKE=.56390924-d388-4daa-9ff9-c9d37d9f83fe@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1371541522


From duke at openjdk.org  Tue Apr  4 18:26:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 18:26:32 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not sure what to put in the _Specification_ section.

What is the specification change in this PR? The removal of the system property?  The adding of the warning?

I'm not seeing any API change as is probably more usual in a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496409539


From alanb at openjdk.org  Tue Apr  4 18:40:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:40:10 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
Message-ID: <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>

On Tue, 4 Apr 2023 18:23:23 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not sure what to put in the _Specification_ section.
> 
> What is the specification change in this PR? The removal of the system property? The adding of the warning?
> 
> I'm not seeing any API change as is probably more usual in a CSR.

I've edited it to add a Specification section with a summary of the changes to the JAR file spec. I also update the Solution section so that it provides a clearer summary of the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496428340


From lancea at openjdk.org  Tue Apr  4 18:44:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 18:44:09 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <bqQehzFMChYg_62qsxy4iEIEaYRIifH54GsE9cKcZDE=.4eb574d6-2fbd-4a62-879a-f2bf195348b4@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1371573197


From lancea at openjdk.org  Tue Apr  4 18:44:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 18:44:09 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
Message-ID: <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>

On Tue, 4 Apr 2023 18:37:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not sure what to put in the _Specification_ section.
> > What is the specification change in this PR? The removal of the system property? The adding of the warning?
> > I'm not seeing any API change as is probably more usual in a CSR.
> 
> I've edited it to add a Specification section with a summary of the changes to the JAR file spec. I also update the Solution section so that it provides a clearer summary of the changes.

I also updated the CSR with the revised JAR File Spec.   I will look over the changes and add myself as a reviewer

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496431151


From duke at openjdk.org  Tue Apr  4 18:44:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 18:44:10 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
 <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
Message-ID: <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>

On Tue, 4 Apr 2023 18:39:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I've edited it to add a Specification section with a summary of the changes to the JAR file spec. I also update the Solution section so that it provides a clearer summary of the changes.

Thanks a lot Alan, as this CSR has deeper waters than what I've experienced before. Did you intend to remove the line break in the example warning output, collapsing it into one line?

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496433027


From mchung at openjdk.org  Tue Apr  4 18:57:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Apr 2023 18:57:13 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <ja2RXqUfQfIE8BxHS4JtWakApCh2IS4-UoYrkXdk5AI=.900e0c4e-5838-4bd2-b596-15af5175e94b@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

LGTM

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1371596288


From duke at openjdk.org  Tue Apr  4 19:03:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 4 Apr 2023 19:03:16 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <nMjoazgMm0rBkvpvLF4xee7WqnsoZ-cbaeibb_zBF14=.4c962b19-3b1c-49de-8895-e558a26c2140@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

I added a draft release note https://bugs.openjdk.org/browse/JDK-8305603 as a sub-task of this PR's issue https://bugs.openjdk.org/browse/JDK-8303410

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496455323


From rriggs at openjdk.org  Tue Apr  4 19:31:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:31:02 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
Message-ID: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>

With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
This PR exports jdk.internal.util to:
 - java.prefs,
 - java.security.jgss,
 - java.smartcardio,
 - jdk.charsets,
 - jdk.net,
 - jdk.zipfs

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

Commit messages:
 - In jdk.prefs module, Replace os.name with OperatingSystem enum
 - Use OperatingSystem methods instead of system property os.name

Changes: https://git.openjdk.org/jdk/pull/13335/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304911
  Stats: 131 lines in 13 files changed: 24 ins; 54 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13335/head:pull/13335

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


From jjg at openjdk.org  Tue Apr  4 19:55:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Apr 2023 19:55:14 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2)
Message-ID: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>

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)

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

Commit messages:
 - JDK-8305406: Add @spec tags in java.base/java.* (part 2)

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

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


From naoto at openjdk.org  Tue Apr  4 20:46:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:46:08 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <PLVQO12D6OpNUM1D631lpeCa-XG2ppj8-yFutinjzo4=.8419be80-c474-4f80-b348-9248b49f12fc@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371756979


From lancea at openjdk.org  Tue Apr  4 20:54:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 20:54:09 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <jmYozHgCwkNFcK_M5EWxKGZ9iHABZ-RdMAOeDjBGNGk=.348c92c5-fb19-410f-9991-d7ab772ac914@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

The changes look good

Please add a Noreg-XXX label to the bug

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371768336


From iris at openjdk.org  Tue Apr  4 21:00:10 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Apr 2023 21:00:10 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <w--1bkwl6V1e7G7aGwcv4NlboudQn_noNPCyD03SAYM=.0c98f3d4-d4a1-43ca-b239-20d6658172a5@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371776265


From duke at openjdk.org  Wed Apr  5 05:11:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 05:11:08 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <aQYAwMrrJcqk4ATxMUuvnQswH8AxHgye4L34iE3UTG4=.5c1f5324-846f-4833-8828-16b3c6067a46@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 105:

> 103:                                 case WINDOWS -> // Full path needed, DLL is in jre/bin
> 104:                                         new String[]{StaticProperty.javaHome()
> 105:                                                 + "\\bin\\sspi_bridge.dll"};

Suggestion:

                                        new String[]{ StaticProperty.javaHome()
                                                + "\\bin\\sspi_bridge.dll" };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158027900


From jpai at openjdk.org  Wed Apr  5 05:56:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Apr 2023 05:56:11 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

Hello Eirik, the changes look good to me. The new test that was planned for testing `JarFile` and `JarInputStream` when dealing with a jar containing a `META-INF/INDEX.LIST`, is that something that you want to be done as a separate PR/task? It's fine with me if you want that to be done separately.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1372196049


From alanb at openjdk.org  Wed Apr  5 06:15:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 06:15:09 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
 <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
 <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>
Message-ID: <91azLVsPgSYLoqX_EK98jo4GsWmOsCJjza85IWcuADc=.1a99ec85-6e54-4ae4-babe-eb6a00648613@github.com>

On Tue, 4 Apr 2023 18:41:31 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Thanks a lot Alan, as this CSR has deeper waters than what I've experienced before. Did you intend to remove the line break in the example warning output, collapsing it into one line?

I used the inline code formatting (3 backquotes) to make the output clear, but maybe it looks differently for you or maybe your comment was while I was editing? When you are ready, press "Finalize" and that will put in the CSR queue to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496970170


From duke at openjdk.org  Wed Apr  5 06:22:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 5 Apr 2023 06:22:11 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <91azLVsPgSYLoqX_EK98jo4GsWmOsCJjza85IWcuADc=.1a99ec85-6e54-4ae4-babe-eb6a00648613@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <o5oNiRz3KGL0IbapIeg20m5hTsg5AOADbz4v4OWjZTE=.08034e35-9a39-4af4-92bb-b57619b6bf2d@github.com>
 <uhG3aN9jIAmxDtQkGhtsjLGrmlz1FEk-INV3fMyQsUI=.36aa06d2-dc7c-4991-9c89-5d993d762b51@github.com>
 <wyWIQkFXtsQNfrsiwREd8p_m7WY5o8V8iqsSQ-0NFEk=.bc25b747-8f1e-44e8-91d6-3b98fc9431f7@github.com>
 <oFyQWvpvV4xyeR2-FMdEUd2e6gBm9ENX_d60DrXJE14=.ce8bb9c1-d80e-47b6-98ba-950fe1c159bf@github.com>
 <91azLVsPgSYLoqX_EK98jo4GsWmOsCJjza85IWcuADc=.1a99ec85-6e54-4ae4-babe-eb6a00648613@github.com>
Message-ID: <KdAVX73Iq-4-DtzRq-DkyTJmlG3KDeCA5rYMtYkjRpc=.d49565d9-7947-47c3-bc30-d918d19133de@github.com>

On Wed, 5 Apr 2023 06:12:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I used the inline code formatting (3 backquotes) to make the output clear, but maybe it looks differently for you or maybe your comment was while I was editing? 

It looks good now, so my comment was probably made during your edits.

> When you are ready, press "Finalize" and that will put in the CSR queue to review.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1496975708


From duke at openjdk.org  Wed Apr  5 07:08:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 5 Apr 2023 07:08:11 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
Message-ID: <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>

On Wed, 5 Apr 2023 05:53:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The new test that was planned for testing `JarFile` and `JarInputStream` when dealing with a jar containing a `META-INF/INDEX.LIST`, is that something that you want to be done as a separate PR/task? It's fine with me if you want that to be done separately.

@jaikiran 

I was looking into creating such a test yesterday. For `JarInputStream`, I was able to write a tests which expects a certain order of entries. This could made broken by disabling the `META-INF/INDEX.LIST` check in `JarInputStream.getNextEntry`.

With `JarVerifier`, I'm struggling to create a scenario which excercises the `META-INF/INDEX.LIST` check. It seems to me this code is simply unreachable, even after moving the `META-INF/INDEX.LIST` file first in the JAR.

If the code is properly unreachable, then maybe we should consider removing it?

In any case, since I feel the current test is somewhat dubious, I checked it into another branch here:

https://github.com/eirbjo/jdk/blob/remove-jar-index-test/test/jdk/java/util/jar/JarFile/JarIndexLegacyJars.java

This is perhaps better than having no tests. I'm not feeling sure about this, please let me know what you think. Perhaps @AlanBateman also has an opinion on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1497017466


From alanb at openjdk.org  Wed Apr  5 08:42:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 08:42:16 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:

> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
> 406:                 default -> new PlatformSocketOptions();

For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:

> 2880:                     elenNTFS = 36;           // total 36 bytes
> 2881:                 } else {                     // Extended Timestamp otherwise
> 2882:                     elenEXTT = 9;            // only mtime in cen

It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158209156
PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158206710


From lancea at openjdk.org  Wed Apr  5 10:28:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 5 Apr 2023 10:28:20 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
 <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>
Message-ID: <amSmQvZ0xqhJvib4GKRW6bvPHLkrFS1jAJ-VICULtA0=.5d1063fa-78da-459b-adec-7d602a239a5e@github.com>

On Wed, 5 Apr 2023 07:05:11 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > The new test that was planned for testing `JarFile` and `JarInputStream` when dealing with a jar containing a `META-INF/INDEX.LIST`, is that something that you want to be done as a separate PR/task? It's fine with me if you want that to be done separately.
> 
> @jaikiran
> 
> I was looking into creating such a test yesterday. For `JarInputStream`, I was able to write a tests which expects a certain order of entries. This could made broken by disabling the `META-INF/INDEX.LIST` check in `JarInputStream.getNextEntry`.
> 
> With `JarVerifier`, I'm struggling to create a scenario which excercises the `META-INF/INDEX.LIST` check. It seems to me this code is simply unreachable, even after moving the `META-INF/INDEX.LIST` file first in the JAR.
> 
> If the code is properly unreachable, then maybe we should consider removing it?
> 
> In any case, since I feel the current test is somewhat dubious, I checked it into another branch here:
> 
> https://github.com/eirbjo/jdk/blob/remove-jar-index-test/test/jdk/java/util/jar/JarFile/JarIndexLegacyJars.java
> 
> This is perhaps better than having no tests. I'm not feeling sure about this, please let me know what you think. Perhaps @AlanBateman also has an opinion on this?

I am not convinced we need a test but to your point Jai, Eirik, lets handle this as a separate PR/Issue and work through what we are hoping to achieve/validate

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1497259301


From duke at openjdk.org  Wed Apr  5 11:09:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 5 Apr 2023 11:09:18 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <amSmQvZ0xqhJvib4GKRW6bvPHLkrFS1jAJ-VICULtA0=.5d1063fa-78da-459b-adec-7d602a239a5e@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <bhwfEvvgT8rIUjF9EvPW6Ok3rVxijYadSJ8MaPE6tPE=.0d01c912-7f87-4d9a-98ac-ef7f155cec9b@github.com>
 <NGmHVOi3lHnU_rT5YpeoV-fpTN6QMhsGVXSmNvU6cHQ=.67c55b1f-349a-4626-902e-9069ff7c60bc@github.com>
 <amSmQvZ0xqhJvib4GKRW6bvPHLkrFS1jAJ-VICULtA0=.5d1063fa-78da-459b-adec-7d602a239a5e@github.com>
Message-ID: <qpuVT0Ad52mJlpqnttoqUyehD78j7XBAq2FgcNMh8KY=.4d231f3d-cabf-43db-9d69-994424fe1292@github.com>

On Wed, 5 Apr 2023 10:25:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I am not convinced we need a test but to your point Jai, Eirik, lets handle this as a separate PR/Issue and work through what we are hoping to achieve/validate

Good. Let's agree to handle testing of dusty 'index jars' separately from this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1497307096


From rriggs at openjdk.org  Wed Apr  5 14:11:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:11:18 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <F8Jr6kezM5OXPwzssO4GuD_FFHdkruuTw955hwPJ9Kc=.fb2ede42-7b0d-4221-9c87-bfa0df005123@github.com>

On Wed, 5 Apr 2023 08:39:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:
> 
>> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
>> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
>> 406:                 default -> new PlatformSocketOptions();
> 
> For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

Created an issue to track the possible refactoring, will keep this change until then.
https://bugs.openjdk.org/browse/JDK-8305661

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158574021


From rriggs at openjdk.org  Wed Apr  5 14:22:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:22:29 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>

On Wed, 5 Apr 2023 08:37:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:
> 
>> 2880:                     elenNTFS = 36;           // total 36 bytes
>> 2881:                 } else {                     // Extended Timestamp otherwise
>> 2882:                     elenEXTT = 9;            // only mtime in cen
> 
> It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp. It shouldn't be looking at the current OS name.

Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
Will revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158587949


From rriggs at openjdk.org  Wed Apr  5 14:32:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:32:03 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert chanes to ZipFileSystem to defer refactoring.
  Reformatted expression to match switch expression formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/72cff1ed..aadf5bbd

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

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

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


From alanb at openjdk.org  Wed Apr  5 14:36:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 14:36:16 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
 <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
Message-ID: <hoTsG4Le90HdJbdN-yAOFAYCjwwLn4avbyJBS6VViR8=.7e769d74-a829-4621-8229-8722dc7c50df@github.com>

On Wed, 5 Apr 2023 14:18:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
> Will revert.

Thanks, you can revert the qualified export in module-info and the additional grant in default.policy too.

The interesting thing about this PR is that each change begs the question on whether the code should be refactored, that would take time of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158609098


From duke at openjdk.org  Wed Apr  5 14:45:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 14:45:15 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
Message-ID: <Osp9DN7X8Ep5PtaZ0V8E7kf3vDZRpxHnrsKmj4NAjPg=.e2fadf20-cd2e-4596-a78d-73e75af04eab@github.com>

On Wed, 5 Apr 2023 14:32:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert chanes to ZipFileSystem to defer refactoring.
>   Reformatted expression to match switch expression formatting.

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 103:

> 101:                                         "/usr/lib/sasl2/libgssapiv2.2.so",
> 102:                                 };
> 103:                                 case WINDOWS -> new String[]{ // Full path needed, DLL is in jre/bin

Suggestion:

                                case WINDOWS -> new String[]{
                                        // Full path needed, DLL is in jre/bin

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158620967


From djelinski at openjdk.org  Wed Apr  5 15:31:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 15:31:08 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2)
In-Reply-To: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
Message-ID: <5LdxHbFCjmNDv-s9An5F63Cx8uux01flNCe8a2pb1Iw=.03f0fae6-e8d0-40af-aea1-2698c543fde2@github.com>

On Tue, 4 Apr 2023 19:46:32 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)

Marked as reviewed by djelinski (Reviewer).

src/java.base/share/classes/java/security/Key.java line 91:

> 89:  * @spec serialization/index.html Java Object Serialization Specification
> 90:  * @spec https://www.rfc-editor.org/info/rfc5280
> 91:  *        RFC 5280: Internet X.509 Public Key Infrastructure Certificate

any reason why you indented this comment with 8 spaces? All others are indented with 6

src/java.base/share/classes/java/security/cert/X509Certificate.java line 630:

> 628:      *              UTF-8 String Representation of Distinguished Names
> 629:      * @spec https://www.rfc-editor.org/info/rfc822
> 630:      *      RFC 822:: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

Suggestion:

     *      RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

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

PR Review: https://git.openjdk.org/jdk/pull/13336#pullrequestreview-1373161162
PR Review Comment: https://git.openjdk.org/jdk/pull/13336#discussion_r1158675317
PR Review Comment: https://git.openjdk.org/jdk/pull/13336#discussion_r1158672811


From rriggs at openjdk.org  Wed Apr  5 15:48:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 15:48:02 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Backout unneeded changes to module-info and default.policy.
  Fixup formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/aadf5bbd..5546b824

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

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

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


From cslucas at openjdk.org  Wed Apr  5 15:52:29 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:29 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v6]
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: <Y2dszixURaihwUBOuiZtOk1vipdNDa0Jbc3DRg3sByk=.356a316c-1ff2-4643-b682-442d804cee1b@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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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:

  Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/5ef86371..3752b21a

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

  Stats: 346 lines in 3 files changed: 113 ins; 106 del; 127 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  Wed Apr  5 15:52:33 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:33 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
Message-ID: <JKbVwv0oELA5K17J6ImKo2k2Dd3I2GXrBJzNNU9rQmQ=.a35b4f4e-fd1f-46e8-9b36-182e2d6f3fc0@github.com>

On Fri, 24 Mar 2023 19:02:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/code/debugInfo.hpp line 199:
> 
>> 197: // ObjectValue describing an object that was scalar replaced.
>> 198: 
>> 199: class ObjectMergeValue: public ScopeValue {
> 
> Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts.

Hi @vnkozlov, just FYI. I made the changes that you suggested. Please let me know what you think.

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

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


From cslucas at openjdk.org  Wed Apr  5 15:52:34 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:34 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <gu_ZHFRO-SoFPxYgt-NDukPxS894AwlZQqDPjcRCwl4=.d0b5473e-83f8-42a9-ae38-bed52780fe58@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>
 <gu_ZHFRO-SoFPxYgt-NDukPxS894AwlZQqDPjcRCwl4=.d0b5473e-83f8-42a9-ae38-bed52780fe58@github.com>
Message-ID: <RR4LYjGsrkBqJKjiwo26FgDr1kK8JqWPnSbY-q7vDt4=.3000ed8f-042f-4881-ab92-8a364e6cb9ea@github.com>

On Sat, 25 Mar 2023 00:07:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes.
>
> It **will** complicate your DebugInfo code (packing/unpacking) information. But I think it is right thing to do to avoid duplicated re-allocations during deoptimization - you should have only one new object.

Hi @vnkozlov, just FYI. I made the changes that you suggested.

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

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


From cslucas at openjdk.org  Wed Apr  5 15:52:37 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:37 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <V50O8_kFBuE3U46ga88HINRP59Pk_IJKCLAf9DAEDEY=.520967d8-41b8-43d8-a196-5f90815fd77b@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <V50O8_kFBuE3U46ga88HINRP59Pk_IJKCLAf9DAEDEY=.520967d8-41b8-43d8-a196-5f90815fd77b@github.com>
Message-ID: <iDlOaKGYAcBWTckprRpZHs-zhfplHyLcAYtRSU5cvqM=.96cddad3-f1d1-456b-9292-8b2f8990a329@github.com>

On Sat, 1 Apr 2023 00:44:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Do you consider to perform the transformation in MacroExpand? Your prior changes have already removed NSR marks, ME/SR will consider 'ptn'.

Yes, I actually did. However, that makes the changes much more complicated.

I patched this method to reuse the scalar replacement method in MacroExpand so that we don't have code duplication. I hope that's sufficient as a first implementation.

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

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


From cslucas at openjdk.org  Wed Apr  5 15:52:38 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:38 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <mxsldgW-AtEV3etyH7yZ2jx5MXXSyQFiKqzalVYPaYg=.fae3b88a-1f76-4b60-8644-6413a7d8accb@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>
 <mxsldgW-AtEV3etyH7yZ2jx5MXXSyQFiKqzalVYPaYg=.fae3b88a-1f76-4b60-8644-6413a7d8accb@github.com>
Message-ID: <ElnvrbpnCXOvlD7GTwzVtsfGcyc1AlSWop597x80Co8=.2c0d15e2-e7ea-4fb1-b9f5-9f42ba0c18c9@github.com>

On Fri, 31 Mar 2023 18:24:45 GMT, Xin Liu <xliu at openjdk.org> wrote:

> It looks like we can use (safepoints == nullptr) instead?

Yeap. Thanks. I don't know how I missed that.

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

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


From cslucas at openjdk.org  Wed Apr  5 15:52:40 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:40 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <FOUeJrVL0xYrKw3FzYZc8HCSocQ82_Iizd_HthI-W_8=.06b6b235-1412-4e5c-82ee-51893239c2f1@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
 <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>
 <FOUeJrVL0xYrKw3FzYZc8HCSocQ82_Iizd_HthI-W_8=.06b6b235-1412-4e5c-82ee-51893239c2f1@github.com>
Message-ID: <doCEWpNl4O4ggJw0lPd1DhXfPjOhRjoEnmmR9BPJIK4=.89ddda21-775f-4677-9a9e-f324c2627ff5@github.com>

On Fri, 31 Mar 2023 18:38:43 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I see, you use it in escape.cpp. Okay. I need to review changes there too.
>
> or you could construct a temporary PhaseMacroExpand object in EA. 
> 
> I see that you convert many member function to static so you can query in EA. the only blocker is _igvn.

That seems a good idea. Together with some other refactoring I decided to revert making the methods static and instead use them through an instance of ME.

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

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


From cslucas at openjdk.org  Wed Apr  5 15:52:39 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 15:52:39 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <ElnvrbpnCXOvlD7GTwzVtsfGcyc1AlSWop597x80Co8=.2c0d15e2-e7ea-4fb1-b9f5-9f42ba0c18c9@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>
 <mxsldgW-AtEV3etyH7yZ2jx5MXXSyQFiKqzalVYPaYg=.fae3b88a-1f76-4b60-8644-6413a7d8accb@github.com>
 <ElnvrbpnCXOvlD7GTwzVtsfGcyc1AlSWop597x80Co8=.2c0d15e2-e7ea-4fb1-b9f5-9f42ba0c18c9@github.com>
Message-ID: <xCtdOzdEPS8KWUDglCjeKKhFU2-j-opCkmKWdFITTYk=.7fcba691-6d7e-4034-b821-da79df7eccac@github.com>

On Wed, 5 Apr 2023 00:59:29 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Do you really need the boolean parameter ignore_merges here? 
>> It looks like we can use (safepoints == nullptr) instead?
>
>> It looks like we can use (safepoints == nullptr) instead?
> 
> Yeap. Thanks. I don't know how I missed that.

> With ignore_merges, why we also skip EncodeP or MemBarRelease here?

The EncodeP shouldn't prevent the reduction of Phi because I check how the Phi is used.
The MemBarRelease node shouldn't prevent the reduction because once the Allocate input to the Phi is set to SR the MemBarRelease node will be removed as part of Ideal transformations after EA.

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

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


From iris at openjdk.org  Wed Apr  5 16:27:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Apr 2023 16:27:21 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <yNqK4eZqzxXtzGKEYf4MbbAaVHOB0Y785UAn1LuTvcs=.525903c3-871b-48b0-ab80-36917b999098@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1373282111


From cslucas at openjdk.org  Wed Apr  5 16:31:20 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 5 Apr 2023 16:31:20 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v7]
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: <jisueY-iTRpza7F1n2OC1tehHKkzDiJa5bZCUhXyXAg=.43474c8f-3784-464c-8e56-4d18825437c4@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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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 seven commits:

 - 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.
 - Merge master
 - Add support for rematerializing scalar replaced objects participating in allocation merges

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

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=06
  Stats: 2193 lines in 22 files changed: 1939 ins; 107 del; 147 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 jjg at openjdk.org  Wed Apr  5 16:35:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 16:35:15 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v2]
In-Reply-To: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
Message-ID: <k-MCRF38Gk3gvVvDmcOblKUeTvTXLyWDKuOgo39irsA=.5e1ab8d4-17f5-413d-b2ef-ad15826e3d00@github.com>

> 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:

  Update src/java.base/share/classes/java/security/cert/X509Certificate.java
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13336/files
  - new: https://git.openjdk.org/jdk/pull/13336/files/951df1af..2e5425b0

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

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

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


From jjg at openjdk.org  Wed Apr  5 16:35:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 16:35:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v2]
In-Reply-To: <5LdxHbFCjmNDv-s9An5F63Cx8uux01flNCe8a2pb1Iw=.03f0fae6-e8d0-40af-aea1-2698c543fde2@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <5LdxHbFCjmNDv-s9An5F63Cx8uux01flNCe8a2pb1Iw=.03f0fae6-e8d0-40af-aea1-2698c543fde2@github.com>
Message-ID: <dymyZM_lYuS1AXCLD01QqfLVX1wYWs5JWcE82zB1Uto=.fa72ee22-12c8-460b-9bc5-db5dce65fe7d@github.com>

On Wed, 5 Apr 2023 15:23:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/security/cert/X509Certificate.java
>>   
>>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>
> src/java.base/share/classes/java/security/Key.java line 91:
> 
>> 89:  * @spec serialization/index.html Java Object Serialization Specification
>> 90:  * @spec https://www.rfc-editor.org/info/rfc5280
>> 91:  *        RFC 5280: Internet X.509 Public Key Infrastructure Certificate
> 
> any reason why you indented this comment with 8 spaces? All others are indented with 6

I will change it to be consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13336#discussion_r1158755137


From jjg at openjdk.org  Wed Apr  5 16:45:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 16:45:06 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
Message-ID: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13336/files
  - new: https://git.openjdk.org/jdk/pull/13336/files/2e5425b0..03a70694

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

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

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


From djelinski at openjdk.org  Wed Apr  5 18:14:17 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 18:14: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: <LCp0BJA3QyDPxSc-eeOHKjunX1zsjO7msCiqUeiMfq4=.de93de57-7573-41e5-828a-f18072d469fb@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

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13336#pullrequestreview-1373439503


From mullan at openjdk.org  Wed Apr  5 21:30:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Apr 2023 21:30:18 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: <rx1-XyQLo1z1bNP_Ja_ePMwLRXtpOZRv2_Us32haY04=.e83a332d-a9f0-4642-99c2-0c9ed9bd7a82@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

I plan to review this but may need a couple of days.

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

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


From kvn at openjdk.org  Thu Apr  6 04:46:25 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 6 Apr 2023 04:46:25 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v7]
In-Reply-To: <jisueY-iTRpza7F1n2OC1tehHKkzDiJa5bZCUhXyXAg=.43474c8f-3784-464c-8e56-4d18825437c4@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <jisueY-iTRpza7F1n2OC1tehHKkzDiJa5bZCUhXyXAg=.43474c8f-3784-464c-8e56-4d18825437c4@github.com>
Message-ID: <4uPGi8Ulap_QoQpkL1zTZUdP-jdL_WDEkpdP7asLow4=.9047ce21-688f-4d29-a643-f9acfd4344c7@github.com>

On Wed, 5 Apr 2023 16:31:20 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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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 seven commits:
> 
>  - 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.
>  - Merge master
>  - Add support for rematerializing scalar replaced objects participating in allocation merges

Thank you for adding new node - it is more clear now.

src/hotspot/share/opto/callnode.hpp line 540:

> 538: 
> 539:   bool is_only_merge_sr_candidate()           { return _only_merge_sr_candidate; }
> 540:   void set_only_merge_sr_candidate(bool only) { _only_merge_sr_candidate = only; }

May be drop `_sr` from  names. `SafePointScalarObjectNode` already represents scalarized object.

src/hotspot/share/opto/escape.cpp line 633:

> 631: 
> 632:     SafePointScalarMergeNode* smerge = new SafePointScalarMergeNode(merge_t, merge_idx);
> 633:     smerge->init_req(0, _compile->root());

May be use ophi's control here, it should stay bellow merge point. Was there a reason you use `root`?

src/hotspot/share/opto/escape.cpp line 640:

> 638: 
> 639:     // Add the selector so we know which direction the execution took
> 640:     sfpt->add_req(selector);

May be added comment that we adding debug info for merge point here (2 values described in the comment for `_merge_pointer_idx`).

src/hotspot/share/opto/escape.cpp line 655:

> 653:       SafePointScalarObjectNode* sobj = mexp.create_scalarized_object_description(alloc, sfpt);
> 654:       if (sobj == nullptr) {
> 655:         fatal("Failed to create SafePointScalarObjectNode!");

This is brutal!  May be exit this compilation and recompile without `ReduceAllocationMerges`.

src/hotspot/share/opto/escape.cpp line 658:

> 656:       }
> 657: 
> 658:       jvms->set_endoff(sfpt->req());

add comment explaining this line

src/hotspot/share/opto/escape.cpp line 677:

> 675: 
> 676:     // Replaces debug information references to "ophi" in "sfpt" with references to "smerge"
> 677:     int debug_end = jvms->debug_end();

May be add comment that debug info changed (and `debug_end`) due to added scalarized objects info.

src/hotspot/share/opto/escape.cpp line 679:

> 677:     int debug_end = jvms->debug_end();
> 678:     sfpt->replace_edges_in_range(ophi, smerge, debug_start, debug_end, _igvn);
> 679:     sfpt->set_req(smerge->merge_pointer_idx(jvms), ophi);

So you trying to restore `ophi` in debug info which was added at line 637 but then in previous line may be replaced with `smerge`. May add  comment explaining that.

src/hotspot/share/opto/output.cpp line 755:

> 753:       ciKlass* cik = t->is_oopptr()->exact_klass();
> 754:       assert(cik->is_instance_klass() ||
> 755:             cik->is_array_klass(), "Not supported allocation.");

Why spacing changed?

src/hotspot/share/opto/output.cpp line 789:

> 787: 
> 788:       for (uint i = 1; i < smerge->req(); i++) {
> 789:         Node* fld_node = smerge->in(i);

It is not `fld_node` but `obj_node`.

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

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1374000788
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159249159
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159245961
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159246463
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159255417
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159253457
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159256643
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159270793
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159272308
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1159271887


From alanb at openjdk.org  Thu Apr  6 07:35:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Apr 2023 07:35:20 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
Message-ID: <AvcNFdCM6eGAM-NA9yDxTZzE_h5xywb7qZV-ZhohHNc=.0ec40d45-ac53-460e-8df9-d2795add811f@github.com>

On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

One additional thing we could do is update the usage output for -i/--generate-index to say that the option is deprecated. Looking at `jdeps -help` output to see this for the deprecated -P/--profile option.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1498617201


From duke at openjdk.org  Thu Apr  6 17:40:24 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 6 Apr 2023 17:40:24 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts
Message-ID: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>

Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.

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

Commit messages:
 - removed whitespace
 - removed unnecessary code
 - 8182621: JSSE should reject empty TLS plaintexts

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

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


From rhalade at openjdk.org  Thu Apr  6 17:40:25 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 6 Apr 2023 17:40:25 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts
In-Reply-To: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
Message-ID: <--wRzeLHxSSW7AkAp0IlWfDoQ60AO5v1wyU1x3gKozs=.e62671a3-d5d4-458d-a8bf-9f4f257e3fbc@github.com>

On Mon, 3 Apr 2023 18:13:19 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.

Please fix the whitespace errors so the `rfr` label will be added by bots.

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

PR Comment: https://git.openjdk.org/jdk/pull/13306#issuecomment-1499368513


From mullan at openjdk.org  Thu Apr  6 19:34:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Apr 2023 19:34:07 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: <m4udm5H1KKWOFrFHbNbbof-gqipEvFbflX-l7-GTImE=.bf857f4e-b987-4eac-a675-aa5b23878cfb@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

There are references to other specifications missing, like NIST Special Publication 800-90A Revision 1, referenced in `java.security.DrbgParameters`. I think there are others, I haven't done a thorough review yet. Will there be subsequent reviews for these, or should I point them out and have them resolved as part of this PR?

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

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


From xuelei at openjdk.org  Fri Apr  7 02:19:48 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 7 Apr 2023 02:19:48 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts
In-Reply-To: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
Message-ID: <h1_dut4TxoUR_lSrYQpksnvG78YPtL0JupeqCd8TgTk=.40fb1238-dc76-4480-8766-3a553ebf3516@github.com>

On Mon, 3 Apr 2023 18:13:19 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.

src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java line 266:

> 264:         //
> 265:         if (contentType == ContentType.HANDSHAKE.id) {
> 266:             if (!fragment.hasRemaining()) {

It may be easier to read if using "contentLen != 0", instead of "fragment.hasRemaining()".  I may add a comment like what is says in RFC 8446, "Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding."

src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java line 267:

> 265:         if (contentType == ContentType.HANDSHAKE.id) {
> 266:             if (!fragment.hasRemaining()) {
> 267:                 throw new SSLProtocolException("Handshake packets may not be zero-length");

"may not" -> "must not"

src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 287:

> 285:         if (contentType == ContentType.HANDSHAKE.id) {
> 286:             ByteBuffer handshakeFrag = fragment;
> 287:             if (!handshakeFrag.hasRemaining()) {

Same comment as src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13306#discussion_r1160385752
PR Review Comment: https://git.openjdk.org/jdk/pull/13306#discussion_r1160385932
PR Review Comment: https://git.openjdk.org/jdk/pull/13306#discussion_r1160386380


From jpai at openjdk.org  Fri Apr  7 05:59:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 05:59:46 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <P8j4Sb_G26s5EnX3hMY-OkBfW7izQLv1uflhTkdV6sM=.1688b147-9689-4eb1-aebb-9cc0a83b1cd8@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Looks ok to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1375851004


From duke at openjdk.org  Fri Apr  7 07:47:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 07:47:49 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <AvcNFdCM6eGAM-NA9yDxTZzE_h5xywb7qZV-ZhohHNc=.0ec40d45-ac53-460e-8df9-d2795add811f@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>
 <AvcNFdCM6eGAM-NA9yDxTZzE_h5xywb7qZV-ZhohHNc=.0ec40d45-ac53-460e-8df9-d2795add811f@github.com>
Message-ID: <U68JoyaXxhEailTKQBaI0OCmPVg7nTS8e5pbn1jlGpI=.3321a055-a8a1-4a22-b6d4-1322c7892998@github.com>

On Thu, 6 Apr 2023 07:32:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One additional thing we could do is update the usage output for -i/--generate-index to say that the option is deprecated. Looking at `jdeps -help` output to see this for the deprecated -P/--profile option.

Implemented as suggested. The --help output now looks like:


  -i, --generate-index=FILE  Generate index information for the specified jar
                             archives. This option is deprecated and may be 
                             removed in a future release.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1500032739


From duke at openjdk.org  Fri Apr  7 07:47:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 07:47:49 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/79b19e94..d04df25e

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

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

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


From aturbanov at openjdk.org  Fri Apr  7 08:09:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 7 Apr 2023 08:09:46 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <MoRaAV2bfkpmtql8WLLyCK7oZuW7oIWJDzLSgmBAEvU=.e90d7846-8e32-4dba-a63e-1d9a2d69fc7e@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 299:

> 297:         String platformFactory = switch (OperatingSystem.current()) {
> 298:             case WINDOWS -> "java.util.prefs.WindowsPreferencesFactory";
> 299:             case MACOS ->  "java.util.prefs.MacOSXPreferencesFactory";

Suggestion:

            case MACOS -> "java.util.prefs.MacOSXPreferencesFactory";

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1160525650


From duke at openjdk.org  Fri Apr  7 13:56:39 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 7 Apr 2023 13:56:39 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts [v2]
In-Reply-To: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
Message-ID: <ZKj4FSQAKrQFGU8wHuIMhxNFVfGeXLs2EKreYEUXV9s=.993ca72a-a599-43b3-b5b5-49a42f2b8c34@github.com>

> Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.

Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision:

 - added comment referring to relevant RFC
 - clarified if-statements; fixed exception message wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13306/files
  - new: https://git.openjdk.org/jdk/pull/13306/files/92c68e4c..7c47ed30

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

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

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


From duke at openjdk.org  Fri Apr  7 13:56:44 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 7 Apr 2023 13:56:44 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts [v2]
In-Reply-To: <h1_dut4TxoUR_lSrYQpksnvG78YPtL0JupeqCd8TgTk=.40fb1238-dc76-4480-8766-3a553ebf3516@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
 <h1_dut4TxoUR_lSrYQpksnvG78YPtL0JupeqCd8TgTk=.40fb1238-dc76-4480-8766-3a553ebf3516@github.com>
Message-ID: <rNkG0H3wPqzh8BQ2dbWqgJBpiV5cr71yQzcqyJqvZ_E=.ced24a04-9364-43aa-af8e-c37525dab1d6@github.com>

On Fri, 7 Apr 2023 02:14:59 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - added comment referring to relevant RFC
>>  - clarified if-statements; fixed exception message wording
>
> src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java line 266:
> 
>> 264:         //
>> 265:         if (contentType == ContentType.HANDSHAKE.id) {
>> 266:             if (!fragment.hasRemaining()) {
> 
> It may be easier to read if using "contentLen != 0", instead of "fragment.hasRemaining()".  I may add a comment like what is says in RFC 8446, "Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding."

I updated the if-logic and added the comment

> src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java line 267:
> 
>> 265:         if (contentType == ContentType.HANDSHAKE.id) {
>> 266:             if (!fragment.hasRemaining()) {
>> 267:                 throw new SSLProtocolException("Handshake packets may not be zero-length");
> 
> "may not" -> "must not"

Fixed

> src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 287:
> 
>> 285:         if (contentType == ContentType.HANDSHAKE.id) {
>> 286:             ByteBuffer handshakeFrag = fragment;
>> 287:             if (!handshakeFrag.hasRemaining()) {
> 
> Same comment as src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java

Also fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13306#discussion_r1160716144
PR Review Comment: https://git.openjdk.org/jdk/pull/13306#discussion_r1160716277
PR Review Comment: https://git.openjdk.org/jdk/pull/13306#discussion_r1160716381


From rriggs at openjdk.org  Fri Apr  7 14:24:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 14:24:37 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v4]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <Usevw300y_mQRvFgSwqQlXsxI8LHs0hb38Xk6PuTx1g=.64512eff-175f-4da7-a1e2-34afd8936b3c@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove errant space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/5546b824..b9267942

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

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

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


From mullan at openjdk.org  Fri Apr  7 14:52:43 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Apr 2023 14:52:43 GMT
Subject: RFR: 8305310: Calculate PublicKey from PrivateKey [v2]
In-Reply-To: <Eb3EX3nkXnXMFPhW1DrL7kZr4tZA83TWV4mpnxQQtP0=.89e18e24-1ad1-4494-964d-2e98218c7b14@github.com>
References: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
 <Eb3EX3nkXnXMFPhW1DrL7kZr4tZA83TWV4mpnxQQtP0=.89e18e24-1ad1-4494-964d-2e98218c7b14@github.com>
Message-ID: <PlYR0iUcsnUagIk4rfL1yFnhluNbtl7DRpIXLpDh2Fc=.cbeebe31-333f-4d5b-9395-481286364e9a@github.com>

On Fri, 31 Mar 2023 12:48:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change is for DHKEM, which requires the function
>> 
>> pk(skX): The KEM public key corresponding to the KEM private key skX.
>> 
>> Only implemented for EC and XDH. Might add PKCS #11 support later.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exception message, directory name

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13250#pullrequestreview-1376279187


From alanb at openjdk.org  Fri Apr  7 16:32:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Apr 2023 16:32:48 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <7c4SBE39xUiS01y6-GM-uH3F-tL_H975S1bgEwWsrLs=.9c69b6cc-bcdd-44ee-81e5-f88ad9f7dcde@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

I've updated the CSR to align it with the proposed solution. Please review again and if you happy, press "Finalize".

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1500441305


From duke at openjdk.org  Fri Apr  7 16:36:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 16:36:49 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <7c4SBE39xUiS01y6-GM-uH3F-tL_H975S1bgEwWsrLs=.9c69b6cc-bcdd-44ee-81e5-f88ad9f7dcde@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
 <7c4SBE39xUiS01y6-GM-uH3F-tL_H975S1bgEwWsrLs=.9c69b6cc-bcdd-44ee-81e5-f88ad9f7dcde@github.com>
Message-ID: <nmKbFFghmOj8RodCnv6wMTvUzaTBf0uSs1PVv-7J1lg=.2ea66677-3cfe-4ad9-9c31-9e3110e1f10e@github.com>

On Fri, 7 Apr 2023 16:29:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've updated the CSR to align it with the proposed solution. Please review again and if you happy, press "Finalize".

Thanks, Alan, this looks good to me. I have pressed "Finalize".

The CSR makes promises about the Release Note. Do you think the current Release Note delivers on this promise?

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

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1500444352


From mpowers at openjdk.org  Fri Apr  7 19:16:47 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 7 Apr 2023 19:16:47 GMT
Subject: RFR: JDK-8302696 Revert API signature changes made in JDK-8285504 and
 JDK-8285263
Message-ID: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>

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

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

Commit messages:
 - Merge
 - first iteration

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

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


From mullan at openjdk.org  Fri Apr  7 19:48:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Apr 2023 19:48:44 GMT
Subject: RFR: JDK-8302696 Revert API signature changes made in JDK-8285504
 and JDK-8285263
In-Reply-To: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
References: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
Message-ID: <w7_ZOyCwypz0QqtQGaoLY_5qRnWlUb1ggM9z2aoPhWA=.c434c5f0-4f09-4f91-8881-30ac1ee608e8@github.com>

On Fri, 7 Apr 2023 19:09:43 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8302696

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13391#pullrequestreview-1376528212


From jiangli at openjdk.org  Fri Apr  7 23:55:54 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Apr 2023 23:55:54 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries
Message-ID: <hcDP1eJ-k2BNE8oPBIZ4ZqCYWQi9xS1lexDY8d5JRro=.32adadad-fbdb-4292-990a-0281a9b26add@github.com>

Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.

8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries

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

Commit messages:
 - Resolve linker failure due to multiple definition of 'jvm' when statically linking with JDK native libraries.

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

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


From jiangli at openjdk.org  Sat Apr  8 00:04:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 8 Apr 2023 00:04:57 GMT
Subject: Withdrawn: 8305761: Resolve multiple definition of 'jvm' when
 statically linking with JDK native libraries
In-Reply-To: <hcDP1eJ-k2BNE8oPBIZ4ZqCYWQi9xS1lexDY8d5JRro=.32adadad-fbdb-4292-990a-0281a9b26add@github.com>
References: <hcDP1eJ-k2BNE8oPBIZ4ZqCYWQi9xS1lexDY8d5JRro=.32adadad-fbdb-4292-990a-0281a9b26add@github.com>
Message-ID: <MV9Nv67M8uMxQchhWUqSJWgml_ygROeUC9b3r7yNTmM=.ebb25c08-dd7c-46e8-881b-a718e7f32381@github.com>

On Fri, 7 Apr 2023 23:32:46 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.
> 
> 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries

This pull request has been closed without being integrated.

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

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


From jiangli at openjdk.org  Sat Apr  8 01:19:44 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 8 Apr 2023 01:19:44 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries
Message-ID: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>

? with JDK native libraries

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

Commit messages:
 - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries

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

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


From duke at openjdk.org  Sun Apr  9 09:54:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 9 Apr 2023 09:54:50 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <YZVAX8X1dCPJREA_khYRvrv5TFWwoVcBD212xChegow=.6cb9dc6f-2cf4-4a17-b226-0621e9f3de36@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

It seems the stars are getting aligned for this PR to be integrated.

None of the current approvals apply to the latest commit d04df25ea2dd505f2224bff446865a0974a8f37a, it would be good to have that `jar --help` update approved as well.

Are there any other concerns left before we can integrate?

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1501089831


From weijun at openjdk.org  Mon Apr 10 00:58:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Apr 2023 00:58:56 GMT
Subject: Integrated: 8305310: Calculate PublicKey from PrivateKey
In-Reply-To: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
References: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
Message-ID: <0qT2jBgCwcKaj9nzs5S3_VmOuodsIGjAWWeGC_hRrm8=.823b4355-1439-44c3-aa2f-de613e35c988@github.com>

On Thu, 30 Mar 2023 19:31:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change is for DHKEM, which requires the function
> 
> pk(skX): The KEM public key corresponding to the KEM private key skX.
> 
> Only implemented for EC and XDH. Might add PKCS #11 support later.

This pull request has now been integrated.

Changeset: 97276859
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97276859ab3892fbf3e839f9403a8e8a1760e803
Stats:     186 lines in 7 files changed: 147 ins; 20 del; 19 mod

8305310: Calculate PublicKey from PrivateKey

Reviewed-by: mullan

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

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


From xuelei at openjdk.org  Mon Apr 10 01:14:55 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Apr 2023 01:14:55 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts [v2]
In-Reply-To: <ZKj4FSQAKrQFGU8wHuIMhxNFVfGeXLs2EKreYEUXV9s=.993ca72a-a599-43b3-b5b5-49a42f2b8c34@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
 <ZKj4FSQAKrQFGU8wHuIMhxNFVfGeXLs2EKreYEUXV9s=.993ca72a-a599-43b3-b5b5-49a42f2b8c34@github.com>
Message-ID: <vG5ETsrhQokcED9ZZ4iom5c2aC9FrRIVqQiU3tzRP0o=.6e0b2827-060f-48d4-827e-0689f186ca46@github.com>

On Fri, 7 Apr 2023 13:56:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.
>
> Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added comment referring to relevant RFC
>  - clarified if-statements; fixed exception message wording

Looks good to me.  Thank you!

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

Marked as reviewed by xuelei (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13306#pullrequestreview-1376985093


From lancea at openjdk.org  Mon Apr 10 10:11:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 10:11:53 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <Czu-mBUM7EfgSs7RXn9mc0HbbTNOgdHhwp36NM7xwIw=.ef63b4eb-1a25-4e04-b16d-10c62540fe11@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

> It seems the stars are getting aligned for this PR to be integrated.
> 
> None of the current approvals apply to the latest commit [d04df25](https://github.com/openjdk/jdk/commit/d04df25ea2dd505f2224bff446865a0974a8f37a), it would be good to have that `jar --help` update approved as well.
> 
> Are there any other concerns left before we can integrate?

I think we are good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1501639744


From lancea at openjdk.org  Mon Apr 10 10:15:51 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Apr 2023 10:15:51 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
Message-ID: <bshbqRBVTcIUuYkCQCg3pcMXu4CzCjq6kEymbMDaj8o=.82964e6e-0d88-4455-93a2-3fc986514b50@github.com>

On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a note in the --help for --generate-index that this option is deprecated and may be removed in a future release.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1377350274


From duke at openjdk.org  Mon Apr 10 10:45:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 10 Apr 2023 10:45:48 GMT
Subject: RFR: 8302819: Remove JAR Index [v6]
In-Reply-To: <Czu-mBUM7EfgSs7RXn9mc0HbbTNOgdHhwp36NM7xwIw=.ef63b4eb-1a25-4e04-b16d-10c62540fe11@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KcM_pg9upKHG9Acu-hKaEARgJ1HT6c4xz5sMxvz3B8o=.6d62d5c9-29d7-4ba1-80cf-cc719c39f81d@github.com>
 <Czu-mBUM7EfgSs7RXn9mc0HbbTNOgdHhwp36NM7xwIw=.ef63b4eb-1a25-4e04-b16d-10c62540fe11@github.com>
Message-ID: <zfOVzfE3t5S_KjbOBT8uJzYdxO3j_ZBwNib5mbfeCYY=.eebc4d0c-725c-48a2-8eae-8dbd294731d1@github.com>

On Mon, 10 Apr 2023 10:09:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think we are good to go.

Thanks, the PR is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1501666039


From duke at openjdk.org  Mon Apr 10 11:27:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 10 Apr 2023 11:27:02 GMT
Subject: Integrated: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <SE0GbU2IGKwdxzIV1_xwGBovTJTvZmWjU7jetXCcJCY=.77b913b2-685f-47fa-8651-8210c91291aa@github.com>

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.

This pull request has now been integrated.

Changeset: 0d45a524
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d45a524b3d29fd57a4d468d7b5af0f588db7409
Stats:     1826 lines in 25 files changed: 231 ins; 1580 del; 15 mod

8302819: Remove JAR Index

Reviewed-by: mchung, alanb, lancea, jpai

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

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


From alanb at openjdk.org  Mon Apr 10 13:55:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Apr 2023 13:55:43 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries
In-Reply-To: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
Message-ID: <n3dJK2gWMYWCIdRcgDb7ZBb8gepc9lkvKJa-I0n3jPI=.89a7b562-6de6-4148-bfa7-9fcec0e028a8@github.com>

On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.

src/java.management/share/native/libmanagement/management.c line 36:

> 34: const JmmInterface* jmm_interface = NULL;
> 35: JavaVM* jvm_management = NULL;
> 36: jint jmm_version = 0;

Is there any reason why these field can't be static?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13397#discussion_r1161738529


From rriggs at openjdk.org  Mon Apr 10 15:53:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 15:53:54 GMT
Subject: Integrated: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <cYBk3ZVUnDppbIZGj79ENgNctV4SjMCgrAXF1Jf_Sd8=.150e8aac-3658-4a6e-876c-9c3147847104@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

This pull request has now been integrated.

Changeset: ba90dc77
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba90dc77958c399e4e1fc3c4999dd76680480c7b
Stats:     120 lines in 12 files changed: 20 ins; 50 del; 50 mod

8304911: Use OperatingSystem enum in some modules

Reviewed-by: naoto, lancea, iris, jpai

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

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


From eirbjo at gmail.com  Mon Apr 10 18:11:22 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 10 Apr 2023 20:11:22 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate,
 Identity, IdentityScope, Signer} APIs
Message-ID: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>

Hello Sean,

I'm curious about the state/fate of JDK-8191136 [1]. This issue aims to
remove some long deprecated classes in java.security.

It seems this issue had several stalls and that it finally was targeted to
Java 19, but never executed.

I think it would be very nice to remove these confusing API classes now,
before we let them see another LTS.

If you already have a PR up your sleeve, that would be great, otherwise I
would be happy to take on this task, get the CSR reapproved etc.

What do you think?

Cheers.
Eirik.

[1] https://bugs.openjdk.org/browse/JDK-8191136
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230410/8a05f4a1/attachment.htm>

From jiangli at openjdk.org  Mon Apr 10 19:22:50 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Apr 2023 19:22:50 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries
In-Reply-To: <n3dJK2gWMYWCIdRcgDb7ZBb8gepc9lkvKJa-I0n3jPI=.89a7b562-6de6-4148-bfa7-9fcec0e028a8@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
 <n3dJK2gWMYWCIdRcgDb7ZBb8gepc9lkvKJa-I0n3jPI=.89a7b562-6de6-4148-bfa7-9fcec0e028a8@github.com>
Message-ID: <R8Qn2A6fvmgP_UPzOxSNIjU2Y-4R0bfrLj1iLhu5kR8=.b51e6f79-6812-46f9-88d0-15e108551c10@github.com>

On Mon, 10 Apr 2023 13:52:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.
>
> src/java.management/share/native/libmanagement/management.c line 36:
> 
>> 34: const JmmInterface* jmm_interface = NULL;
>> 35: JavaVM* jvm_management = NULL;
>> 36: jint jmm_version = 0;
> 
> Is there any reason why these field can't be static?

Thanks.

My understanding is that 'static' gives internal linkage. The static variable is limited to the scope of the translate unit that declares it. It seems to be okay to use 'static' for the 'jvm' variables in  [management.c](https://github.com/openjdk/jdk/pull/13397/files/0fa6a4b3984d91c124ee2adb9d6e1facdc63c156#diff-1717ac36c4bbefab688a4e75104417bec3687f78108096c2cca3af4ee552ab11) and [management_ext.c](https://github.com/openjdk/jdk/pull/13397/files#diff-0fa91a6686c9e5dc77bdef6981235785524108950075e58d2004853dc66e1977) to resolve the symbol issue. It's problematic for the usages in jdk.crypto.cryptoki code.

I'll change management.c and management_ext.c to define 'jvm' as 'static' as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13397#discussion_r1162008444


From jiangli at openjdk.org  Mon Apr 10 19:38:18 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Apr 2023 19:38:18 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries [v2]
In-Reply-To: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
Message-ID: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>

> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.

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

  Update management.c and management_ext.c to define 'jvm' as static.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13397/files
  - new: https://git.openjdk.org/jdk/pull/13397/files/0fa6a4b3..40b1a82a

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

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

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


From Alan.Bateman at oracle.com  Mon Apr 10 19:39:54 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Apr 2023 20:39:54 +0100
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
Message-ID: <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>



On 10/04/2023 19:11, Eirik Bj?rsn?s wrote:
>
> Hello Sean,
>
> I'm curious about the state/fate of?JDK-8191136 [1]. This issue aims 
> to remove some long deprecated classes in java.security.
>
> It seems this issue had several stalls and that it finally was 
> targeted to Java 19, but never executed.
>
> I think it would be very nice to remove these confusing API classes 
> now, before we let them see another LTS.
>
> If you already have a PR up your sleeve, that would be great, 
> otherwise I would be happy to take on this task, get the CSR 
> reapproved etc.
>
> What?do you think?
>
The issue with java.security.Identity is/was the usage in Java EE, more 
specifically the EJB spec and the concern that there are app servers 
that want to support Java EE releases and run on newer JDK releases at 
the same time. So this one has been stuck for a long time.

-Alan


From eirbjo at gmail.com  Mon Apr 10 19:46:54 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 10 Apr 2023 21:46:54 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
Message-ID: <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>

>
> The issue with java.security.Identity is/was the usage in Java EE, more
> specifically the EJB spec and the concern that there are app servers
> that want to support Java EE releases and run on newer JDK releases at
> the same time. So this one has been stuck for a long time.
>

Jakarta EE 9 was updated to remove EJBContext methods which depended on
java.security.Identity.

Is the remaining concern about Java EE 8 implementations running Java 21
and newer? The Java 17 LTS seems to be supported until 2029?

Are our hands tied or would it be possible to move forward on this?

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230410/37375e42/attachment.htm>

From sean.mullan at oracle.com  Mon Apr 10 20:00:16 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 10 Apr 2023 16:00:16 -0400
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
Message-ID: <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>

Eirik,

First, thanks for volunteering to help out. Unfortunately though, this 
is a tricky issue that is best left as is for now.

On 4/10/23 3:46 PM, Eirik Bj?rsn?s wrote:
>     The issue with java.security.Identity is/was the usage in Java EE, more
>     specifically the EJB spec and the concern that there are app servers
>     that want to support Java EE releases and run on newer JDK releases at
>     the same time. So this one has been stuck for a long time.
> 
> 
> Jakarta EE 9 was updated to remove EJBContext methods which depended on 
> java.security.Identity.

Correct.

> Is the?remaining concern about Java EE 8 implementations running Java 21 
> and newer? 

Yes.

Given that removing these APIs would cause TCK issues in these cases, I 
have been reticent to remove the APIs. At this point, I view this to be 
in a holding pattern until we have a very strong confidence that it 
won't break EE implementations.

> The Java 17 LTS seems to be supported until 2029?
> 
> Are our hands tied or would it be possible?to move forward on this?

I wouldn't necessarily say our hands are tied, but more that we need to 
wait longer.

This is a small enough set of APIs that I don't feel this is a huge 
burden to keep around a few more releases. All dependencies on these 
APIs in the JDK have been removed.

I shall update the issue with some more of these details.

--Sean


From eirbjo at gmail.com  Mon Apr 10 20:11:53 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 10 Apr 2023 22:11:53 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
Message-ID: <CA+pBWhvUzgNKTPP4ckHbkNf0uH2euuuy3QAUjb_3OaJgzW4RjA@mail.gmail.com>

On Mon, Apr 10, 2023 at 10:00?PM Sean Mullan <sean.mullan at oracle.com> wrote:

> Eirik,
>
> First, thanks for volunteering to help out. Unfortunately though, this
> is a tricky issue that is best left as is for now.
>

Thanks for explaining, Sean.  I'll look for greener pastures :-)

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230410/1d92706f/attachment.htm>

From Nico.Williams at twosigma.com  Mon Apr 10 20:57:11 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 10 Apr 2023 20:57:11 +0000
Subject: JDK-8304264 isn't quite right
Message-ID: <20230410205711.GC581160@twosigma.com>

JDK-8304264 is due to c63fabe3d582ce0828b04b0224cea49aab5fedf3 (8284935:
Improve debug in java.security.jgss) which did this:

```
@@ -51,14 +52,14 @@ public final class SunNativeProvider extends Provider {
     private static final String INFO = "Sun Native GSS provider";
     private static final String MF_CLASS =
         "sun.security.jgss.wrapper.NativeGSSFactory";
-    static boolean DEBUG;
+    private static final boolean DEBUG =
+        GetBooleanAction.privilegedGetProperty("sun.security.nativegss.debug");
+
     static void debug(String message) {
-        if (DEBUG) {
-            if (message == null) {
-                throw new NullPointerException();
-            }
-            System.out.println(NAME + ": " + message);
+        if (message == null) {
+            throw new NullPointerException();
         }
+        System.out.println(NAME + ": " + message);
     }

     @SuppressWarnings("removal")
```

and then changed all the `debug()` method call sites to check
SunNativeProvider.DEBUG.  Several JGSS classes have their own DEBUG
methods.

This was done to avoid string concatenation at the call sites when debug
is disabled.  Fair enough.  But the fix for JDK-8284935 (or subsequent
commits) missed some call sites, yielding JDK-8304264.

It would be better to also have the debug check in the debug() method(s)
just in case call sites are missed.  Because the boolean class member is
a `static final` the JIT should optimize the superfluous branch away.

Also, while we're at it, printing debug messages to `stdout` is a
terrible thing to do.  The only reason I'm even writing this is that
those messages go to `stdout`.  The chance of accidental writing to
`stdout` (which can cause problems for apps) should be zero.

Thanks,

Nico
-- 


From xuelei at openjdk.org  Mon Apr 10 21:15:48 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Apr 2023 21:15:48 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts [v2]
In-Reply-To: <ZKj4FSQAKrQFGU8wHuIMhxNFVfGeXLs2EKreYEUXV9s=.993ca72a-a599-43b3-b5b5-49a42f2b8c34@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
 <ZKj4FSQAKrQFGU8wHuIMhxNFVfGeXLs2EKreYEUXV9s=.993ca72a-a599-43b3-b5b5-49a42f2b8c34@github.com>
Message-ID: <_LA1RahYAmxD2WhJmIMYT7EKGP6zAnClPiq--_KfRMc=.8ca5b9bc-9a8c-4430-a671-b98f284749ac@github.com>

On Fri, 7 Apr 2023 13:56:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.
>
> Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added comment referring to relevant RFC
>  - clarified if-statements; fixed exception message wording

@mpdonova Did you have a chance to pass Mach5 testing?  If the testing is good, I would like to sponsor the committing.

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

PR Comment: https://git.openjdk.org/jdk/pull/13306#issuecomment-1502332785


From jnimeh at openjdk.org  Mon Apr 10 23:32:36 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 10 Apr 2023 23:32:36 GMT
Subject: RFR: 8182621: JSSE should reject empty TLS plaintexts [v2]
In-Reply-To: <_LA1RahYAmxD2WhJmIMYT7EKGP6zAnClPiq--_KfRMc=.8ca5b9bc-9a8c-4430-a671-b98f284749ac@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
 <ZKj4FSQAKrQFGU8wHuIMhxNFVfGeXLs2EKreYEUXV9s=.993ca72a-a599-43b3-b5b5-49a42f2b8c34@github.com>
 <_LA1RahYAmxD2WhJmIMYT7EKGP6zAnClPiq--_KfRMc=.8ca5b9bc-9a8c-4430-a671-b98f284749ac@github.com>
Message-ID: <osbQKp5cxB7JpDb0mjGYxD586eCkpFYyj21AB9aEeBs=.85bdbd6c-6a4d-419b-b991-87f59bc0abb3@github.com>

On Mon, 10 Apr 2023 21:12:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - added comment referring to relevant RFC
>>  - clarified if-statements; fixed exception message wording
>
> @mpdonova Did you have a chance to pass Mach5 testing?  If the testing is good, I would like to sponsor the committing.

@XueleiFan Yes, @mpdonova did have successful mach5 runs.  I had a similar question I asked him directly and I've reviewed the results.  jdk_security test groups are clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/13306#issuecomment-1502467293


From duke at openjdk.org  Tue Apr 11 04:24:54 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 11 Apr 2023 04:24:54 GMT
Subject: Integrated: 8182621: JSSE should reject empty TLS plaintexts
In-Reply-To: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
References: <B4DYs8UAsUD1GyAle9SG_SlAhUNw4i7vTpf1UegIuB8=.d560062c-8023-4fa5-a418-e0c81fecd155@github.com>
Message-ID: <N589jYW3FIfQulj5u_JRWSjeaUL-_NnOza0sfRrYDaw=.23f7d278-8902-40e9-8d42-8822cfe033ed@github.com>

On Mon, 3 Apr 2023 18:13:19 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added code similar to the suggested patches for empty Handshake messages. I also implemented tests to verify empty Handshake, Alert, and ChangeCipherSpec messages result in expected behavior: for SSLEngineImpl, exceptions are thrown, for SSLSockets the connection is closed.

This pull request has now been integrated.

Changeset: 39398075
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/39398075b719739513b7610286e19735a8b478b1
Stats:     648 lines in 4 files changed: 646 ins; 0 del; 2 mod

8182621: JSSE should reject empty TLS plaintexts

Reviewed-by: xuelei

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

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


From alanb at openjdk.org  Tue Apr 11 11:07:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Apr 2023 11:07:33 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries [v2]
In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
 <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>
Message-ID: <xCKjdS6DRRkFcn_RXxsrmJsqMt09sQGua2fA1fbQ6V8=.7399d065-3622-4d9f-8258-b0dff575b5a3@github.com>

On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update management.c and management_ext.c to define 'jvm' as static.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13397#pullrequestreview-1378993775


From kevinw at openjdk.org  Tue Apr 11 14:12:36 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Apr 2023 14:12:36 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries [v2]
In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
 <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>
Message-ID: <fp6QvtcMyJDYFM28sDGScyQYJUCtW2fy2lXAYNhoLdg=.a2af977b-becb-44a3-95f4-77da301f48b6@github.com>

On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update management.c and management_ext.c to define 'jvm' as static.

Marked as reviewed by kevinw (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13397#pullrequestreview-1379355549


From mpowers at openjdk.org  Tue Apr 11 14:45:47 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 11 Apr 2023 14:45:47 GMT
Subject: Integrated: JDK-8302696 Revert API signature changes made in
 JDK-8285504 and JDK-8285263
In-Reply-To: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
References: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
Message-ID: <BeVsKjSie4CnqMzPx8h3CTqoue675oLO3MDKPwMheow=.8265224a-d112-4b69-ad03-6280608dec59@github.com>

On Fri, 7 Apr 2023 19:09:43 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8302696

This pull request has now been integrated.

Changeset: 9486969b
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9486969bd3cb084c89a7255de0c664c980d1e661
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263

Reviewed-by: mullan

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

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


From jiangli at openjdk.org  Tue Apr 11 15:08:48 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Apr 2023 15:08:48 GMT
Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically
 linking with JDK native libraries [v2]
In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
 <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com>
Message-ID: <eN-Hj0vhfuZz_em8EnhdlX7Ejv0-4JSBEpSrYQM8ito=.03c63eee-0de6-4792-a63e-b13836ca03a4@github.com>

On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update management.c and management_ext.c to define 'jvm' as static.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13397#issuecomment-1503553861


From jiangli at openjdk.org  Tue Apr 11 15:08:50 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Apr 2023 15:08:50 GMT
Subject: Integrated: 8305761: Resolve multiple definition of 'jvm' when
 statically linking with JDK native libraries
In-Reply-To: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
References: <rr5Dxv5Au01VnIEXh5meaQMdTAmoEG9VY7TF9boz_Bc=.47ea302d-e5c2-4c37-97eb-8a98a1cd86f4@github.com>
Message-ID: <-x_vxEhdcSWFLhsFY6_gPE15yQueMwboKZUAkuY42tM=.33bf748a-cc6e-4b25-ba27-80c2267b8c98@github.com>

On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename various 'jvm' variables to 'jvm_<lib_name>' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries.

This pull request has now been integrated.

Changeset: ce4b9955
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce4b9955568100d6b315336321ff8903b703f19e
Stats:     34 lines in 5 files changed: 0 ins; 0 del; 34 mod

8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries

Reviewed-by: alanb, kevinw

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

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


From jnimeh at openjdk.org  Tue Apr 11 17:35:28 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 11 Apr 2023 17:35:28 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM
Message-ID: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>

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

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

Commit messages:
 - 8305091: Change ChaCha20 cipher init behavior to match AES-GCM

Changes: https://git.openjdk.org/jdk/pull/13428/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305091
  Stats: 77 lines in 2 files changed: 31 ins; 14 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/13428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13428/head:pull/13428

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


From xuelei at openjdk.org  Tue Apr 11 18:18:38 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 11 Apr 2023 18:18:38 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: <uPcGi5evrDkNGXuoGr6YrI1yTOPh_vwCSKRsRgklfYo=.26f9717a-6eec-4d59-af8e-5d0c5c74820c@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

In the decryption side, does it sound like good to detect and reject key/nonce reuse for security reason(i.e., if key/nonce is reused, the decryption side will not accept the encryption)?  Did you known real problems in practice for the key/nonce reuse for decryption?

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

PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1503872733


From jnimeh at openjdk.org  Tue Apr 11 18:23:32 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 11 Apr 2023 18:23:32 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <uPcGi5evrDkNGXuoGr6YrI1yTOPh_vwCSKRsRgklfYo=.26f9717a-6eec-4d59-af8e-5d0c5c74820c@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
 <uPcGi5evrDkNGXuoGr6YrI1yTOPh_vwCSKRsRgklfYo=.26f9717a-6eec-4d59-af8e-5d0c5c74820c@github.com>
Message-ID: <ts9SryHfZ673ipRCUDXC1TWmmmTDWUq9P8IyZL2CoZE=.a8658959-38d2-4090-bd9f-26206f6e1f2b@github.com>

On Tue, 11 Apr 2023 18:15:22 GMT, Xue-Lei Andrew Fan <xuelei 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
>
> In the decryption side, does it sound like good to detect and reject key/nonce reuse for security reason(i.e., if key/nonce is reused, the decryption side will not accept the encryption)?  Did you known real problems in practice for the key/nonce reuse for decryption?

@XueleiFan I think the key/nonce reuse protections are there to prevent sending ciphertexts out that are created from XORing against the same value twice.  But that is an encryption use case.  Decryption is a different story, since you're consuming the ciphertext and not emitting data out on the wire.  The decrypting entity might use that data, but that doesn't leak information to a passive observer.
There are cases where people using the ChaCha20 and ChaCha20-Poly1305 ciphers have run into behavioral issues because they operate differently than AES-GCM does.  It seems sensible that the ciphers should be unified in their behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1503878118


From jiangli at openjdk.org  Tue Apr 11 19:25:25 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Apr 2023 19:25:25 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when
 statically linking with JDK native libraries
Message-ID: <g3oGVtC_e7QXpX9duoKG8UvErLjuej7bNM5UjH336Dg=.5ad810ef-44cd-42f6-8097-a890d2c95bd3@github.com>

Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves related duplicate symbol failure when both libnio and libsctp are statically linked with.

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

Commit messages:
 - 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

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

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


From cslucas at openjdk.org  Tue Apr 11 22:06:42 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 11 Apr 2023 22:06:42 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v7]
In-Reply-To: <4uPGi8Ulap_QoQpkL1zTZUdP-jdL_WDEkpdP7asLow4=.9047ce21-688f-4d29-a643-f9acfd4344c7@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <jisueY-iTRpza7F1n2OC1tehHKkzDiJa5bZCUhXyXAg=.43474c8f-3784-464c-8e56-4d18825437c4@github.com>
 <4uPGi8Ulap_QoQpkL1zTZUdP-jdL_WDEkpdP7asLow4=.9047ce21-688f-4d29-a643-f9acfd4344c7@github.com>
Message-ID: <WZmFi5hoOMN5yDl65xkYTBFfGujkaASX1eOMr5H0qyA=.5be6ed43-dc3a-4361-a916-90a07a06466b@github.com>

On Thu, 6 Apr 2023 04:34:52 GMT, Vladimir Kozlov <kvn 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 seven commits:
>> 
>>  - 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.
>>  - Merge master
>>  - Add support for rematerializing scalar replaced objects participating in allocation merges
>
> src/hotspot/share/opto/output.cpp line 755:
> 
>> 753:       ciKlass* cik = t->is_oopptr()->exact_klass();
>> 754:       assert(cik->is_instance_klass() ||
>> 755:             cik->is_array_klass(), "Not supported allocation.");
> 
> Why spacing changed?

The identation level was incorrect before.

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

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


From jiangli at openjdk.org  Tue Apr 11 22:33:42 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Apr 2023 22:33:42 GMT
Subject: Withdrawn: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <g3oGVtC_e7QXpX9duoKG8UvErLjuej7bNM5UjH336Dg=.5ad810ef-44cd-42f6-8097-a890d2c95bd3@github.com>
References: <g3oGVtC_e7QXpX9duoKG8UvErLjuej7bNM5UjH336Dg=.5ad810ef-44cd-42f6-8097-a890d2c95bd3@github.com>
Message-ID: <JuZ-yUzcwWEo1ITyibZNkGtV4eWlwFIOhEbknlqqBf8=.ca49a43d-542c-4099-89c3-1005c730afba@github.com>

On Tue, 11 Apr 2023 19:19:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves related duplicate symbol failure when both libnio and libsctp are statically linked with.

This pull request has been closed without being integrated.

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

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


From valeriep at openjdk.org  Tue Apr 11 23:23:35 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Apr 2023 23:23:35 GMT
Subject: RFR: 8304845: COPYING in MUSCLE library includes incomplete license
Message-ID: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>

8304845: COPYING in MUSCLE library includes incomplete license

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

Commit messages:
 - Update to 1.9.9 and more .md changes.
 - 8304845: COPYING in MUSCLE library includes incomplete license

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

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


From cslucas at openjdk.org  Wed Apr 12 00:32:40 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 12 Apr 2023 00:32:40 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v7]
In-Reply-To: <4uPGi8Ulap_QoQpkL1zTZUdP-jdL_WDEkpdP7asLow4=.9047ce21-688f-4d29-a643-f9acfd4344c7@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <jisueY-iTRpza7F1n2OC1tehHKkzDiJa5bZCUhXyXAg=.43474c8f-3784-464c-8e56-4d18825437c4@github.com>
 <4uPGi8Ulap_QoQpkL1zTZUdP-jdL_WDEkpdP7asLow4=.9047ce21-688f-4d29-a643-f9acfd4344c7@github.com>
Message-ID: <Z-uEVBlcSj7cRqPh5WeExuABSuGybzzby0WIgnMMSsU=.b17b4b4e-4448-4dff-873e-39693064bac0@github.com>

On Thu, 6 Apr 2023 03:25:31 GMT, Vladimir Kozlov <kvn 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 seven commits:
>> 
>>  - 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.
>>  - Merge master
>>  - Add support for rematerializing scalar replaced objects participating in allocation merges
>
> src/hotspot/share/opto/escape.cpp line 633:
> 
>> 631: 
>> 632:     SafePointScalarMergeNode* smerge = new SafePointScalarMergeNode(merge_t, merge_idx);
>> 633:     smerge->init_req(0, _compile->root());
> 
> May be use ophi's control here, it should stay bellow merge point. Was there a reason you use `root`?

To be honest, for this Node, I thought it didn't matter. I actually just used the same pattern as in PhaseMacroExpand.
I'll adjust the patch as you suggested, though.

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

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


From manc at openjdk.org  Wed Apr 12 01:37:35 2023
From: manc at openjdk.org (Man Cao)
Date: Wed, 12 Apr 2023 01:37:35 GMT
Subject: RFR: 8304845: COPYING in MUSCLE library includes incomplete
 license
In-Reply-To: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
References: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
Message-ID: <J2j0UU5HJ9pVqLxnkrobIJbiixlFJ4swcebOaI8TAUM=.41a836a7-c15b-45dd-a9d9-31c182dc6c7c@github.com>

On Mon, 10 Apr 2023 16:56:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this fix? Besides updating the md and COPYING files to address the incomplete license issue, this PR also updates the version to 1.9.9.

Thank you for fixing this! Not an official Reviewer, but it looks good.

src/java.smartcardio/unix/native/libj2pcsc/MUSCLE/COPYING line 29:

> 27: 
> 28: 
> 29: Some source code files are using other licences. However, they are not included here and thus this file is a truncated version of the [COPYING](https://salsa.debian.org/rousseau/PCSC/-/blob/master/COPYING) file.

Nit: should be "licenses".

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

PR Comment: https://git.openjdk.org/jdk/pull/13409#issuecomment-1504397482
PR Review Comment: https://git.openjdk.org/jdk/pull/13409#discussion_r1163474198


From jiangli at openjdk.org  Wed Apr 12 03:29:36 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 03:29:36 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when
 statically linking with JDK native libraries
Message-ID: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>

Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.

Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.

(Sorry about the earlier RFR/Withdrawn noise.)

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

Commit messages:
 - 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

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

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


From jiangli at openjdk.org  Wed Apr 12 03:29:37 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 03:29:37 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <kLWWNdDkdoeUNGpyPd-cGDVwEw7oYKMT5Jtc8YyZGPw=.56098905-b018-4455-b803-dc4d44c82cce@github.com>

On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

I noticed there is a presubmit test failure: https://github.com/jianglizhou/jdk/actions/runs/4672962155#user-content-java_lang_thread_virtual_tracevirtualthreadlocals for linux-x86. It appears to be unrelated. Will file a bug tomorrow if there is not existing bug (will check before filing).

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1504522861


From alanb at openjdk.org  Wed Apr 12 06:32:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 06:32:40 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>

On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

This looks okay but it makes me wonder about loadSocketExtensionFuncs. Maybe we should remove that from Sctp.h and change loadSocketExtensionFuncs in SctpNet.c to be static.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1504733524


From mullan at openjdk.org  Wed Apr 12 13:25:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Apr 2023 13:25:32 GMT
Subject: RFR: 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: <ilyNqhJAvs6CxmwaBZJP4S-JwOzw2GKmjH3p0kr2HO0=.772db7d7-8b53-4632-8ee5-6d88cc041e25@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.

src/java.base/share/classes/javax/crypto/DecapsulateException.java line 30:

> 28: 
> 29: /**
> 30:  * An {@link Exception} child class that is thrown by the

I would just say "An exception that is thrown by ..." The mentioning that it is a child class and the link to Exception seems unnecessary.

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

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


From duke at openjdk.org  Wed Apr 12 14:08:30 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 12 Apr 2023 14:08:30 GMT
Subject: RFR: 8255548: Missing coverage for
 javax.xml.crypto.dom.DOMCryptoContext
Message-ID: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>

Implemented tests for the `DomCryptoContext.iterator()` method.

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

Commit messages:
 - 8255548: Missing coverage for javax.xml.crypto.dom.DOMCryptoContext

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

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


From xuelei at openjdk.org  Wed Apr 12 14:13:36 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Apr 2023 14:13:36 GMT
Subject: RFR: 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: <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@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.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 107:

> 105:      * @see KEM.Encapsulator
> 106:      */
> 107:     interface EncapsulatorSpi {

Is it really necessary to define a EncapsulatorSpi?  It looks like an internal implementation for KEMSpi service, rather than a public individual interface that EncapsulatorSpi.getInstance() could be used.

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

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


From mullan at openjdk.org  Wed Apr 12 14:55:38 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Apr 2023 14:55:38 GMT
Subject: RFR: 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: <vZjRV20pgiP4gpMwLQuMvXQs7b1FWFMLt72alz0UAlE=.a58966a9-b025-4b60-9376-461ae649f43b@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.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 37:

> 35:  * This class defines the Service Provider Interface (SPI)
> 36:  * for the {@link KEM} class. A security provider implements this interface
> 37:  * to implement a KEM algorithm.

Suggest defining what KEM stands for. Also, a few wording suggestions:

"A security provider implements this interface to provide an implementation of a Key Encapsulation Mechanism (KEM) algorithm."

src/java.base/share/classes/javax/crypto/KEMSpi.java line 39:

> 37:  * to implement a KEM algorithm.
> 38:  * <p>
> 39:  * A KEM algorithm may contain a family of configurations.

Would "support" instead of "contain" be better?

src/java.base/share/classes/javax/crypto/KEMSpi.java line 42:

> 40:  * Different configurations accept different types of keys, uses different
> 41:  * underlying cryptographic primitives, and supports different sizes of shared
> 42:  * secrets and key encapsulation messages. A configuration must be decided

Wording suggestions: "Each configuration may accept different types of keys, cryptographic primitives, and sizes of shared secrets and key encapsulation messages."

src/java.base/share/classes/javax/crypto/KEMSpi.java line 45:

> 43:  * by the KEM algorithm name, the key it uses, and an optional
> 44:  * {@code AlgorithmParameterSpec} argument when creating an encapsulator or
> 45:  * decapsulator. The result of either {@link #engineNewDecapsulator} or

How about: "A configuration is defined by the ..." and "... argument that is specified when ..."

"The result of calling {@link #engineNewDecapsulator} or .."

src/java.base/share/classes/javax/crypto/KEMSpi.java line 52:

> 50:  * A {@code KEMSpi} implementation should be immutable. It should be safe to
> 51:  * call multiple {@code engineNewEncapsulator} and {@code engineNewDecapsulator}
> 52:  * methods at the same time.

I would make these "should" requirements a "must", otherwise you cannot guarantee it when testing for API compliance. Same comment for the EncapsulatorSpi and DecapsulatorSpi below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164235638
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164243774
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164241949
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164249995
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164251531


From mullan at openjdk.org  Wed Apr 12 15:26:14 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Apr 2023 15:26:14 GMT
Subject: RFR: 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: <8bHDa13a4vgSx2M3EBpjxnMZEIvXRlmDeDEETErwUM8=.0d9c7013-dfc0-4342-b5d2-52b07ef33dde@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.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 211:

> 209:      * The caller of this method has already validated the parameters to
> 210:      * ensure that {@code pk} is not {@code null}. Therefore an implementation
> 211:      * of this method does not to validate it.

s/not to/not need to/

Also, suggest saying who the caller is, "The caller (KEM.newEncapsulator) of this method ..."

src/java.base/share/classes/javax/crypto/KEMSpi.java line 215:

> 213:      * @param pk the receiver's public key. This argument is never {@code null}.
> 214:      * @param spec the optional parameter, can be {@code null}
> 215:      * @param secureRandom the source of randomness for encapsulation,

s/encapsulation/encapsulation./

src/java.base/share/classes/javax/crypto/KEMSpi.java line 216:

> 214:      * @param spec the optional parameter, can be {@code null}
> 215:      * @param secureRandom the source of randomness for encapsulation,
> 216:      *                     If {@code null}, the implementation should provide

s/should/must/

src/java.base/share/classes/javax/crypto/KEMSpi.java line 231:

> 229:      * Creates a KEM decapsulator.
> 230:      * <p>
> 231:      * The caller of this method has already validated the parameters to

Similar comments as engineNewEncapsulator.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 236:

> 234:      *
> 235:      * @param sk the receiver's private key. This argument is never {@code null}.
> 236:      * @param spec the parameter, can be {@code null}

"the optional parameter, ..." (use same wording as engineNewEncapsulator).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164290210
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164290739
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164291396
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164294422
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164293863


From jiangli at openjdk.org  Wed Apr 12 17:18:25 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:18:25 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries [v2]
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

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

  Make loadSocketExtensionFuncs as a static function.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13438/files
  - new: https://git.openjdk.org/jdk/pull/13438/files/ea9627a4..321fa6d5

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

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

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


From alanb at openjdk.org  Wed Apr 12 17:18:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 17:18:25 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries [v2]
In-Reply-To: <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
Message-ID: <1Pt6vqYxxVPJktghuO6F0zs3GkvouCGooJI01F646ns=.607cfddb-bc96-4a45-b1de-8784fcbe33b4@github.com>

On Wed, 12 Apr 2023 17:13:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
>> 
>> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
>> 
>> (Sorry about the earlier RFR/Withdrawn noise.)
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make loadSocketExtensionFuncs as a static function.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13438#pullrequestreview-1381756250


From jiangli at openjdk.org  Wed Apr 12 17:18:28 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:18:28 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>
Message-ID: <om75cQes6jNcUdA-2halAkughrsM66mAvHRObbglBXg=.f0cfa614-7f19-442a-9014-d8baad899677@github.com>

On Wed, 12 Apr 2023 06:29:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay but it makes me wonder about loadSocketExtensionFuncs. Maybe we should remove that from Sctp.h and change loadSocketExtensionFuncs in SctpNet.c to be static.

Changed loadSocketExtensionFuncs to be static as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505628839


From alanb at openjdk.org  Wed Apr 12 17:18:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 17:18:28 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <om75cQes6jNcUdA-2halAkughrsM66mAvHRObbglBXg=.f0cfa614-7f19-442a-9014-d8baad899677@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>
 <om75cQes6jNcUdA-2halAkughrsM66mAvHRObbglBXg=.f0cfa614-7f19-442a-9014-d8baad899677@github.com>
Message-ID: <AYOdVScRdiBxHxQPQS6XaLkwx5cnRnvlsDFxZKiWAW8=.9d9beb7d-f868-46d6-aefd-368ed0eb2c40@github.com>

On Wed, 12 Apr 2023 17:09:26 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Changed loadSocketExtensionFuncs to be static as suggested.

Thanks, that avoids having inconsistent naming in the header file.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505632040


From jiangli at openjdk.org  Wed Apr 12 17:32:35 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:32:35 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries [v2]
In-Reply-To: <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
Message-ID: <x6ofs6Je8NeHpr37CUme8lTs8oCLRdd0PzbPISga7sQ=.fe4b3643-8572-48ae-8e75-f74ea9d2a797@github.com>

On Wed, 12 Apr 2023 17:18:25 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
>> 
>> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
>> 
>> (Sorry about the earlier RFR/Withdrawn noise.)
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make loadSocketExtensionFuncs as a static function.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505662956


From jiangli at openjdk.org  Wed Apr 12 17:38:34 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:38:34 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <kLWWNdDkdoeUNGpyPd-cGDVwEw7oYKMT5Jtc8YyZGPw=.56098905-b018-4455-b803-dc4d44c82cce@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <kLWWNdDkdoeUNGpyPd-cGDVwEw7oYKMT5Jtc8YyZGPw=.56098905-b018-4455-b803-dc4d44c82cce@github.com>
Message-ID: <BwomHkm6FvtLdnjwuxGvHF2frvkEO5EZA1OmjRcgesA=.fd78e15e-820d-4cd9-9576-f957be1fd648@github.com>

On Wed, 12 Apr 2023 03:26:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> I noticed there is a presubmit test failure: https://github.com/jianglizhou/jdk/actions/runs/4672962155#user-content-java_lang_thread_virtual_tracevirtualthreadlocals for linux-x86. It appears to be unrelated. Will file a bug tomorrow if there is not existing bug (will check before filing).

I found there is the existing https://bugs.openjdk.org/browse/JDK-8305875.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505670999


From weijun at openjdk.org  Wed Apr 12 18:31:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Apr 2023 18:31:35 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <ilyNqhJAvs6CxmwaBZJP4S-JwOzw2GKmjH3p0kr2HO0=.772db7d7-8b53-4632-8ee5-6d88cc041e25@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <ilyNqhJAvs6CxmwaBZJP4S-JwOzw2GKmjH3p0kr2HO0=.772db7d7-8b53-4632-8ee5-6d88cc041e25@github.com>
Message-ID: <1jGgNVmwW9lJktJrMoFAyA7ic8W-yIz40XPmmdoRmYE=.c00134d4-a8f1-4f8a-a0d9-a5117cb58590@github.com>

On Wed, 12 Apr 2023 13:22:48 GMT, Sean Mullan <mullan 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.
>
> src/java.base/share/classes/javax/crypto/DecapsulateException.java line 30:
> 
>> 28: 
>> 29: /**
>> 30:  * An {@link Exception} child class that is thrown by the
> 
> I would just say "An exception that is thrown by ..." The mentioning that it is a child class and the link to Exception seems unnecessary.

Sure.

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

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


From valeriep at openjdk.org  Wed Apr 12 18:31:36 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 12 Apr 2023 18:31:36 GMT
Subject: RFR: 8304845: COPYING in MUSCLE library includes incomplete
 license
In-Reply-To: <J2j0UU5HJ9pVqLxnkrobIJbiixlFJ4swcebOaI8TAUM=.41a836a7-c15b-45dd-a9d9-31c182dc6c7c@github.com>
References: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
 <J2j0UU5HJ9pVqLxnkrobIJbiixlFJ4swcebOaI8TAUM=.41a836a7-c15b-45dd-a9d9-31c182dc6c7c@github.com>
Message-ID: <0vsNL1nBF2FZdbudQQF3oOq8dIYngChVwMCnvp8KVfw=.29e64e78-4223-4a85-a001-858aed06cc3c@github.com>

On Wed, 12 Apr 2023 01:32:36 GMT, Man Cao <manc at openjdk.org> wrote:

>> Could someone please help review this fix? Besides updating the md and COPYING files to address the incomplete license issue, this PR also updates the version to 1.9.9.
>
> src/java.smartcardio/unix/native/libj2pcsc/MUSCLE/COPYING line 29:
> 
>> 27: 
>> 28: 
>> 29: Some source code files are using other licences. However, they are not included here and thus this file is a truncated version of the [COPYING](https://salsa.debian.org/rousseau/PCSC/-/blob/master/COPYING) file.
> 
> Nit: should be "licenses".

Sure, thanks for the review~

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13409#discussion_r1164500260


From weijun at openjdk.org  Wed Apr 12 18:35:37 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Apr 2023 18:35:37 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@github.com>
Message-ID: <VjQ938kBYjTNg9TtI1p6UrWwjY1mWqqhufhBE_oG8OU=.b2388fe5-fd03-47a4-ac87-e94b0b946a08@github.com>

On Wed, 12 Apr 2023 14:10:16 GMT, Xue-Lei Andrew Fan <xuelei 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.
>
> src/java.base/share/classes/javax/crypto/KEMSpi.java line 107:
> 
>> 105:      * @see KEM.Encapsulator
>> 106:      */
>> 107:     interface EncapsulatorSpi {
> 
> Is it really necessary to define a EncapsulatorSpi?  It looks like an internal implementation for KEMSpi service, rather than a public individual interface that EncapsulatorSpi.getInstance() could be used.

Not exactly sure what you want. Security providers need to implement it and the `KEM` class uses it. Unlike other `AbcSpi` classes, it will not be created with a `getInstance` method.

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

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


From valeriep at openjdk.org  Wed Apr 12 18:39:40 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 12 Apr 2023 18:39:40 GMT
Subject: RFR: 8304845: COPYING in MUSCLE library includes incomplete
 license [v2]
In-Reply-To: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
References: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
Message-ID: <teAe1iz0CJvcYBiYW1uiAyfJAMKCeh7jY_C_gNQk5uA=.2f47f526-a208-461a-a4a0-3c52b11a7564@github.com>

> Could someone please help review this fix? Besides updating the md and COPYING files to address the incomplete license issue, this PR also updates the version to 1.9.9.

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

  typo fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13409/files
  - new: https://git.openjdk.org/jdk/pull/13409/files/aec13c1b..a9151092

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

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

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


From weijun at openjdk.org  Wed Apr 12 18:45:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Apr 2023 18:45:08 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <vZjRV20pgiP4gpMwLQuMvXQs7b1FWFMLt72alz0UAlE=.a58966a9-b025-4b60-9376-461ae649f43b@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <vZjRV20pgiP4gpMwLQuMvXQs7b1FWFMLt72alz0UAlE=.a58966a9-b025-4b60-9376-461ae649f43b@github.com>
Message-ID: <flwh2hnCIrA0aRcITSjSTQsb1Ejpz-4cZjUN8u9Frjg=.16a3b2b7-0b1d-46d0-8b8b-505d755616af@github.com>

On Wed, 12 Apr 2023 14:44:10 GMT, Sean Mullan <mullan 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.
>
> src/java.base/share/classes/javax/crypto/KEMSpi.java line 39:
> 
>> 37:  * to implement a KEM algorithm.
>> 38:  * <p>
>> 39:  * A KEM algorithm may contain a family of configurations.
> 
> Would "support" instead of "contain" be better?

Good, I'll use it.

> src/java.base/share/classes/javax/crypto/KEMSpi.java line 45:
> 
>> 43:  * by the KEM algorithm name, the key it uses, and an optional
>> 44:  * {@code AlgorithmParameterSpec} argument when creating an encapsulator or
>> 45:  * decapsulator. The result of either {@link #engineNewDecapsulator} or
> 
> How about: "A configuration is defined by the ..." and "... argument that is specified when ..."
> 
> "The result of calling {@link #engineNewDecapsulator} or .."

Accepted.

> src/java.base/share/classes/javax/crypto/KEMSpi.java line 211:
> 
>> 209:      * The caller of this method has already validated the parameters to
>> 210:      * ensure that {@code pk} is not {@code null}. Therefore an implementation
>> 211:      * of this method does not to validate it.
> 
> s/not to/not need to/
> 
> Also, suggest saying who the caller is, "The caller (KEM.newEncapsulator) of this method ..."

Oops. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164510335
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164512159
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164513349


From jiangli at openjdk.org  Wed Apr 12 20:45:42 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 20:45:42 GMT
Subject: Integrated: 8305858: Resolve multiple definition of
 'handleSocketError' when statically linking with JDK native libraries
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <asZX78C5grsqQ68TEBBPkiR32FmTtkNu_vnC21j2jGw=.56bf211b-84ee-4249-9368-fc3dd0cd620e@github.com>

On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

This pull request has now been integrated.

Changeset: 2bbbff20
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bbbff209dc21633e08fe4d565dfc649eea2c883
Stats:     20 lines in 3 files changed: 0 ins; 4 del; 16 mod

8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

Reviewed-by: alanb

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

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


From xuelei at openjdk.org  Wed Apr 12 21:51:35 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Apr 2023 21:51:35 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <VjQ938kBYjTNg9TtI1p6UrWwjY1mWqqhufhBE_oG8OU=.b2388fe5-fd03-47a4-ac87-e94b0b946a08@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>
Message-ID: <ivHF3RYi0DRrtF5bUzgaO9heJDzz1Oyo2oykxRhAPMg=.06bedb57-6ea2-465e-9d69-5fa5fcc6a13e@github.com>

On Wed, 12 Apr 2023 18:32:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEMSpi.java line 107:
>> 
>>> 105:      * @see KEM.Encapsulator
>>> 106:      */
>>> 107:     interface EncapsulatorSpi {
>> 
>> Is it really necessary to define a EncapsulatorSpi?  It looks like an internal implementation for KEMSpi service, rather than a public individual interface that EncapsulatorSpi.getInstance() could be used.
>
> Not exactly sure what you want. Security providers need to implement it and the `KEM` class uses it. Unlike other `AbcSpi` classes, it will not be created with a `getInstance` method.

If I get it right, SPI means "service provider interface", which is normally for public service access by searching the registers.  In the provider implementation, a SPI implementation is normally registered so that it can be accessed.  I did not find the registration in the provider implementation.  I know it is right because it is not expected to be registered as it is not expected to be accessed directly.

> Security providers need to implement it and the KEM class uses it.
I know, but it is not necessarily designed as an SPI (it could be a normal interface that a provider need to implement and KEM class uses).  You can code like this, but I'm not sure if it is the common way.

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

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


From weijun at openjdk.org  Wed Apr 12 22:19:33 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Apr 2023 22:19:33 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <ivHF3RYi0DRrtF5bUzgaO9heJDzz1Oyo2oykxRhAPMg=.06bedb57-6ea2-465e-9d69-5fa5fcc6a13e@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>
Message-ID: <edE3OeRCUzw3f70HjFFi4S4-GW-ma0GOhEksI5m5q80=.55beeb17-ebdf-4426-abf8-2f08eaa33805@github.com>

On Wed, 12 Apr 2023 21:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Not exactly sure what you want. Security providers need to implement it and the `KEM` class uses it. Unlike other `AbcSpi` classes, it will not be created with a `getInstance` method.
>
> If I get it right, SPI means "service provider interface", which is normally for public service access by searching the registers.  In the provider implementation, a SPI implementation is normally registered so that it can be accessed.  I did not find the registration in the provider implementation.  I know it is right because it is not expected to be registered as it is not expected to be accessed directly.
> 
>> Security providers need to implement it and the KEM class uses it.
> I know, but it is not necessarily designed as an SPI (it could be a normal interface that a provider need to implement and KEM class uses).  You can code like this, but I'm not sure if it is the common way.

So you think the name is misleading?

Well, at the beginning there is only the `Encapsulator` interface inside `KEMSpi`, and the `Encapsulator` class in `KEM` implements it with an extra `provider()` method. However, I think this connection is unnecessary because the provider writers and application writers are completely separated and there is no need for one side to learn any knowledge of the other side. So I disconnect them but keep using the same names. But then if you want to talk about one you have to say which class it is in, and this could be confusing and sometimes wrong. Finally I decided to add the `Spi` suffix to them. Yes, it's a little different from the other SPI classes since it's not directly returned by `getInstance`. However, because of delayed provider selection, I believe it's precise to say it's only on the encapsulator and decapsulator level that the service itself is provided, and that's also why the `provider()` method is on this level. Think of this as the new style of SPI. :-)

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

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


From xuelei at openjdk.org  Wed Apr 12 23:02:34 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Apr 2023 23:02:34 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <edE3OeRCUzw3f70HjFFi4S4-GW-ma0GOhEksI5m5q80=.55beeb17-ebdf-4426-abf8-2f08eaa33805@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>
Message-ID: <JSqC_YvbJqpt1Q2lu89x66JVzjJlHcOwkl38Xi6ZaFc=.f94e184b-d77d-48c6-baa0-6435e1cd8c03@github.com>

On Wed, 12 Apr 2023 22:17:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> So you think the name is misleading?

Yes.

> But then if you want to talk about one you have to say which class it is in, and this could be confusing and sometimes wrong. 

I did not get the idea yet to define it in KEPSpi.  It looks like that only one interface in the KEM should be sufficient.  The interface implementation details could be provider based.  It is OK to have an provider implementation implements an interface internally.

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

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


From weijun at openjdk.org  Wed Apr 12 23:25:33 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Apr 2023 23:25:33 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <JSqC_YvbJqpt1Q2lu89x66JVzjJlHcOwkl38Xi6ZaFc=.f94e184b-d77d-48c6-baa0-6435e1cd8c03@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>
Message-ID: <BrStk_E-pBfLshWoKkHXnC0OEZOFUH8YsQaDDwbwORo=.0b09d034-02c1-4714-bb82-fe6836d29030@github.com>

On Wed, 12 Apr 2023 22:59:23 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> So you think the name is misleading?
>> 
>> Well, at the beginning there is only the `Encapsulator` interface inside `KEMSpi`, and the `Encapsulator` class in `KEM` implements it with an extra `provider()` method. However, I think this connection is unnecessary because the provider writers and application writers are completely separated and there is no need for one side to learn any knowledge of the other side. So I disconnect them but keep using the same names. But then if you want to talk about one you have to say which class it is in, and this could be confusing and sometimes wrong. Finally I decided to add the `Spi` suffix to them. Yes, it's a little different from the other SPI classes since it's not directly returned by `getInstance`. However, because of delayed provider selection, I believe it's precise to say it's only on the encapsulator and decapsulator level that the service itself is provided, and that's also why the `provider()` method is on this level. Think of this as the new style of SPI. :-)
>
>> So you think the name is misleading?
> 
> Yes.
> 
>> But then if you want to talk about one you have to say which class it is in, and this could be confusing and sometimes wrong. 
> 
> I did not get the idea yet to define it in KEPSpi.  It looks like that only one interface in the KEM should be sufficient.  The interface implementation details could be provider based.  It is OK to have an provider implementation implements an interface internally.

If the interface is only in `KEM`, then it needs a `provider()` method, but an implementation actually does not know what the provider is. An implementation can be registered in any (or even multiple) providers.

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

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


From xuelei at openjdk.org  Thu Apr 13 02:54:31 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Apr 2023 02:54:31 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <BrStk_E-pBfLshWoKkHXnC0OEZOFUH8YsQaDDwbwORo=.0b09d034-02c1-4714-bb82-fe6836d29030@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>
Message-ID: <hPjy5_EtYyXQgzDRwWywIrLcR9GWjkx07YOUs5ttkxU=.a8ae73fb-5fc7-4c5b-afc0-2d6f5f4c2a5e@github.com>

On Wed, 12 Apr 2023 23:23:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> If the interface is only in `KEM`, then it needs a `provider()` method, but an implementation actually does not know what the provider is.

With "implementation", do you mean the javax/crypto/KEPSpi.java or src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java?

If it is refer to KEPSpi.java, why KEPSpi.java need to know what the provider is?  Is it sufficient to use engineNewEncapsulator() to get the provider implementation?

If it is refer to DHKEM.java, I did not get the idea why the  provider is unknown.

> An implementation can be registered in any (or even multiple) providers.

I did not get the idea.  Why it is not registered in SunJCE?

I think you may have evaluated the following idea, but I'm not why it is not work.  I may missed something.  Would you mind explain in more details?


public final class KEM {
    interface Encapsulator {
        ...
        KEM.Encapsulated encapsulate(...);
        ...
    }

    public static KEM getInstance(String algorithm) {
        ...
    }

    // Search for the registered providers, return the 1st non-null provider.newEncapsulator() or throw exception.
    public Encapsulator newEncapsulator(PublicKey pk,
            AlgorithmParameterSpec spec, SecureRandom secureRandom)
        ...
    }
}

public interface KEMSpi {
    // A provider implementation will implement the KEM.Encapsulator 
    // interface internally.  If a provider does not support the parameters,
    // null or nil object will be returned.
    public KEM.Encapsulator newEncapsulator(PublicKey pk,
            AlgorithmParameterSpec spec, SecureRandom secureRandom);
}       

Use case:
    KEM.getInstance(DHKEM).newEncapsulator(...);

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

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


From duke at openjdk.org  Thu Apr 13 11:14:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 13 Apr 2023 11:14:49 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v4]
In-Reply-To: <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
Message-ID: <v55Y1aLhvm2H9UHod5bMrpxdspnE-pLMkJa71AXCbwc=.3e6e9386-f49c-4ddc-b2fd-0ec631f25c49@github.com>

On Thu, 9 Mar 2023 18:50:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused resource names 'This.option.is.forremoval' and 'using.an.alternative.signing.mechanism'

I see that the Release Note for this PR did not seem to get any review comments or edits. Probably it's ok, but perhaps a Reviewer could take an extra look anyway:

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

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

PR Comment: https://git.openjdk.org/jdk/pull/12791#issuecomment-1506780727


From weijun.wang at oracle.com  Thu Apr 13 12:18:04 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Thu, 13 Apr 2023 12:18:04 +0000
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v4]
In-Reply-To: <v55Y1aLhvm2H9UHod5bMrpxdspnE-pLMkJa71AXCbwc=.3e6e9386-f49c-4ddc-b2fd-0ec631f25c49@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
 <v55Y1aLhvm2H9UHod5bMrpxdspnE-pLMkJa71AXCbwc=.3e6e9386-f49c-4ddc-b2fd-0ec631f25c49@github.com>
Message-ID: <18C4A577-CE0E-4ED0-A37F-D2312C4A9AB4@oracle.com>

IIUC there is no place to add a reviewer's name. As long as you follow the steps in https://openjdk.org/guide/#release-notes, someone reviews it, and the state becomes Delivered, I think it's done.

Thanks,
Weijun

> On Apr 13, 2023, at 7:14 AM, Eirik Bjorsnos <duke at openjdk.org> wrote:
> 
> On Thu, 9 Mar 2023 18:50:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:
> 
>>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>>> 
>>> This PR suggests it's time to remove this code:
>>> 
>>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>>> - Mentions of the options in Resource files in the same directory is removed
>>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>> 
>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Remove unused resource names 'This.option.is.forremoval' and 'using.an.alternative.signing.mechanism'
> 
> I see that the Release Note for this PR did not seem to get any review comments or edits. Probably it's ok, but perhaps a Reviewer could take an extra look anyway:
> 
> https://bugs.openjdk.org/browse/JDK-8303536
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/12791#issuecomment-1506780727



From kdriver at openjdk.org  Thu Apr 13 15:40:08 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Apr 2023 15:40:08 GMT
Subject: RFR: 8305794: Unused interface sun.security.util.PermissionFactory can
 be removed
Message-ID: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>

All known implementors of this interface were removed in [JDK-8029886](https://bugs.openjdk.org/browse/JDK-8029886).

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

Commit messages:
 - removed unused interface

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

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


From kdriver at openjdk.org  Thu Apr 13 16:05:29 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Apr 2023 16:05:29 GMT
Subject: RFR: 8305794: Unused interface sun.security.util.PermissionFactory
 can be removed [v2]
In-Reply-To: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
References: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
Message-ID: <HRA45O-yeKhlHxmR6-PAqWkkQLbLR0l6cSxTFtU930I=.b174971a-a4b2-4228-b62f-3174afa7e6be@github.com>

> All known implementors of this interface were removed in [JDK-8029886](https://bugs.openjdk.org/browse/JDK-8029886).

Kevin Driver 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:

  JDK-8305794: removed unused interface

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13464/files
  - new: https://git.openjdk.org/jdk/pull/13464/files/1ef6c64b..cb6489d9

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

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

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


From kdriver at openjdk.org  Thu Apr 13 16:08:35 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Apr 2023 16:08:35 GMT
Subject: RFR: 8305794: Unused interface sun.security.util.PermissionFactory
 can be removed
In-Reply-To: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
References: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
Message-ID: <vslnrmy4tk8YXRPKaWsp0rv7FsSDFmz16P8Og8BDpEE=.106921ca-dffc-417b-836d-dd4be74ef58d@github.com>

On Thu, 13 Apr 2023 15:29:23 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> All known implementors of this interface were removed in [JDK-8029886](https://bugs.openjdk.org/browse/JDK-8029886).

> @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.

I just amended the commit message.

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

PR Comment: https://git.openjdk.org/jdk/pull/13464#issuecomment-1507225540


From mullan at openjdk.org  Thu Apr 13 16:36:02 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 16:36:02 GMT
Subject: RFR: 8305794: Unused interface sun.security.util.PermissionFactory
 can be removed [v2]
In-Reply-To: <HRA45O-yeKhlHxmR6-PAqWkkQLbLR0l6cSxTFtU930I=.b174971a-a4b2-4228-b62f-3174afa7e6be@github.com>
References: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
 <HRA45O-yeKhlHxmR6-PAqWkkQLbLR0l6cSxTFtU930I=.b174971a-a4b2-4228-b62f-3174afa7e6be@github.com>
Message-ID: <RAY6Jw2xIPs_jW756M2pLjuAWgjJgMSqfiQqTsbj8m4=.37bfd2d8-8d6e-4c26-b942-97fcb90b4fbc@github.com>

On Thu, 13 Apr 2023 16:05:29 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> All known implementors of this interface were removed in [JDK-8029886](https://bugs.openjdk.org/browse/JDK-8029886).
>
> Kevin Driver 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:
> 
>   JDK-8305794: removed unused interface

Looks fine. Please add a noreg label to the issue.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13464#pullrequestreview-1383810853


From aturbanov at openjdk.org  Thu Apr 13 16:49:56 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Apr 2023 16:49:56 GMT
Subject: RFR: 8305794: Unused interface sun.security.util.PermissionFactory
 can be removed [v2]
In-Reply-To: <HRA45O-yeKhlHxmR6-PAqWkkQLbLR0l6cSxTFtU930I=.b174971a-a4b2-4228-b62f-3174afa7e6be@github.com>
References: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
 <HRA45O-yeKhlHxmR6-PAqWkkQLbLR0l6cSxTFtU930I=.b174971a-a4b2-4228-b62f-3174afa7e6be@github.com>
Message-ID: <0GZdpvIns9q84dF9WTd3qlrxA6G-ndFx699Dm31sT98=.c0d18744-51e1-4dc3-898b-386bfccbb075@github.com>

On Thu, 13 Apr 2023 16:05:29 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> All known implementors of this interface were removed in [JDK-8029886](https://bugs.openjdk.org/browse/JDK-8029886).
>
> Kevin Driver 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:
> 
>   JDK-8305794: removed unused interface

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13464#pullrequestreview-1383833802


From mullan at openjdk.org  Thu Apr 13 16:57:51 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 16:57:51 GMT
Subject: RFR: 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: <QVhDx-58ms_6FlBb2QNKPB4geuSLhUEGwNKr2dSFlmg=.c8236583-c582-4120-b96b-10cc8d684c5e@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.

src/java.base/share/classes/javax/crypto/KEM.java line 36:

> 34: 
> 35: /**
> 36:  * The Key Encapsulation Mechanism.

How about a bit more here: "This class provides the functionality of a Key Encapsulation Mechanism (KEM). A KEM can be used to encrypt symmetric keys using asymmetric or public key cryptography."

src/java.base/share/classes/javax/crypto/KEM.java line 49:

> 47:  * or public key, and the optional {@code AlgorithmParameterSpec} object,
> 48:  * the {@code newEncapsulator} or {@code newDecapsulator} method
> 49:  * may return encapsulators or decapsulators from different providers. The user

This sentence is kind of long. Suggest breaking it up, ex: "If a provider is not specified in the {@code getInstance} method when  instantiating a {@code KEM} object,  the {@code newEncapsulator} and {@code newDecapsulator} method may return encapsulators or decapsulators from different providers. The provider selected is based on the parameters passed to the the {@code newEncapsulator} or {@code newDecapsulator} methods: the private or public key and the optional {@code AlgorithmParameterSpec}."

src/java.base/share/classes/javax/crypto/KEM.java line 50:

> 48:  * the {@code newEncapsulator} or {@code newDecapsulator} method
> 49:  * may return encapsulators or decapsulators from different providers. The user
> 50:  * can call the {@link Encapsulator#provider} or {@link Decapsulator#provider}

I would avoid referring to "The user". Suggest: "The {@link Encapsulator#provider} and {@link Decapsulator#provider} methods return the selected provider."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165787134
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165798901
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165800833


From weijun at openjdk.org  Thu Apr 13 17:12:43 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 17:12:43 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <hPjy5_EtYyXQgzDRwWywIrLcR9GWjkx07YOUs5ttkxU=.a8ae73fb-5fc7-4c5b-afc0-2d6f5f4c2a5e@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>
Message-ID: <M6an2C-rWAlx-1_j5__mlFxHfwc7qnUb6SO1PF-YtAs=.4e3e139a-7687-468e-b6d1-53e7e922445d@github.com>

On Thu, 13 Apr 2023 02:51:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> If the interface is only in `KEM`, then it needs a `provider()` method, but an implementation actually does not know what the provider is. An implementation can be registered in any (or even multiple) providers.
>
>> If the interface is only in `KEM`, then it needs a `provider()` method, but an implementation actually does not know what the provider is.
> 
> With "implementation", do you mean the javax/crypto/KEPSpi.java or src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java?
> 
> If it is refer to KEPSpi.java, why KEPSpi.java need to know what the provider is?  Is it sufficient to use engineNewEncapsulator() to get the provider implementation?
> 
> If it is refer to DHKEM.java, I did not get the idea why the  provider is unknown.
> 
>> An implementation can be registered in any (or even multiple) providers.
> 
> I did not get the idea.  Why it is not registered in SunJCE?
> 
> I think you may have evaluated the following idea, but I'm not why it is not work.  I may missed something.  Would you mind explain in more details?
> 
> 
> public final class KEM {
>     interface Encapsulator {
>         ...
>         KEM.Encapsulated encapsulate(...);
>         ...
>     }
> 
>     public static KEM getInstance(String algorithm) {
>         ...
>     }
> 
>     // Search for the registered providers, return the 1st non-null provider.newEncapsulator() or throw exception.
>     public Encapsulator newEncapsulator(PublicKey pk,
>             AlgorithmParameterSpec spec, SecureRandom secureRandom)
>         ...
>     }
> }
> 
> public interface KEMSpi {
>     // A provider implementation will implement the KEM.Encapsulator 
>     // interface internally.  If a provider does not support the parameters,
>     // null or nil object will be returned.
>     public KEM.Encapsulator newEncapsulator(PublicKey pk,
>             AlgorithmParameterSpec spec, SecureRandom secureRandom);
> }       
> 
> Use case:
>     KEM.getInstance(DHKEM).newEncapsulator(...);

`DHKEM.java` is the implementation, and it does not know which provider it will be put into. It's inside the provider that calls `putService` or `put` to add an implementation there, not that the implementation registered itself in a provider.

If `getProvider()` is implemented inside the implementation, then it can only be attached to one provider. Also, do you expect it to return `new SunJCE()`? This means the `p` in `getInstance("DHKEM", p)` will be a different instance from the value returned by `getProvider()`. There is no specification talking about if the instances must be the same or not, but it's probably not a good idea to have 2 objects for the same provider.

In fact, I can create a new provider and simply call `putService` to add existing implementations (that were already provided by other providers) inside it, and I can `getInstance` from this provider and its `getProvider()` returns this provider.

For this reason, the base `Encapsulator` interface cannot be defined inside `KEM`. As I said earlier, it can be defined inside `KEMSpi` and then we add an extra `provider()` method to its implementation in `KEM`. I just don't think this is worth doing.

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

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


From rhalade at openjdk.org  Thu Apr 13 17:17:51 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 13 Apr 2023 17:17:51 GMT
Subject: RFR: 8255548: Missing coverage for
 javax.xml.crypto.dom.DOMCryptoContext
In-Reply-To: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
References: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
Message-ID: <6wJGog41v82lesA6w1H4o7pLSbfvnDVdsBufyHsA3yk=.363b876a-5f21-4bb2-8ff4-c27abde7d99b@github.com>

On Wed, 12 Apr 2023 13:58:56 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Implemented tests for the `DomCryptoContext.iterator()` method.

LGTM. @seanjmullan let us know if you have any comments?

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

Marked as reviewed by rhalade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13445#pullrequestreview-1383875315


From mullan at openjdk.org  Thu Apr 13 17:24:38 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 17:24:38 GMT
Subject: RFR: 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: <zjzk5U_WOfvTkV4HBvocWyGCths41Thz-WELqHaHb2k=.f833c568-aa4b-4679-93e7-d2e2320ae868@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.

src/java.base/share/classes/javax/crypto/KEM.java line 430:

> 428:     /**
> 429:      * Returns a {@code KEM} object that implements the specified algorithm
> 430:      * and supports the specified {@code KEMParameterSpec} parameters

There are no parameters for this method.

src/java.base/share/classes/javax/crypto/KEM.java line 441:

> 439:      *                 to {@link #getInstance(String)}.
> 440:      * @return the new {@code KEM} object
> 441:      * @throws NoSuchAlgorithmException if no {@code Provider} supports a

This sounds like the provider argument is ignored. Maybe add some more words to take into account both cases "if a {@code provider} is specified and it does not support the specified KEM algorithm, or if {@code provider} is {@code null} and there is no provider that supports a KEM implementation of the  specified algorithm"

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

> 458:     /**
> 459:      * Returns a {@code KEM} object that implements the specified algorithm
> 460:      * and supports the specified {@code KEMParameterSpec} parameters

There are no parameters.

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

> 469:      *                 to {@link #getInstance(String)}.
> 470:      * @return the new {@code KEM} object
> 471:      * @throws NoSuchAlgorithmException if no {@code Provider} supports a

See above for similar comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165814719
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165816835
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165821821
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165822406


From weijun at openjdk.org  Thu Apr 13 17:24:39 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 17:24:39 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <zjzk5U_WOfvTkV4HBvocWyGCths41Thz-WELqHaHb2k=.f833c568-aa4b-4679-93e7-d2e2320ae868@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <zjzk5U_WOfvTkV4HBvocWyGCths41Thz-WELqHaHb2k=.f833c568-aa4b-4679-93e7-d2e2320ae868@github.com>
Message-ID: <L8hZ5Za0M8CP7RVHE-Kumen43YOKlS5rxRWlKan2c74=.71d26771-c205-403f-acb8-ec5e798d3c6c@github.com>

On Thu, 13 Apr 2023 17:08:44 GMT, Sean Mullan <mullan 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.
>
> src/java.base/share/classes/javax/crypto/KEM.java line 430:
> 
>> 428:     /**
>> 429:      * Returns a {@code KEM} object that implements the specified algorithm
>> 430:      * and supports the specified {@code KEMParameterSpec} parameters
> 
> There are no parameters for this method.

Oops, yes.

> src/java.base/share/classes/javax/crypto/KEM.java line 441:
> 
>> 439:      *                 to {@link #getInstance(String)}.
>> 440:      * @return the new {@code KEM} object
>> 441:      * @throws NoSuchAlgorithmException if no {@code Provider} supports a
> 
> This sounds like the provider argument is ignored. Maybe add some more words to take into account both cases "if a {@code provider} is specified and it does not support the specified KEM algorithm, or if {@code provider} is {@code null} and there is no provider that supports a KEM implementation of the  specified algorithm"

Correct. I must be copying text from the method without a provider argument.

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

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


From xuelei at openjdk.org  Thu Apr 13 17:37:36 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Apr 2023 17:37:36 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <M6an2C-rWAlx-1_j5__mlFxHfwc7qnUb6SO1PF-YtAs=.4e3e139a-7687-468e-b6d1-53e7e922445d@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>
Message-ID: <k8NSBsDNASYYZZ9POh3UynWRz15K18wAbfXJhpOTKZU=.a0ef70aa-61d5-4111-9170-63cd9f5013b0@github.com>

On Thu, 13 Apr 2023 17:10:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `DHKEM.java` is the implementation, and it does not know which provider it will be put into. It's inside the provider that calls `putService` or `put` to add an implementation there, not that the implementation registered itself in a provider.
> 
I did not get the idea.  Why DHKEM.java need register itself in a provider?  A DHKEM.java is a part of a provider, and the Provider implementation in the provider knows how to register DHKEM.

> If `getProvider()` is implemented inside the implementation, then it can only be attached to one provider. Also, do you expect it to return `new SunJCE()`? This means the `p` in `getInstance("DHKEM", p)` will be a different instance from the value returned by `getProvider()`. 

I did not get the idea.  How could it be possible to return different instances. `getInstance("DHKEM", p)` returns the DHKEM implementation in provider p.  The "DHKEM" string name here is not the DHKEM.java class in SunJCE provider.

Back to the question you have previously: 
> If the interface is only in KEM, then it needs a provider() method, but an implementation actually does not know what the provider is.

Why it is needed to know the provider of the interface?  Do you mean the Encapsulator provider could be different from the KEM provider?  That's, KEM provider is ProviderK, and the Encapsulator provider is ProviderE, and you want them work together?   Does it make sense that it is required that Encapsulator is an internal implementation of the KEM provider (i.e., both from the same provider)?

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

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


From weijun at openjdk.org  Thu Apr 13 17:57:43 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 17:57:43 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <k8NSBsDNASYYZZ9POh3UynWRz15K18wAbfXJhpOTKZU=.a0ef70aa-61d5-4111-9170-63cd9f5013b0@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>
Message-ID: <hWPmrjW9tEViQVGSuF0QAY7PniK8J0LVvKJ0fThcvJA=.a61eae44-a0ed-44c3-82c9-cf2e031d6581@github.com>

On Thu, 13 Apr 2023 17:35:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> `DHKEM.java` is the implementation, and it does not know which provider it will be put into. It's inside the provider that calls `putService` or `put` to add an implementation there, not that the implementation registered itself in a provider.
>> 
>> If `getProvider()` is implemented inside the implementation, then it can only be attached to one provider. Also, do you expect it to return `new SunJCE()`? This means the `p` in `getInstance("DHKEM", p)` will be a different instance from the value returned by `getProvider()`. There is no specification talking about if the instances must be the same or not, but it's probably not a good idea to have 2 objects for the same provider.
>> 
>> In fact, I can create a new provider and simply call `putService` to add existing implementations (that were already provided by other providers) inside it, and I can `getInstance` from this provider and its `getProvider()` returns this provider.
>> 
>> For this reason, the base `Encapsulator` interface cannot be defined inside `KEM`. As I said earlier, it can be defined inside `KEMSpi` and then we add an extra `provider()` method to its implementation in `KEM`. I just don't think this is worth doing.
>
>> `DHKEM.java` is the implementation, and it does not know which provider it will be put into. It's inside the provider that calls `putService` or `put` to add an implementation there, not that the implementation registered itself in a provider.
>> 
> I did not get the idea.  Why DHKEM.java need register itself in a provider?  A DHKEM.java is a part of a provider, and the Provider implementation in the provider knows how to register DHKEM.
> 
>> If `getProvider()` is implemented inside the implementation, then it can only be attached to one provider. Also, do you expect it to return `new SunJCE()`? This means the `p` in `getInstance("DHKEM", p)` will be a different instance from the value returned by `getProvider()`. 
> 
> I did not get the idea.  How could it be possible to return different instances. `getInstance("DHKEM", p)` returns the DHKEM implementation in provider p.  The "DHKEM" string name here is not the DHKEM.java class in SunJCE provider.
> 
> Back to the question you have previously: 
>> If the interface is only in KEM, then it needs a provider() method, but an implementation actually does not know what the provider is.
> 
> Why it is needed to know the provider of the interface?  Do you mean the Encapsulator provider could be different from the KEM provider?  That's, KEM provider is ProviderK, and the Encapsulator provider is ProviderE, and you want them work together?   Does it make sense that it is required that Encapsulator is an internal implementation of the KEM provider (i.e., both from the same provider)?

Currently, `provider()` is a method of `KEM.Encapsulator`. If `KEMSpi. newEncapsulator` also returns this interface, then what value should its `provider()` method return? This is what I meant registering itself to a provider.

When I said different instances, I was asking

var k = KEM.getInstance("DHKEM", p);
var e = k.newEncapsulator(pk);
// now, is p == e.provider()?


Or, are you suggesting we should define `provider()` somewhere else? It's possible, but I have difficulty making every class immutable.

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

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


From mullan at openjdk.org  Thu Apr 13 18:14:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 18:14:36 GMT
Subject: RFR: 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: <W2m2etvxDeQRFotc3WYGPkurKVo5sogWhCQPt7YOcqU=.d59eabe4-4544-44aa-9597-454fb7589fd6@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.

src/java.base/share/classes/javax/crypto/KEM.java line 1:

> 1: /*

Did you consider adding a `getAlgorithm` method? Most (all?) primitive classes contain this method.

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

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


From weijun at openjdk.org  Thu Apr 13 18:39:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 18:39:35 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <W2m2etvxDeQRFotc3WYGPkurKVo5sogWhCQPt7YOcqU=.d59eabe4-4544-44aa-9597-454fb7589fd6@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <W2m2etvxDeQRFotc3WYGPkurKVo5sogWhCQPt7YOcqU=.d59eabe4-4544-44aa-9597-454fb7589fd6@github.com>
Message-ID: <5BxTCY_2LcFvMhwL6-Q8Y1pdi0qwJh1xeG86PTKiBfE=.79e256bf-2218-437a-92e7-493c0827fdd9@github.com>

On Thu, 13 Apr 2023 18:12:09 GMT, Sean Mullan <mullan 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.
>
> src/java.base/share/classes/javax/crypto/KEM.java line 1:
> 
>> 1: /*
> 
> Did you consider adding a `getAlgorithm` method? Most (all?) primitive classes contain this method.

Yes, you're right. I'll add one.

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

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


From mullan at openjdk.org  Thu Apr 13 18:45:45 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 18:45:45 GMT
Subject: RFR: 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: <nCmzL0V4B89zUUMnqhO9hWHEOWmvu-3RPPMOZmeBAsw=.86ad83cc-d236-4e20-a2ae-4972f0b10f7a@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.

src/java.base/share/classes/javax/crypto/KEM.java line 493:

> 491:      * Creates a KEM encapsulator.
> 492:      * <p>
> 493:      * The method is equivalent to {@code newEncapsulator(pk, null, null)}.

s/The/This/

src/java.base/share/classes/javax/crypto/KEM.java line 500:

> 498:      * @throws NullPointerException if {@code pk} is {@code null}
> 499:      * @throws UnsupportedOperationException if this method is not supported
> 500:      *          and a {@code AlgorithmParameterSpec} must be provided

I would say "... because an {@code AlgorithmParameterSpec} must be provided".

src/java.base/share/classes/javax/crypto/KEM.java line 515:

> 513:      * Creates a KEM encapsulator.
> 514:      * <p>
> 515:      * The method is equivalent to {@code newEncapsulator(pk, null, secureRandom)}.

s/The/This/

src/java.base/share/classes/javax/crypto/KEM.java line 518:

> 516:      *
> 517:      * @param pk the receiver's public key, must not be {@code null}
> 518:      * @param secureRandom the source of randomness for encapsulation,

s/,/./

src/java.base/share/classes/javax/crypto/KEM.java line 519:

> 517:      * @param pk the receiver's public key, must not be {@code null}
> 518:      * @param secureRandom the source of randomness for encapsulation,
> 519:      *                     If {@code null}, the implementation should provide

s/should/must/

src/java.base/share/classes/javax/crypto/KEM.java line 556:

> 554:      * @param pk the receiver's public key, must not be {@code null}
> 555:      * @param spec the optional parameter, can be {@code null}
> 556:      * @param secureRandom the source of randomness for encapsulation,

s/,/./

src/java.base/share/classes/javax/crypto/KEM.java line 557:

> 555:      * @param spec the optional parameter, can be {@code null}
> 556:      * @param secureRandom the source of randomness for encapsulation,
> 557:      *                     If {@code null}, the implementation should provide

s/should/must/

src/java.base/share/classes/javax/crypto/KEM.java line 577:

> 575:      * Creates a KEM decapsulator.
> 576:      * <p>
> 577:      * The method is equivalent to {@code newDecapsulator(sk, null)}.

s/The/This/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165877912
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165882608
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165882987
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165883370
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165883547
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165886660
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165886977
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165884344


From kdriver at openjdk.org  Thu Apr 13 18:50:44 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Apr 2023 18:50:44 GMT
Subject: Integrated: 8305794: Unused interface
 sun.security.util.PermissionFactory can be removed
In-Reply-To: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
References: <hSJJwbXTlmAQ9Jn6iXtKc9TzH5VL1D4uvJcLO5R4p-0=.5ab404b2-7bd0-4b11-bdbb-d4b6de185856@github.com>
Message-ID: <8jNryV5c6fTaF5rgAkD77xD0I8ATEBdEGoem-Dw5BGw=.2d61a544-6d3e-401c-9050-8377ed30662c@github.com>

On Thu, 13 Apr 2023 15:29:23 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> All known implementors of this interface were removed in [JDK-8029886](https://bugs.openjdk.org/browse/JDK-8029886).

This pull request has now been integrated.

Changeset: b60604e8
Author:    Kevin Driver <kdriver at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b60604e8eb046b9d1ea81ba45328061945c8a29e
Stats:     36 lines in 1 file changed: 0 ins; 36 del; 0 mod

8305794: Unused interface sun.security.util.PermissionFactory can be removed

Co-authored-by: Andrey Turbanov <aturbanov at openjdk.org>
Reviewed-by: mullan, aturbanov

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

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


From weijun at openjdk.org  Thu Apr 13 18:51:37 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 18:51:37 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <nCmzL0V4B89zUUMnqhO9hWHEOWmvu-3RPPMOZmeBAsw=.86ad83cc-d236-4e20-a2ae-4972f0b10f7a@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <nCmzL0V4B89zUUMnqhO9hWHEOWmvu-3RPPMOZmeBAsw=.86ad83cc-d236-4e20-a2ae-4972f0b10f7a@github.com>
Message-ID: <riZy0-4U7e4hYv1wlxJZmAOirIAX_er6JxlTudFDiH4=.da08c631-6f33-4d32-9b7d-f396f3192298@github.com>

On Thu, 13 Apr 2023 18:21:51 GMT, Sean Mullan <mullan 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.
>
> src/java.base/share/classes/javax/crypto/KEM.java line 519:
> 
>> 517:      * @param pk the receiver's public key, must not be {@code null}
>> 518:      * @param secureRandom the source of randomness for encapsulation,
>> 519:      *                     If {@code null}, the implementation should provide
> 
> s/should/must/

This spec is not written for the implementor. How about "If {@code} null, a default one from the implementation will be used.".

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

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


From kdriver at openjdk.org  Thu Apr 13 18:57:22 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Apr 2023 18:57:22 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
Message-ID: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>

Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294985
  Stats: 6 lines in 1 file changed: 5 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 xuelei at openjdk.org  Thu Apr 13 19:03:45 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Apr 2023 19:03:45 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <hWPmrjW9tEViQVGSuF0QAY7PniK8J0LVvKJ0fThcvJA=.a61eae44-a0ed-44c3-82c9-cf2e031d6581@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>
Message-ID: <sXLJgnHB8eEGdQnRlYikjc6R6PzNMCYzMosdEyr25IY=.4ed97eb8-b954-4ccb-8ed6-381ad73f9245@github.com>

On Thu, 13 Apr 2023 17:54:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Currently, `provider()` is a method of `KEM.Encapsulator`. If `KEMSpi. newEncapsulator` also returns this interface, then what value should its `provider()` method return? This is what I meant registering itself to a provider.
> 
> When I said different instances, I was asking
> 
> ```
> var k = KEM.getInstance("DHKEM", p);
> var e = k.newEncapsulator(pk);
> // now, is p == e.provider()?
> ```
> 
> Or, are you suggesting we should define `provider()` somewhere else? It's possible, but I have difficulty making every class immutable.

If the provider() method in KEM.Encapsulator is the only reason, the cost to support it may be too high with so many duplicated/similar specifications/names and code.

Option 1: Remove the KEM.Encapsulator.provider() method, and provide no access to the underlying provider object.

>  do you expect it to return new SunJCE()? This means the p in getInstance("DHKEM", p) will be a different instance from the value returned by getProvider(). 

The Provider class is mutable, we may not want to change the provider object asked for "DHKEM".  I think you have used a solution to pass the provider object in the KEM.java implementation currently.  Maybe, it could be twitted a little bit so that the provider can be passed to a delegated KM.Encapsulator interface implementation.

Option 2:

public final class KEM {
    interface Encapsulator {
        ...
        KEM.Encapsulated encapsulate(...);
        ...
        
        default Provider provider() {
            return null;
        }
    }
    
    private static class DelegatedEncapsulator implements Encapsulator {
        private final Provider p;
        private DelegatedEncapsulator(Encapsulator e, Provider p) {
            this.p = p;
            ...
        } 
        public Provider provider() {
            return this.p;
        }
    }

    ...
          KEMSpi spi = (KEMSpi) service.newInstance(null);
          return new DelegatedEncapsulator(
                       spi.engineNewEncapsulator(pk, spec, secureRandom),  // This is the interface implementation, use the same provider as KEM.
                service.getProvider());    // This is the provider passed to the delegated KEM.Encapsulator object.
    ...
}

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

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


From mullan at openjdk.org  Thu Apr 13 20:00:33 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 20:00:33 GMT
Subject: RFR: 8255548: Missing coverage for
 javax.xml.crypto.dom.DOMCryptoContext
In-Reply-To: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
References: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
Message-ID: <03lm0MNqmKsx1kCDtf3PNqQdMfHz-JQdojhOtymb67M=.8407185a-8721-4471-a0dc-2f5b76d7e503@github.com>

On Wed, 12 Apr 2023 13:58:56 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Implemented tests for the `DomCryptoContext.iterator()` method.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13445#pullrequestreview-1384121238


From mullan at openjdk.org  Thu Apr 13 20:00:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 20:00:34 GMT
Subject: RFR: 8255548: Missing coverage for
 javax.xml.crypto.dom.DOMCryptoContext
In-Reply-To: <03lm0MNqmKsx1kCDtf3PNqQdMfHz-JQdojhOtymb67M=.8407185a-8721-4471-a0dc-2f5b76d7e503@github.com>
References: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
 <03lm0MNqmKsx1kCDtf3PNqQdMfHz-JQdojhOtymb67M=.8407185a-8721-4471-a0dc-2f5b76d7e503@github.com>
Message-ID: <sjBljtxIIvVGRlpX2Onllh6YNtyc2BkOeNvP9td31eg=.702c3241-3e84-4fd0-adef-16a7862eef41@github.com>

On Thu, 13 Apr 2023 19:57:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Implemented tests for the `DomCryptoContext.iterator()` method.
>
> Marked as reviewed by mullan (Reviewer).

> LGTM. @seanjmullan let us know if you have any comments?

LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/13445#issuecomment-1507535672


From jjg at openjdk.org  Thu Apr 13 20:30:03 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 13 Apr 2023 20:30:03 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <m4udm5H1KKWOFrFHbNbbof-gqipEvFbflX-l7-GTImE=.bf857f4e-b987-4eac-a675-aa5b23878cfb@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
 <m4udm5H1KKWOFrFHbNbbof-gqipEvFbflX-l7-GTImE=.bf857f4e-b987-4eac-a675-aa5b23878cfb@github.com>
Message-ID: <UGiiVD_nZK18Cul3Ww_GwNji8G26KplBEMoJV3EgAuw=.23e0116e-6701-4040-90b6-37bda7333df4@github.com>

On Thu, 6 Apr 2023 19:31:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> There are references to other specifications missing, like NIST Special Publication 800-90A Revision 1, referenced in `java.security.DrbgParameters`. I think there are others, I haven't done a thorough review yet. Will there be subsequent reviews for these, or should I point them out and have them resolved as part of this PR?

This should contain all the specs on spec sites that I know about, so if there are other specs that I missed, please indicate that, and we can either handle them here or in follow-up reviews. Your choice.

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

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


From stephen.farrell at cs.tcd.ie  Thu Apr 13 20:31:43 2023
From: stephen.farrell at cs.tcd.ie (Stephen Farrell)
Date: Thu, 13 Apr 2023 21:31:43 +0100
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <sXLJgnHB8eEGdQnRlYikjc6R6PzNMCYzMosdEyr25IY=.4ed97eb8-b954-4ccb-8ed6-381ad73f9245@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@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>
Message-ID: <99d85512-589b-fe62-b4ad-59bd37e8459c@cs.tcd.ie>


Hi,

Apologies for the interruption from the sidelines but I
have a query if that's ok.

Is there any relationship between this work and RFC1980
which defines HPKE, being a way of encrypting to a public
value using a KEM?

Reason to ask is HPKE is a mechanism that'll be needed for
TLS Encrypted Client Hello and the MLS protocol, so it'd
be a fine thing if these additions were suitable for that
too.

Cheers,
S.

PS: I implemented HPKE for OpenSSL so if there's interest
in supporting that here too, I'd be happy to help a bit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE4D8E9F997A833DD.asc
Type: application/pgp-keys
Size: 1197 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230413/a1b0f044/OpenPGP_0xE4D8E9F997A833DD.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230413/a1b0f044/OpenPGP_signature.sig>

From duke at openjdk.org  Thu Apr 13 20:40:47 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 13 Apr 2023 20:40:47 GMT
Subject: Integrated: 8255548: Missing coverage for
 javax.xml.crypto.dom.DOMCryptoContext
In-Reply-To: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
References: <eg_gzt4UL19XKqvk_1qvB2psmD8NUi-hJrOMOMuiwNk=.aa968b5d-bce3-4be3-910b-cdf1ce91f78f@github.com>
Message-ID: <IP1UTQ7hvU_6njLY0aRAEwc9Wf6ms5uSAzVnDrmeVy4=.010bb853-b240-4b5b-ab0d-59d604bc12fb@github.com>

On Wed, 12 Apr 2023 13:58:56 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Implemented tests for the `DomCryptoContext.iterator()` method.

This pull request has now been integrated.

Changeset: 76cda9f4
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76cda9f44a80b1979e6e1b7a21431ef631f80782
Stats:     46 lines in 1 file changed: 45 ins; 0 del; 1 mod

8255548: Missing coverage for javax.xml.crypto.dom.DOMCryptoContext

Reviewed-by: rhalade, mullan

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

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


From xuelei at openjdk.org  Thu Apr 13 21:46:38 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Apr 2023 21:46:38 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <sXLJgnHB8eEGdQnRlYikjc6R6PzNMCYzMosdEyr25IY=.4ed97eb8-b954-4ccb-8ed6-381ad73f9245@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>
Message-ID: <B83h3J_JdLSr_QRc-ExkESDe-pyOxzpjXvGk6zCQhJE=.6a331882-35a4-4ce8-8136-30a03a80aa05@github.com>

On Thu, 13 Apr 2023 19:01:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Currently, `provider()` is a method of `KEM.Encapsulator`. If `KEMSpi. newEncapsulator` also returns this interface, then what value should its `provider()` method return? This is what I meant registering itself to a provider.
>> 
>> When I said different instances, I was asking
>> 
>> var k = KEM.getInstance("DHKEM", p);
>> var e = k.newEncapsulator(pk);
>> // now, is p == e.provider()?
>> 
>> 
>> Or, are you suggesting we should define `provider()` somewhere else? It's possible, but I have difficulty making every class immutable.
>
>> Currently, `provider()` is a method of `KEM.Encapsulator`. If `KEMSpi. newEncapsulator` also returns this interface, then what value should its `provider()` method return? This is what I meant registering itself to a provider.
>> 
>> When I said different instances, I was asking
>> 
>> ```
>> var k = KEM.getInstance("DHKEM", p);
>> var e = k.newEncapsulator(pk);
>> // now, is p == e.provider()?
>> ```
>> 
>> Or, are you suggesting we should define `provider()` somewhere else? It's possible, but I have difficulty making every class immutable.
> 
> If the provider() method in KEM.Encapsulator is the only reason, the cost to support it may be too high with so many duplicated/similar specifications/names and code.
> 
> Option 1: Remove the KEM.Encapsulator.provider() method, and provide no access to the underlying provider object.
> 
>>  do you expect it to return new SunJCE()? This means the p in getInstance("DHKEM", p) will be a different instance from the value returned by getProvider(). 
> 
> The Provider class is mutable, we may not want to change the provider object asked for "DHKEM".  I think you have used a solution to pass the provider object in the KEM.java implementation currently.  Maybe, it could be twitted a little bit so that the provider can be passed to a delegated KM.Encapsulator interface implementation.
> 
> Option 2:
> 
> public final class KEM {
>     interface Encapsulator {
>         ...
>         KEM.Encapsulated encapsulate(...);
>         ...
>         
>         default Provider provider() {
>             return null;
>         }
>     }
>     
>     private static class DelegatedEncapsulator implements Encapsulator {
>         private final Provider p;
>         private DelegatedEncapsulator(Encapsulator e, Provider p) {
>             this.p = p;
>             ...
>         } 
>         public Provider provider() {
>             return this.p;
>         }
>     }
> 
>     ...
>           KEMSpi spi = (KEMSpi) service.newInstance(null);
>           return new DelegatedEncapsulator(
>                        spi.engineNewEncapsulator(pk, spec, secureRandom),  // This is the interface implementation, use the same provider as KEM.
>                 service.getProvider());    // This is the provider passed to the delegated KEM.Encapsulator object.
>     ...
> }

For more details about option 2, please refer to https://github.com/openjdk/jdk/pull/13470/files.  The KEM.java and KEMSpi.java is pretty much the same except the clean up of En/Decapsulator(s) in this PR.

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

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


From xuelei at openjdk.org  Thu Apr 13 21:52:39 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Apr 2023 21:52:39 GMT
Subject: RFR: 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: <4Rl87srCoqcWDcczqYgcDU9x9T5dPJ4M7o9KyxVHsEM=.c00d116f-89c7-40e5-8372-0c5ddbdb6b84@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.

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/javax/crypto/KEMSpi.java line 119:

> 117:          * of {@code from} and {@code to} are within the correct range.
> 118:          * Therefore an implementation of this method does not need to
> 119:          * validate them.

The KEM caller does validate the parameters, but the caller may be more widely other than the KEM.   Then, the statement here could be wrong at that time.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 172:

> 170:          * within the correct range. Therefore an implementation of this method
> 171:          * does not to validate them.
> 172:          *

Same comment as above.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 211:

> 209:      * The caller of this method has already validated the parameters to
> 210:      * ensure that {@code pk} is not {@code null}. Therefore an implementation
> 211:      * of this method does not to validate it.

Same as above, the caller may not validate the parameters yet.  For example, the instance could be accessed just like what you do in the KEM implementation manner (use Provider method and Service look-up APIs), but without validating the parameters as you did.

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

PR Review: https://git.openjdk.org/jdk/pull/13256#pullrequestreview-1384268215
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166059684
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166059934
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166061964


From mullan at openjdk.org  Thu Apr 13 22:22:50 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Apr 2023 22:22:50 GMT
Subject: RFR: 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: <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@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.

src/java.base/share/classes/javax/crypto/KEM.java line 79:

> 77: 
> 78:     /**
> 79:      * Type for the return value of the {@link Encapsulator#encapsulate} method.

I think the description should more generally describe what this is, maybe "The encapsulated data generated by a Key Encapsulation Mechanism (KEM), which includes the shared secret (as a SecretKey), the key encapsulation message, and additional optional parameters."

src/java.base/share/classes/javax/crypto/KEM.java line 94:

> 92:      * @see KEM#newEncapsulator(PublicKey, AlgorithmParameterSpec, SecureRandom)
> 93:      */
> 94:     public record Encapsulated(SecretKey key, byte[] encapsulation, byte[] params) {

We need to decide if the encapsulation array should be defensively cloned. I would lean towards cloning it since immutability is a feature of this API, and I think it would be surprising if this type was not. 

We can potentially switch to frozen arrays later.

src/java.base/share/classes/javax/crypto/KEM.java line 109:

> 107: 
> 108:     /**
> 109:      * A decapsulator, generated by {@link #newDecapsulator}.

See comments on Encapsulator about adding more description here.

src/java.base/share/classes/javax/crypto/KEM.java line 140:

> 138:          * @param encapsulation the key encapsulation message from the sender
> 139:          * @return the shared secret as a {@code SecretKey} with
> 140:          *          algorithm being "Generic", not {@code null}

suggest "with an algorithm name of "Generic"  ..."

src/java.base/share/classes/javax/crypto/KEM.java line 150:

> 148: 
> 149:         /**
> 150:          * The key decapsulation function.

See encapsulate for similar comments.

src/java.base/share/classes/javax/crypto/KEM.java line 155:

> 153:          * @param from the initial index of the shared secret to be returned, inclusive
> 154:          * @param to the final index of the shared secret to be returned, exclusive.
> 155:          * @param algorithm the algorithm for the secret key returned

Suggest: " ... algorithm name of the secret key that is returned" (or generated)

src/java.base/share/classes/javax/crypto/KEM.java line 168:

> 166:          *          is not supported by the decapsulator
> 167:          */
> 168:         public SecretKey decapsulate(byte[] encapsulation,

WDYT about throwing IllegalArgumentException if the size of encapsulation is not equal to encapsulationSize()?

If not, I think you should add a sentence to the @param encapsulation such as "The size must be equal to ..., or a DecapsulateException will be thrown."

src/java.base/share/classes/javax/crypto/KEM.java line 193:

> 191: 
> 192:         /**
> 193:          * Returns the size of the key encapsulation message.

I think both the `secretSize` and `encapsulationSize` methods could use a sentence or two explaining why they are useful. This will help both users understand when they might need to call them and implementors  to implement them correctly.

src/java.base/share/classes/javax/crypto/KEM.java line 206:

> 204: 
> 205:     /**
> 206:      * An encapsulator, generated by {@link #newEncapsulator}.

Can you add more description here? "An encapsulator, generated by {@link #newEncapsulator}. This class represents the key encapsulation function of a KEM. Each invocation of the {@link encapsulate} method generates a new secret key and key encapsulation message that is returned in an {@link Encapsulated} object."

src/java.base/share/classes/javax/crypto/KEM.java line 223:

> 221:          * Returns the provider.
> 222:          *
> 223:          * @return thr provider

s/thr/the/

src/java.base/share/classes/javax/crypto/KEM.java line 230:

> 228: 
> 229:         /**
> 230:          * The key encapsulation function.

I think you should include this text in both encapsulate methods: "Each invocation of this method generates a new secret key and key encapsulation message that is returned in an {@link Encapsulated} object."

src/java.base/share/classes/javax/crypto/KEM.java line 238:

> 236:          * @return an {@link KEM.Encapsulated} object containing the full
> 237:          *          shared secret as a key with algorithm being "Generic",
> 238:          *          the key encapsulation message, and optional parameters.

Maybe break up into two sentences: "an {@link KEM.Encapsulated} object containing the shared secret, key encapsulation message, and optional parameters. The shared secret is a {@code SecretKey} containing all of the bytes of the secret, and an algorithm name of "Generic".

src/java.base/share/classes/javax/crypto/KEM.java line 246:

> 244: 
> 245:         /**
> 246:          * The key encapsulation function.

I think it would be useful to add a sentence explaining when this method would be useful.

src/java.base/share/classes/javax/crypto/KEM.java line 248:

> 246:          * The key encapsulation function.
> 247:          *
> 248:          * @param from the initial index of the shared secret to be returned, inclusive

Should you say the index is the index of the byte array? "... the initial index of the shared secret byte array ..."

src/java.base/share/classes/javax/crypto/KEM.java line 249:

> 247:          *
> 248:          * @param from the initial index of the shared secret to be returned, inclusive
> 249:          * @param to the final index of the shared secret to be returned, exclusive.

omit period to be consistent

src/java.base/share/classes/javax/crypto/KEM.java line 250:

> 248:          * @param from the initial index of the shared secret to be returned, inclusive
> 249:          * @param to the final index of the shared secret to be returned, exclusive.
> 250:          * @param algorithm the algorithm for the secret key returned

Suggest: "the algorithm name of the secret key that is returned" (or maybe "generated")

src/java.base/share/classes/javax/crypto/KEM.java line 253:

> 251:          * @return an {@link KEM.Encapsulated} object containing a portion of
> 252:          *          the shared secret as a key with the specified algorithm,
> 253:          *          the key encapsulation message, and optional parameters.

See comment above about splitting into 2 sentences.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166026177
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166037807
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166009690
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166010704
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166011839
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166012724
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166020023
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166022013
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165988842
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165989666
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165991209
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165997956
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166000074
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1165999651
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166004651
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166005900
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166006297


From weijun at openjdk.org  Thu Apr 13 22:29:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 22:29:34 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@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:

  spec change, getAlgorithm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/e953d9ec..8a227daf

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

  Stats: 72 lines in 3 files changed: 20 ins; 3 del; 49 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 Apr 13 22:35:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 22:35:40 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
Message-ID: <KPYJUqXMeR4m9GAUK4Y7g6bYmXlb1qMSicMppEWtnD8=.b77bce11-6530-443d-8f47-41faedb1f6dd@github.com>

On Thu, 13 Apr 2023 22:29:34 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:
> 
>   spec change, getAlgorithm

> _Mailing list message from [Stephen Farrell](mailto:stephen.farrell at cs.tcd.ie) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> Hi,
> 
> Apologies for the interruption from the sidelines but I have a query if that's ok.
> 
> Is there any relationship between this work and RFC1980 which defines HPKE, being a way of encrypting to a public value using a KEM?

We know about HPKE, and it can makes use of the DHKEM implementation here (if the AuthEncap/AuthDecap functions are not used). However, we (Oracle's Java SE Security Team) don't have a plan to include HPKE inside OpenJDK yet.

This PR is mainly about adding the KEM SPI so 3rd security providers can implement other KEM algorithms. DHKEM is included mainly to prove that the API is usable.

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

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


From weijun at openjdk.org  Thu Apr 13 22:38:37 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Apr 2023 22:38:37 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <4Rl87srCoqcWDcczqYgcDU9x9T5dPJ4M7o9KyxVHsEM=.c00d116f-89c7-40e5-8372-0c5ddbdb6b84@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <4Rl87srCoqcWDcczqYgcDU9x9T5dPJ4M7o9KyxVHsEM=.c00d116f-89c7-40e5-8372-0c5ddbdb6b84@github.com>
Message-ID: <HjEDcdSQVwVuWuwXKYCXCTSJSaIlzDaBjboHhEUb2P0=.c96c5df0-2c59-4bc3-87af-d9ee8981c266@github.com>

On Thu, 13 Apr 2023 21:46:22 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spec change, getAlgorithm
>
> src/java.base/share/classes/javax/crypto/KEMSpi.java line 119:
> 
>> 117:          * of {@code from} and {@code to} are within the correct range.
>> 118:          * Therefore an implementation of this method does not need to
>> 119:          * validate them.
> 
> The KEM caller does validate the parameters, but the caller may be more widely other than the KEM.   Then, the statement here could be wrong at that time.

I can rewrite this into something like "The caller of this method must validate..." so it becomes a requirement. We'll make sure the `KEM` class follows it. Any other class that wishes to call it directly must do it as well.

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

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


From stephen.farrell at cs.tcd.ie  Fri Apr 14 00:27:23 2023
From: stephen.farrell at cs.tcd.ie (Stephen Farrell)
Date: Fri, 14 Apr 2023 01:27:23 +0100
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <KPYJUqXMeR4m9GAUK4Y7g6bYmXlb1qMSicMppEWtnD8=.b77bce11-6530-443d-8f47-41faedb1f6dd@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
 <KPYJUqXMeR4m9GAUK4Y7g6bYmXlb1qMSicMppEWtnD8=.b77bce11-6530-443d-8f47-41faedb1f6dd@github.com>
Message-ID: <e3906f0a-b16e-9f56-fd64-43dc09c0d821@cs.tcd.ie>


Hiya,

On 13/04/2023 23:35, Weijun Wang wrote:

>> Apologies for the interruption from the sidelines but I have a
>> query if that's ok.
>> 
>> Is there any relationship between this work and RFC1980 which
>> defines HPKE, being a way of encrypting to a public value using a
>> KEM?
> 
> We know about HPKE, 

Of course:-)

> and it can makes use of the DHKEM implementation
> here (if the AuthEncap/AuthDecap functions are not used).

FWIW, I'm not aware of any protocol yet attempting to make
use of the authenticated HPKE modes, so that seems very
reasonable. (OTOH, it's not that hard for a library to
support all modes, so it may be worth some consideration.)

> However, we
> (Oracle's Java SE Security Team) don't have a plan to include HPKE
> inside OpenJDK yet.

Entirely fair. If doing so is of interest (to you or others),
I'd be happy to try help. (Ping me on/off-list if that is of
interest.)

> This PR is mainly about adding the KEM SPI so 3rd security providers
> can implement other KEM algorithms. DHKEM is included mainly to prove
> that the API is usable.

Grand. I'll get out of the way of this thread so:-) But
again, if interested, do reach out, as I'm keen to see ECH
support ending up widespread and HPKE is a fine precursor
for that.

Cheers,
S.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE4D8E9F997A833DD.asc
Type: application/pgp-keys
Size: 1197 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230414/418fe369/OpenPGP_0xE4D8E9F997A833DD.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230414/418fe369/OpenPGP_signature.sig>

From weijun at openjdk.org  Fri Apr 14 00:45:39 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 00:45:39 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
Message-ID: <J5YWmwZB2yDr6iSoJyekzGiVwsRAPfowsMzXC13ylc4=.6173874e-1fda-4f01-96c0-1abf238abe13@github.com>

On Thu, 13 Apr 2023 20:35:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spec change, getAlgorithm
>
> src/java.base/share/classes/javax/crypto/KEM.java line 246:
> 
>> 244: 
>> 245:         /**
>> 246:          * The key encapsulation function.
> 
> I think it would be useful to add a sentence explaining when this method would be useful.

Then at the same time I should add a sentence to the usage of the other method. However, it's a little difficult to describe it if KDF is not defined yet.

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

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


From weijun at openjdk.org  Fri Apr 14 00:52:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 00:52:51 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
Message-ID: <vlkkzMEJltlOS-26oR7wXNChmTvpYR_TocBwa-vFAmw=.0e505346-c29c-45ea-bb51-e69bdb63e54a@github.com>

On Thu, 13 Apr 2023 20:59:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spec change, getAlgorithm
>
> src/java.base/share/classes/javax/crypto/KEM.java line 168:
> 
>> 166:          *          is not supported by the decapsulator
>> 167:          */
>> 168:         public SecretKey decapsulate(byte[] encapsulation,
> 
> WDYT about throwing IllegalArgumentException if the size of encapsulation is not equal to encapsulationSize()?
> 
> If not, I think you should add a sentence to the @param encapsulation such as "The size must be equal to ..., or a DecapsulateException will be thrown."

I'll choose the latter.

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

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


From xuelei at openjdk.org  Fri Apr 14 02:02:36 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 14 Apr 2023 02:02:36 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <HjEDcdSQVwVuWuwXKYCXCTSJSaIlzDaBjboHhEUb2P0=.c96c5df0-2c59-4bc3-87af-d9ee8981c266@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <4Rl87srCoqcWDcczqYgcDU9x9T5dPJ4M7o9KyxVHsEM=.c00d116f-89c7-40e5-8372-0c5ddbdb6b84@github.com>
 <HjEDcdSQVwVuWuwXKYCXCTSJSaIlzDaBjboHhEUb2P0=.c96c5df0-2c59-4bc3-87af-d9ee8981c266@github.com>
Message-ID: <HqfIY7foJ0lQvhXO6Au9f7R1Vuz2Ct_7XHrm41VxSW0=.de8fd166-d86d-4e88-8544-f250892dea6f@github.com>

On Thu, 13 Apr 2023 22:36:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEMSpi.java line 119:
>> 
>>> 117:          * of {@code from} and {@code to} are within the correct range.
>>> 118:          * Therefore an implementation of this method does not need to
>>> 119:          * validate them.
>> 
>> The KEM caller does validate the parameters, but the caller may be more widely other than the KEM.   Then, the statement here could be wrong at that time.
>
> I can rewrite this into something like "The caller of this method must validate..." so it becomes a requirement. We'll make sure the `KEM` class follows it. Any other class that wishes to call it directly must do it as well.

You can make it a required part of the specification.  But it is a error-prone design.

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

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


From wetmore at openjdk.org  Fri Apr 14 04:35:39 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 14 Apr 2023 04:35:39 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <ziZXdrvk6c4peJnksEdAyWX9cH0d5xdRRnQTdmE0E24=.ab299bf6-5943-43ae-821a-9d137902fec6@github.com>

On Thu, 13 Apr 2023 18:49:48 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Please update the copyright date to include "2022, 2023,"

Otherwise, LGTM.

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

Marked as reviewed by wetmore (Reviewer).

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


From xuelei at openjdk.org  Fri Apr 14 05:03:39 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 14 Apr 2023 05:03:39 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <rjITB-PgTG3J0mRNKl_Z735VL8KJkCsLfSWrENaDl-k=.f09bbfee-bdf1-412f-9a3d-eea6b436c3e4@github.com>

On Thu, 13 Apr 2023 18:49:48 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Is [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) in JBS a closed bug?

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

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


From wetmore at openjdk.org  Fri Apr 14 05:10:34 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 14 Apr 2023 05:10:34 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: <pIAgd90HZULenLPxOFuq6VZdWfWZs0l4oKgUIHfOMTQ=.84f00548-51f8-4982-984e-ae8785f26c54@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

I'm coming to this late, but what is the breadth of the specs you're trying to call out?  Where did you obtain this list?  Are all of these changes coming from existing mentions in the current APIs, and you're just adding a `@spec` in various places?   Or are you trying to be complete, or just list a representative sample?   In part 1, I saw you moved some of the spec mentions to be in a `@spec`, but in this PR, you're adding specs in the APIs.

In many of our APIs, we mention things "...such as...RFC 2246...", but we make no effort to be complete by providing a list of specs.

For example:

SSLEngine.java:  only TLSv1.0 was mentioned, but there's also SSLv3/1.1/1.2/1.3, and DTLS 1.0/1.2.

SSLSocket.java:  your change only lists 7301, but not 2246.  But same issue as SSLEngine, there are others specs this also applies to.

java.security.Key.java:  RFC 5280 was the only spec called out.  There are many other Key types.

SecureRandom:  RFC 4086 was called out.  There are others.

If you want to mention a bunch of the security specs, I think we need to better understand the scope of what you're trying to do, and how this will be kept in sync with Chapter 4 of the Security Documentation (Providers):  which also could use some updates-e.g. TLSv1.x RFCs, but that is another RFE for another day.

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

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


From mbaesken at openjdk.org  Fri Apr 14 06:48:34 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Apr 2023 06:48:34 GMT
Subject: RFR: 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: <gpAgcEwj0qGEuQ85fxtXVX1gsGCHUXZgRf_iWD0lBpM=.0d659901-146f-46e1-9f4f-7416bb473e2d@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 .

Hi Weijun, here I found an example from Apple OpenSource 
https://opensource.apple.com/source/Security/Security-59754.80.3/OSX/libsecurity_keychain/lib/SecTrustSettings.cpp.auto.html
and
https://opensource.apple.com/source/Security/Security-57740.51.3/trust/SecTrustSettingsPriv.h.auto.html

they have there a " wrapper around SecTrustSettingsCopyCertificates that combines user and admin domain outputs."
(SecTrustSettingsCopyCertificatesForUserAdminDomains).   Seems at least those 2 domains need to be considered.
That#s what I found also in some other projects (e.g. Go).

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

PR Comment: https://git.openjdk.org/jdk/pull/12829#issuecomment-1508008557


From eirbjo at gmail.com  Fri Apr 14 12:00:42 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 14 Apr 2023 14:00:42 +0200
Subject: Could we backport the default SSLSession.getPeerCertificateChain
 method to 11?
Message-ID: <CA+pBWhsWsVQHiQc_cLBm_wiZWWPX8MaHUR-FmmdJ7OGA8w8MqQ@mail.gmail.com>

Hi,

I've been reaching out to various open source projects in an effort to
reduce the ecosystem risk of removing the javax.security.cert package, see
JDK-8227024 [1].

I contributed a patch to Tomcat, which was accepted, but not backported to
versions running on Java 11. Since Java 11 does not have the default
implementation for SSLSession.getPeerCertificateChain, any implementation
not overriding this method would give a compilation error.

We observe a similar situation in JBoss Undertow/Wildfly, where my PR to
remove javax.security.cert compiles fine under Java 17, but fails to
compile on Java 11:

SNISSLEngine.java:[211,69] error: <anonymous
> io.undertow.protocols.ssl.SNISSLEngine$InitialState$1> is not abstract and
> does not override abstract method getPeerCertificateChain() in SSLSession


So I was wondering if at all it would be possible to backport the
default SSLSession.getPeerCertificateChain method to 11? It seems this
would help the ecosystem move forward in reducing the dependency on
javax.security.cert.

What would the compatibility concerns for such a backport be? Is it at all
possible? The method was deprecated in Java 9, for-removal in Java 13.

Thanks,
Eirik.

[1] https://bugs.openjdk.org/browse/JDK-8227024
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230414/46913fda/attachment.htm>

From mullan at openjdk.org  Fri Apr 14 13:42:49 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Apr 2023 13:42:49 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
Message-ID: <CxJi-KDqF97yK_d9Y31ZkF1n_B8cYBI__ga-1frGK5U=.defe89f1-2269-4beb-aa57-6433eab5c024@github.com>

On Thu, 13 Apr 2023 22:29:34 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:
> 
>   spec change, getAlgorithm

src/java.base/share/classes/javax/crypto/KEM.java line 49:

> 47:  * If a provider is not specified in the {@code getInstance} method when
> 48:  * instantiating a {@code KEM} object, the {@code newEncapsulator} and
> 49:  * {@code newDecapsulator} method may return encapsulators or decapsulators

s/method/methods/

src/java.base/share/classes/javax/crypto/KEM.java line 51:

> 49:  * {@code newDecapsulator} method may return encapsulators or decapsulators
> 50:  * from different providers. The provider selected is based on the parameters
> 51:  * passed to the the {@code newEncapsulator} or {@code newDecapsulator} methods:

s/the the/the/

src/java.base/share/classes/javax/crypto/KEM.java line 54:

> 52:  * the private or public key and the optional {@code AlgorithmParameterSpec}.
> 53:  * The {@link Encapsulator#provider} and {@link Decapsulator#provider} methods
> 54:  * return the selected provider."

remove "".

src/java.base/share/classes/javax/crypto/KEM.java line 103:

> 101:          * @param key the shared secret as a key, must not be {@code null}.
> 102:          * @param encapsulation the key encapsulation message, must not be {@code null}.
> 103:          * @param params additional parameters, can be {@code null}.

Nit: remove periods.

src/java.base/share/classes/javax/crypto/KEM.java line 105:

> 103:          * @param params additional parameters, can be {@code null}.
> 104:          */
> 105:         public Encapsulated {

Should this also have an `@throws NullPointerException` clause?

src/java.base/share/classes/javax/crypto/KEM.java line 128:

> 126:          * Returns the provider.
> 127:          *
> 128:          * @return thr provider

s/thr/the/

src/java.base/share/classes/javax/crypto/KEM.java line 143:

> 141:          * @param encapsulation the key encapsulation message from the sender
> 142:          * @return the shared secret as a {@code SecretKey} with
> 143:          *          algorithm being "Generic", not {@code null}

See my comment below, I don't think you need to specify that this does not return null, it should be implied.

src/java.base/share/classes/javax/crypto/KEM.java line 160:

> 158:          * @param algorithm the algorithm for the secret key returned
> 159:          * @return a portion of the shared secret as a {@code SecretKey} with
> 160:          *          the specified algorithm, not {@code null}

Same comment as above.

src/java.base/share/classes/javax/crypto/KEM.java line 242:

> 240:          *          shared secret as a key with algorithm being "Generic",
> 241:          *          the key encapsulation message, and optional parameters.
> 242:          *          The return value should not be {@code null}.

"should" means it *could* still return null. I assume that is not what we want. Although I would be more inclined to only specify cases where null may be returned, and if it isn't mentioned, then it should be implied that null is not a legal return value. If in doubt, perhaps check with Joe/CCC for advice when you file the CSR.

This general comment applies to the other return types in this API where you say "not null". I think you can omit those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166801682
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166802062
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166802596
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166808093
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166811613
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166826429
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166829885
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166830271
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166841781


From weijun at openjdk.org  Fri Apr 14 14:16:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 14:16:40 GMT
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <e3906f0a-b16e-9f56-fd64-43dc09c0d821@cs.tcd.ie>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <e3906f0a-b16e-9f56-fd64-43dc09c0d821@cs.tcd.ie>
Message-ID: <XFoKFMfPfpZaRy1gF_-4zOGKykDA8V40SLHlfnti_TA=.71fe87af-3a9b-4268-a05f-e0564fbe90b7@github.com>

On Fri, 14 Apr 2023 08:18:16 GMT, Stephen Farrell <stephen.farrell at cs.tcd.ie> wrote:

> Grand. I'll get out of the way of this thread so:-) But
> again, if interested, do reach out, as I'm keen to see ECH
> support ending up widespread and HPKE is a fine precursor
> for that.

Thanks a lot. I'll remember that.

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

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


From weijun at openjdk.org  Fri Apr 14 14:23:41 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 14:23:41 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <CxJi-KDqF97yK_d9Y31ZkF1n_B8cYBI__ga-1frGK5U=.defe89f1-2269-4beb-aa57-6433eab5c024@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
 <CxJi-KDqF97yK_d9Y31ZkF1n_B8cYBI__ga-1frGK5U=.defe89f1-2269-4beb-aa57-6433eab5c024@github.com>
Message-ID: <TOImpg-bF0OZpJVNLzyCDWI0BlOYuSnbpuwqEh6Qb64=.954ecb37-d4ae-4e6d-a8f5-033392231a63@github.com>

On Fri, 14 Apr 2023 13:32:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spec change, getAlgorithm
>
> src/java.base/share/classes/javax/crypto/KEM.java line 242:
> 
>> 240:          *          shared secret as a key with algorithm being "Generic",
>> 241:          *          the key encapsulation message, and optional parameters.
>> 242:          *          The return value should not be {@code null}.
> 
> "should" means it *could* still return null. I assume that is not what we want. Although I would be more inclined to only specify cases where null may be returned, and if it isn't mentioned, then it should be implied that null is not a legal return value. If in doubt, perhaps check with Joe/CCC for advice when you file the CSR.
> 
> This general comment applies to the other return types in this API where you say "not null". I think you can omit those.

I do mean "must not be null". Maybe I can ask Joe directly.

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

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


From weijun at openjdk.org  Fri Apr 14 14:36:45 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 14:36:45 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
Message-ID: <g8zEGhdpDGNlLGuUtuXdnP9kbC4uzqFLfEZ_mrMHNjA=.598437b2-8195-48c2-937a-c148bbb7475c@github.com>

On Thu, 13 Apr 2023 21:20:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spec change, getAlgorithm
>
> src/java.base/share/classes/javax/crypto/KEM.java line 94:
> 
>> 92:      * @see KEM#newEncapsulator(PublicKey, AlgorithmParameterSpec, SecureRandom)
>> 93:      */
>> 94:     public record Encapsulated(SecretKey key, byte[] encapsulation, byte[] params) {
> 
> We need to decide if the encapsulation and params arrays should be defensively cloned. I would lean towards cloning it since immutability is a feature of this API, and I think it would be surprising if this type was not. 
> 
> We can potentially switch to frozen arrays later.

If we need to clone defensively I'll switch back to normal class, and then we can clone in both the constructor and the getters. IMO records are meant to be deadly simple.

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

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


From kevin.driver at oracle.com  Fri Apr 14 14:55:50 2023
From: kevin.driver at oracle.com (Kevin Driver)
Date: Fri, 14 Apr 2023 14:55:50 +0000
Subject: RFR: 8297878: KEM: Implementation
In-Reply-To: <a0f3de00-e5a3-fbbc-6ce7-525451e1db26@oracle.com>
References: <99d85512-589b-fe62-b4ad-59bd37e8459c@cs.tcd.ie>
 <a0f3de00-e5a3-fbbc-6ce7-525451e1db26@oracle.com>
Message-ID: <2691FA71-274F-4864-96FA-FDA5392E0169@oracle.com>

Some interesting side discussion here. I wanted to chime in to point out that HPKE is built upon the ?primitives? of KEM and HKDF. As mentioned on the list, KEM is underway. I am also spearheading our effort reviving the HKDF JEP<https://bugs.openjdk.org/browse/JDK-8189808> which has gone a bit stale.

HPKE is certainly something we?re looking into as well. Once the building blocks of KEM and HKDF are in place, HPKE will ramp up next.

Kevin Driver
Mobile: +1.512.431.5690
Java Security Libraries

Subject: Re: RFR: 8297878: KEM: Implementation
Date: Thu, 13 Apr 2023 21:31:43 +0100
From: Stephen Farrell <stephen.farrell at cs.tcd.ie>
To: Xue-Lei Andrew Fan <xuelei at openjdk.org>, security-dev at openjdk.org


Hi,

Apologies for the interruption from the sidelines but I
have a query if that's ok.

Is there any relationship between this work and RFC1980
which defines HPKE, being a way of encrypting to a public
value using a KEM?

Reason to ask is HPKE is a mechanism that'll be needed for
TLS Encrypted Client Hello and the MLS protocol, so it'd
be a fine thing if these additions were suitable for that
too.

Cheers,
S.

PS: I implemented HPKE for OpenSSL so if there's interest
in supporting that here too, I'd be happy to help a bit.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230414/0efa22f3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE4D8E9F997A833DD.asc
Type: application/pgp-keys
Size: 1221 bytes
Desc: OpenPGP_0xE4D8E9F997A833DD.asc
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230414/0efa22f3/OpenPGP_0xE4D8E9F997A833DD.asc>

From weijun at openjdk.org  Fri Apr 14 15:04:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 15:04:40 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <B83h3J_JdLSr_QRc-ExkESDe-pyOxzpjXvGk6zCQhJE=.6a331882-35a4-4ce8-8136-30a03a80aa05@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>
Message-ID: <N_7guPY4IKbVc3_2f7SQDf1KSOSXrUL7fIcn2T5ZuBk=.73250f06-f78c-4a68-a689-98db0af22881@github.com>

On Thu, 13 Apr 2023 21:43:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> Currently, `provider()` is a method of `KEM.Encapsulator`. If `KEMSpi. newEncapsulator` also returns this interface, then what value should its `provider()` method return? This is what I meant registering itself to a provider.
>>> 
>>> When I said different instances, I was asking
>>> 
>>> ```
>>> var k = KEM.getInstance("DHKEM", p);
>>> var e = k.newEncapsulator(pk);
>>> // now, is p == e.provider()?
>>> ```
>>> 
>>> Or, are you suggesting we should define `provider()` somewhere else? It's possible, but I have difficulty making every class immutable.
>> 
>> If the provider() method in KEM.Encapsulator is the only reason, the cost to support it may be too high with so many duplicated/similar specifications/names and code.
>> 
>> Option 1: Remove the KEM.Encapsulator.provider() method, and provide no access to the underlying provider object.
>> 
>>>  do you expect it to return new SunJCE()? This means the p in getInstance("DHKEM", p) will be a different instance from the value returned by getProvider(). 
>> 
>> The Provider class is mutable, we may not want to change the provider object asked for "DHKEM".  I think you have used a solution to pass the provider object in the KEM.java implementation currently.  Maybe, it could be twitted a little bit so that the provider can be passed to a delegated KM.Encapsulator interface implementation.
>> 
>> Option 2:
>> 
>> public final class KEM {
>>     interface Encapsulator {
>>         ...
>>         KEM.Encapsulated encapsulate(...);
>>         ...
>>         
>>         default Provider provider() {
>>             return null;
>>         }
>>     }
>>     
>>     private static class DelegatedEncapsulator implements Encapsulator {
>>         private final Provider p;
>>         private DelegatedEncapsulator(Encapsulator e, Provider p) {
>>             this.p = p;
>>             ...
>>         } 
>>         public Provider provider() {
>>             return this.p;
>>         }
>>     }
>> 
>>     ...
>>           KEMSpi spi = (KEMSpi) service.newInstance(null);
>>           return new DelegatedEncapsulator(
>>                        spi.engineNewEncapsulator(pk, spec, secureRandom),  // This is the interface implementation, use the same provider as KEM.
>>                 service.getProvider());    // This is the provider passed to the delegated KEM.Encapsulator object.
>>     ...
>> }
>
> For more details about option 2, please refer to https://github.com/openjdk/jdk/pull/13470/files.  The KEM.java and KEMSpi.java is pretty much the same except the clean up of En/Decapsulator(s) in this PR.

I see. So the security providers are told:
1. Don't implement `provider()` (If you do, we won't look at it)
2. Do validate parameters on your own (because no one else does)

Let me think about it. I can even ask a security provider what their opinion is.

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

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


From xuelei at openjdk.org  Fri Apr 14 15:45:44 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 14 Apr 2023 15:45:44 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <N_7guPY4IKbVc3_2f7SQDf1KSOSXrUL7fIcn2T5ZuBk=.73250f06-f78c-4a68-a689-98db0af22881@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>
Message-ID: <YBjgVCncT9koFcVMIFsws18mQe8oKzFc4yNx6KzrKsw=.9faa1118-d00a-4736-ba9a-ca63f34e4407@github.com>

On Fri, 14 Apr 2023 15:00:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 2. Do validate parameters on your own (because no one else does)
> 
I would say: validate the parameters on your own, because not everyone else does.

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

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


From weijun at openjdk.org  Fri Apr 14 16:25:39 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 16:25:39 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <YBjgVCncT9koFcVMIFsws18mQe8oKzFc4yNx6KzrKsw=.9faa1118-d00a-4736-ba9a-ca63f34e4407@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>
Message-ID: <LvnyLNDnIDmfWT4KyzlRfXe1ljCbUM9QEyD7vKkN5dI=.119644cf-99b4-45b4-a5bb-020be5743679@github.com>

On Fri, 14 Apr 2023 15:42:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I see. So the security providers are told:
>> 1. Don't implement `provider()` (If you do, we won't look at it)
>> 2. Do validate parameters on your own (because no one else does)
>> 
>> Let me think about it. I can even ask a security provider what their opinion is.
>
>> 2. Do validate parameters on your own (because no one else does)
>> 
> I would say: validate the parameters on your own, because not everyone else does.

I added another proposal in you PR at https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798.

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

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


From xuelei at openjdk.org  Fri Apr 14 16:36:41 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 14 Apr 2023 16:36:41 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <LvnyLNDnIDmfWT4KyzlRfXe1ljCbUM9QEyD7vKkN5dI=.119644cf-99b4-45b4-a5bb-020be5743679@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>
Message-ID: <UFgMmvt8ugD3exa6OWVFbsVGByYpKEfmWMjsJ2l5pr4=.930fc1e8-e451-44a5-a7d3-39832c17f6c3@github.com>

On Fri, 14 Apr 2023 16:23:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> 2. Do validate parameters on your own (because no one else does)
>>> 
>> I would say: validate the parameters on your own, because not everyone else does.
>
> 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.

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

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


From weijun at openjdk.org  Fri Apr 14 16:54:49 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Apr 2023 16:54:49 GMT
Subject: RFR: 8297878: KEM: Implementation [v3]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <-a9sn7ro1yid9nsdJr45IZdWtsjTArWnF9uLYsEtzHg=.8f09208b-4503-4ffa-b27e-5a39c8c8d79e@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:

  spec changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/8a227daf..b398b03e

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

  Stats: 169 lines in 4 files changed: 106 ins; 19 del; 44 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  Fri Apr 14 18:47:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Apr 2023 18:47:44 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
Message-ID: <ToViuvnJq8M9ZdCmMzWJjzY103mQDGYcyI3bZBGUjCA=.bd56fd5f-3792-4bb5-ac59-df39f4e08d19@github.com>

On Thu, 13 Apr 2023 22:29:34 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:
> 
>   spec change, getAlgorithm

src/java.base/share/classes/javax/crypto/KEM.java line 78:

> 76:  *    assert Arrays.equals(k1.getEncoded(), k2.getEncoded());
> 77:  * }
> 78:  */

Missing an `@since 21`.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 45:

> 43:  * {@code AlgorithmParameterSpec} argument that is specified when creating
> 44:  * an encapsulator or decapsulator. The result of calling
> 45:  * {@link #engineNewDecapsulator} or {@link #engineNewDecapsulator} must be of

First one should be engineNewEncapsulator.

Also, maybe say "... must return an encapsulator or decapsulator that maps to a single configuration, ..."

src/java.base/share/classes/javax/crypto/KEMSpi.java line 47:

> 45:  * {@link #engineNewDecapsulator} or {@link #engineNewDecapsulator} must be of
> 46:  * a single configuration, where its {@link EncapsulatorSpi#engineSecretSize()}
> 47:  * and {@link EncapsulatorSpi#engineEncapsulationSize()} are constants.

Maybe change "are constants" to "methods return constant values."

src/java.base/share/classes/javax/crypto/KEMSpi.java line 54:

> 52:  * <p>
> 53:  * {@code EncapsulatorSpi} and {@code DecapsulatorSpi} implementations must
> 54:  * be immutable. It must be safe to invoke multiple {@code encapsulate} and

suggest "... must also be immutable."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166869294
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166871954
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166885398
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1166887194


From kdriver at openjdk.org  Fri Apr 14 19:03:16 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Apr 2023 19:03:16 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v2]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <uwDmlKbnovbFGsg4OZT_oRLyPSZoyn4taGQ6cqFL9j4=.27760720-9ced-444a-8df4-ac8475451cb9@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:

  updated copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/df4fbebc..d4a73407

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

  Stats: 1 line in 1 file changed: 0 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  Fri Apr 14 19:03:19 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Apr 2023 19:03:19 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v2]
In-Reply-To: <ziZXdrvk6c4peJnksEdAyWX9cH0d5xdRRnQTdmE0E24=.ab299bf6-5943-43ae-821a-9d137902fec6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <ziZXdrvk6c4peJnksEdAyWX9cH0d5xdRRnQTdmE0E24=.ab299bf6-5943-43ae-821a-9d137902fec6@github.com>
Message-ID: <7xCQHBv5bhK-i7vwE5fzURaHsG1jLbBRpar7WKPolkg=.3fb52f2e-6f59-497a-846b-567e678d4530@github.com>

On Fri, 14 Apr 2023 04:33:15 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Please update the copyright date to include "2022, 2023,"
> 
> Otherwise, LGTM.

Fixed in https://github.com/openjdk/jdk/pull/13466/commits/d4a7340718dcdb769ad5eb6c8708e43284c14548.

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

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


From sean.mullan at oracle.com  Fri Apr 14 19:18:00 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Apr 2023 15:18:00 -0400
Subject: Could we backport the default SSLSession.getPeerCertificateChain
 method to 11?
In-Reply-To: <CA+pBWhsWsVQHiQc_cLBm_wiZWWPX8MaHUR-FmmdJ7OGA8w8MqQ@mail.gmail.com>
References: <CA+pBWhsWsVQHiQc_cLBm_wiZWWPX8MaHUR-FmmdJ7OGA8w8MqQ@mail.gmail.com>
Message-ID: <cce165c4-a797-3752-07aa-a0f6268592c8@oracle.com>

Hi Eirik,

On 4/14/23 8:00 AM, Eirik Bj?rsn?s wrote:
> Hi,
> 
> I've been reaching out to various open source projects in an effort to 
> reduce the ecosystem risk of removing the javax.security.cert package, 
> see JDK-8227024 [1].
> 
> I contributed a patch to Tomcat, which was accepted, but not backported 
> to versions running on Java 11. Since Java 11 does not have the default 
> implementation for?SSLSession.getPeerCertificateChain, any 
> implementation not overriding this method would give a compilation error.
> 
> We observe a similar situation in JBoss Undertow/Wildfly, where my PR to 
> remove javax.security.cert compiles fine under Java 17, but fails to 
> compile on Java 11:
> 
>     SNISSLEngine.java:[211,69] error: <anonymous
>     io.undertow.protocols.ssl.SNISSLEngine$InitialState$1> is not
>     abstract and does not override abstract method
>     getPeerCertificateChain() in SSLSession
> 
> 
> So I was wondering if at all it would be possible to backport the 
> default?SSLSession.getPeerCertificateChain method to 11? It seems this 
> would help the ecosystem move forward in reducing the dependency on 
> javax.security.cert.

In order to backport that change to Java SE 11, an MR (Maintenance 
Release of Java SE) would be required. See the CSR [1] for more details, 
which has a scope of SE.

There is an MR for Java SE 11 that is in progress [2]. Unfortunately, it 
is too late and this issue is not critical enough to justify it being 
added at this point.

> 
> What would the compatibility concerns for such a backport be? Is it at 
> all possible? The method was deprecated in Java 9, for-removal in Java 13.

Not possible right now AFAICT, but I will keep it in mind as a candidate 
API change for the next MR, if and when that may occur.

--Sean

[1] https://bugs.openjdk.org/browse/JDK-8241047
[2] https://jcp.org/en/jsr/detail?id=384

> 
> Thanks,
> Eirik.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8227024 
> <https://bugs.openjdk.org/browse/JDK-8227024>
> 
> 


From jjg at openjdk.org  Fri Apr 14 20:12:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 14 Apr 2023 20:12:34 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <pIAgd90HZULenLPxOFuq6VZdWfWZs0l4oKgUIHfOMTQ=.84f00548-51f8-4982-984e-ae8785f26c54@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
 <pIAgd90HZULenLPxOFuq6VZdWfWZs0l4oKgUIHfOMTQ=.84f00548-51f8-4982-984e-ae8785f26c54@github.com>
Message-ID: <0uQtS932l0j2dzw4f8mn4uiPznDPfSNNUixv9UoS8bI=.9a6d465e-b3cd-487d-a7b3-5c108fb14c1e@github.com>

On Fri, 14 Apr 2023 05:07:18 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedback
>
> I'm coming to this late, but what is the breadth of the specs you're trying to call out?  Where did you obtain this list?  Are all of these changes coming from existing mentions in the current APIs, and you're just adding a `@spec` in various places?   Or are you trying to be complete, or just list a representative sample?   In part 1, I saw you moved some of the spec mentions to be in a `@spec`, but in this PR, you're adding specs in the APIs.
> 
> In many of our APIs, we mention things "...such as...RFC 2246...", but we make no effort to be complete by providing a list of specs.
> 
> For example:
> 
> SSLEngine.java:  only TLSv1.0 was mentioned, but there's also SSLv3/1.1/1.2/1.3, and DTLS 1.0/1.2.
> 
> SSLSocket.java:  your change only lists 7301, but not 2246.  But same issue as SSLEngine, there are others specs this also applies to.
> 
> java.security.Key.java:  RFC 5280 was the only spec called out.  There are many other Key types.
> 
> SecureRandom:  RFC 4086 was called out.  There are others.
> 
> If you want to mention a bunch of the security specs, I think we need to better understand the scope of what you're trying to do, and how this will be kept in sync with Chapter 4 of the Security Documentation (Providers):  which also could use some updates-e.g. TLSv1.x RFCs, but that is another RFE for another day.

@bradfordwetmore 
> I'm coming to this late, but what is the breadth of the specs you're trying to call out? 

This is a mostly automated update based on existing references to well-known specifications.  

* **Mostly automated** means it was done by a custom utility program, but I hand-edited the output to improve line-wrapping, etc.
* **Existing references** means found in `<a href=...>` in the same doc comment to which the `@spec` is added, where that HTML link may appear in either narrative text or in a `@see` tag
* **Well-known specifications** means that the utility was looking for well-known hosts/urls. The list of the hosts that was used is `ietf.org`, `unicode.org`, `w3.org`, `iana.org`, `iso.org`, and references to the sibling `specs` directory that exists beside the main `api` directory.  While those are the hosts, the pattern matching was more specific to singleton URLs or groups of URLs at each site.

The update uses "normative"/"preferred" URLs for each spec, to avoid the variety of different URLs used for some of the specs, reflecting _different_ hosts and/or paths for the _same_ specification.
The goal is just to add these `@spec` tags without any semantic change to the specification. As such, no CSR is required for this work.

If there are additional `@spec` tags that should be added for existing references, I can do that here in this PR, or in followup work. It has already been noted that I missed the references to `nist.gov`.

If there are additional specifications that should be included (that are not currently mentioned) that is a task for the relevant developers in the relevant component teams. I would expect any such work to be done separately, later.

It is also a future-goal to clean up the existing `href` references to the same general form of URL as given in the `@spec` tag, thus normalizing the host and path that we use for each specification (or the root of a multi-page specification.). 

The effect of the `@spec` tags is to list the specifications for a declaration in a list headed `External Specifications`, similar to the existing `See Also` list.  Eventually, we will enable a new summary page headed `External Specifications` that lists all the specs listed in `@spec` tags, providing links to where the specs are mentioned. That page is currently temporarily disabled until we have a more complete set of `@spec` tags in most or all modules.  Using the canonical form of spec URLs and titles in `@spec` tags, and having the cross-referenced list on that new `External Specifications` page should make it easier to find and maintain these references going forward.

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

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


From cslucas at openjdk.org  Fri Apr 14 20:54:45 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 14 Apr 2023 20:54:45 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v8]
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: <Mf1vAYk5EpwlcuZ2P1Nj8WjjtD0Mh9IWFvt0Tl69tPE=.8a27d12b-61c2-49fa-adbe-48b4e91974a4@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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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 3. Some comments and be able to abort compilation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/8ed147f4..a10b0a4c

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

  Stats: 118 lines in 13 files changed: 60 ins; 11 del; 47 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 Apr 14 20:54:48 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 14 Apr 2023 20:54:48 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <Fco8XVAwjuZJoOaK-fb7UzAu3y9utPQk17D6ncUAH6E=.f097a54d-8883-42f7-b81a-2a7b423511d5@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <Fco8XVAwjuZJoOaK-fb7UzAu3y9utPQk17D6ncUAH6E=.f097a54d-8883-42f7-b81a-2a7b423511d5@github.com>
Message-ID: <lolqjMiNtN45uvnBHAais5xsCOzKam6LhVJ-a1WXHi4=.9c2cfece-3bd4-40da-8db1-4872d91d77db@github.com>

On Fri, 31 Mar 2023 18:30:19 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>
> src/hotspot/share/opto/escape.cpp line 457:
> 
>> 455:         found_sr_allocate = true;
>> 456:       } else {
>> 457:         ptn->set_scalar_replaceable(false);
> 
> This member function is const. Do we really need to change ptn's property here? 
> 
> My reading is ophi is profitable as long as we spot any input object which can be eliminated.  how about you just return at line 455?

This is actually necessary here. By setting the input to NSR I don't need to later, when performing reduction, check that I can eliminate the node. I can just check that I can scalar replace the input. If I removed this line I'd hit a problem if the merge had an input that is SR but that ME can't eliminate.

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

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


From cslucas at openjdk.org  Fri Apr 14 20:56:39 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 14 Apr 2023 20:56:39 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <xeGxSTB0GhzgnN1EwPutxShuPnGXh5bbBUs1w28_f64=.d1eadc8e-e78f-41d3-b8b3-823493f01ce6@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <xeGxSTB0GhzgnN1EwPutxShuPnGXh5bbBUs1w28_f64=.d1eadc8e-e78f-41d3-b8b3-823493f01ce6@github.com>
Message-ID: <qL62NYDRxIztfcuwc7DuJIIEnY4st2AEM8-X2-zQFkY=.3231257a-9b01-40c7-97dc-30add2aafe63@github.com>

On Fri, 24 Mar 2023 16:40:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> You new test failed in GHA testing with 32-bit VM: `Could not find VM flag "UseCompressedOops" in @IR rule 1 at int`.
> You need to adjust next rule: `@IR(counts = { IRNode.ALLOC, "2" }, applyIf = { "UseCompressedOops", "false" })`

@vnkozlov - I think I addressed all your comments. Please let me know if I missed something or if there is something on that you think need to be improved.

@iwanowww - can I ask you to please take a look and let me know what you think?

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

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


From kvn at openjdk.org  Fri Apr 14 21:49:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Apr 2023 21:49:36 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v8]
In-Reply-To: <Mf1vAYk5EpwlcuZ2P1Nj8WjjtD0Mh9IWFvt0Tl69tPE=.8a27d12b-61c2-49fa-adbe-48b4e91974a4@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Mf1vAYk5EpwlcuZ2P1Nj8WjjtD0Mh9IWFvt0Tl69tPE=.8a27d12b-61c2-49fa-adbe-48b4e91974a4@github.com>
Message-ID: <1pTfg6PGb3zu3ndvKYt0FSFmkOA01w9qLFtQ_s1BQbE=.7de234bc-5484-4d98-a003-ff86836922b9@github.com>

On Fri, 14 Apr 2023 20:54:45 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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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 3. Some comments and be able to abort compilation.

Nice. I will test it.

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

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1386210380


From valeriep at openjdk.org  Fri Apr 14 22:00:30 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Apr 2023 22:00:30 GMT
Subject: RFR: 8305336: java.security.debug=sunpkcs11 breaks PKCS#11
 configuration with slotListIndex
Message-ID: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>

Could someone help review this trivial fix?

Inside the debugging block, the slot list variable "slots" is overridden with slots with tokens, this causes problem when trying to access the slot list with slotListIndex configuration option. Fix is to print out the slot with tokens info w/o storing it into the slot list variable.

Thanks,
Valerie

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

Commit messages:
 - 8305336: java.security.debug=sunpkcs11 breaks PKCS#11 configuration with slotListIndex

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

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


From mpowers at openjdk.org  Fri Apr 14 23:13:32 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 14 Apr 2023 23:13:32 GMT
Subject: RFR: 8305336: java.security.debug=sunpkcs11 breaks PKCS#11
 configuration with slotListIndex
In-Reply-To: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>
References: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>
Message-ID: <UjpEBdNtyPjYeR1uD1F_yHKx3B0WjaCVaSMb7w6hde4=.dbb2650f-2f67-41e2-a2c6-46c5b6d438ee@github.com>

On Fri, 14 Apr 2023 21:53:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this trivial fix?
> 
> Inside the debugging block, the slot list variable "slots" is overridden with slots with tokens, this causes problem when trying to access the slot list with slotListIndex configuration option. Fix is to print out the slot with tokens info w/o storing it into the slot list variable.
> 
> Thanks,
> Valerie

LGTM

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

Marked as reviewed by mpowers (Author).

PR Review: https://git.openjdk.org/jdk/pull/13483#pullrequestreview-1386253261


From kvn at openjdk.org  Sat Apr 15 00:20:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 15 Apr 2023 00:20:36 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v8]
In-Reply-To: <Mf1vAYk5EpwlcuZ2P1Nj8WjjtD0Mh9IWFvt0Tl69tPE=.8a27d12b-61c2-49fa-adbe-48b4e91974a4@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Mf1vAYk5EpwlcuZ2P1Nj8WjjtD0Mh9IWFvt0Tl69tPE=.8a27d12b-61c2-49fa-adbe-48b4e91974a4@github.com>
Message-ID: <egFiUX18gxHTK7vDPXekBEkmxr-MoJG4jtZQKxwwWfo=.9c1e6c40-7601-4f5d-88c6-c9903ca295b7@github.com>

On Fri, 14 Apr 2023 20:54:45 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 that are 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 in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) 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 straight forward: 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 tested 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 3. Some comments and be able to abort compilation.

New test failed in tier1 on all platforms. Here is list:

1) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.TestTrapAfterMerge(boolean,int,int)" - [Failed IR rules: 1]:
2) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testCondLoadAfterMerge(boolean,boolean,int,int)" - [Failed IR rules: 1]:
3) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testLoadInCondAfterMerge(boolean,int,int)" - [Failed IR rules: 1]:
4) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testMergesAndMixedEscape(boolean,int,int)" - [Failed IR rules: 1]:
5) Method "compiler.c2.irTests.scalarReplacement.AllocationMergesTests$Point[] compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testNestedObjectsArray(boolean,int,int)" - [Failed IR rules: 1]:
6) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testNestedObjectsNoEscapeObject(boolean,int,int)" - [Failed IR rules: 1]:
7) Method "compiler.c2.irTests.scalarReplacement.AllocationMergesTests$Point compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testNestedObjectsObject(boolean,int,int)" - [Failed IR rules: 1]:

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

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


From weijun at openjdk.org  Sat Apr 15 01:40:33 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 15 Apr 2023 01:40:33 GMT
Subject: RFR: 8305336: java.security.debug=sunpkcs11 breaks PKCS#11
 configuration with slotListIndex
In-Reply-To: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>
References: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>
Message-ID: <ss2knAU6zakNtklj4UaDBodc5Dj0oDAjwd5_E0pZUzM=.1cb268f5-5c81-437b-a904-1bad5d67b06f@github.com>

On Fri, 14 Apr 2023 21:53:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this trivial fix?
> 
> Inside the debugging block, the slot list variable "slots" is overridden with slots with tokens, this causes problem when trying to access the slot list with slotListIndex configuration option. Fix is to print out the slot with tokens info w/o storing it into the slot list variable.
> 
> Thanks,
> Valerie

Marked as reviewed by weijun (Reviewer).

I suggest using `noreg-trivial`.

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

PR Review: https://git.openjdk.org/jdk/pull/13483#pullrequestreview-1386287620
PR Comment: https://git.openjdk.org/jdk/pull/13483#issuecomment-1509451674


From duke at openjdk.org  Sat Apr 15 02:01:52 2023
From: duke at openjdk.org (duke)
Date: Sat, 15 Apr 2023 02:01:52 GMT
Subject: Withdrawn: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <G6Tw0B0L-RsbxtWAHaDtj3Q11H47PQZYJKw69j5oF9g=.bb2621e8-9cb4-43b8-a12d-a71640263d0c@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

This pull request has been closed without being integrated.

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

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


From eirbjo at gmail.com  Sat Apr 15 08:23:50 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 15 Apr 2023 10:23:50 +0200
Subject: Could we backport the default SSLSession.getPeerCertificateChain
 method to 11?
In-Reply-To: <cce165c4-a797-3752-07aa-a0f6268592c8@oracle.com>
References: <CA+pBWhsWsVQHiQc_cLBm_wiZWWPX8MaHUR-FmmdJ7OGA8w8MqQ@mail.gmail.com>
 <cce165c4-a797-3752-07aa-a0f6268592c8@oracle.com>
Message-ID: <CA+pBWhurZeaOd9cx0cCG0mFHdqm+YkbQYgqn5_C2+MnWPNUw5A@mail.gmail.com>

Sean,

On Fri, Apr 14, 2023 at 9:18?PM Sean Mullan <sean.mullan at oracle.com> wrote:

> Not possible right now AFAICT, but I will keep it in mind as a candidate
> API change for the next MR, if and when that may occur.


Thanks for your analysis, this was enlightening. Too bad our timing is off,
but such is life :-)

I found the Compatibility risk description in the CSR a bit interesting:

There might be some applications that still use the deprecated
> SSLSession.getPeerCertificateChain() API. But they have had plenty of
> advance warning to switch to use the equivalent
> SSLSession.getPeerCertificates() API that use the java.security.cert APIs
> instead.


Any existing application calling SSLSession.getPeerCertificateChain() will
do so on some existing implementation which already overrides this method.
So these applications should not observe a behavioural  change.

The only behavioural change I see that could surprise anyone is the set of
applications which today fails to compile because they don't
override getPeerCertificateChain. These applications may be surprised that
their source code suddenly compiles.

But compatibility is a tricky topic, so I assume I'm missing some subtlety
here.

Eirik :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230415/7d75d28b/attachment.htm>

From eirbjo at gmail.com  Sat Apr 15 09:15:21 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 15 Apr 2023 11:15:21 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
Message-ID: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>

Hi,

JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests removing
the deprecated classes in javax.security.cert.

The CSR was withdrawn last year following ecosystem compatibility concerns:

Given the compatibility risks/impacts with existing providers and JSSE
> implementations, we've decided to withdraw this CSR for the time being.


I reached out to the BouncyCastle project [3] and they are basically OK
with the OpenJDK project to go ahead and remove the APIs:

It's a just cause, so go ahead and deal with it, I think all we need is
> someone to let us know when it's done and point us at a JVM so we can
> start organising the new jar.


I have also contributed the following PRs to make Tomcat, Netty, Vert.x and
Undertow aware of the plans of removal and also to provide the actual code
changes:

https://github.com/apache/tomcat/pull/608
https://github.com/netty/netty/pull/13326
https://github.com/eclipse-vertx/vert.x/pull/4665
https://github.com/undertow-io/undertow/pull/1468

Implementing these PRs was mostly straightforward, indicating that the
impact in these projects would be relatively low if these APIs would be
removed today.

I think we are in a bit of a knotty situation where the ecosystem is now
basically just waiting for OpenJDK to actually remove these APIs.

Based on my recent interaction with these projects I'm hopeful that the
ecosystem impact is lower than what has been assessed previously. I believe
we should go ahead with this removal, sooner rather than later.

Any thoughts?

Thanks,
Eirik.

[1] https://bugs.openjdk.org/browse/JDK-8227024
[2] https://bugs.openjdk.org/browse/JDK-8227395
[3] https://marc.info/?l=bouncycastle-crypto-dev&m=168154811006840&w=2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230415/5a5b4b1d/attachment.htm>

From eirbjo at gmail.com  Sat Apr 15 13:26:02 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 15 Apr 2023 15:26:02 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
Message-ID: <CA+pBWhsGcjukEEbPf+0thJEdB-QhPuiz15yEqkcT6j7YhKmjBQ@mail.gmail.com>

On Sat, Apr 15, 2023 at 11:15?AM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

> Based on my recent interaction with these projects I'm hopeful that the
> ecosystem impact is lower than what has been assessed previously.
>

Neither Jetty nor Grizzly have dependencies on javax.servlet.cert in their
mainline code bases.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230415/a7dc95ae/attachment.htm>

From Alan.Bateman at oracle.com  Sat Apr 15 13:50:44 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Apr 2023 14:50:44 +0100
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
Message-ID: <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>

On 15/04/2023 10:15, Eirik Bj?rsn?s wrote:
> Hi,
>
> JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests 
> removing the deprecated?classes in?javax.security.cert.
>
> The CSR was withdrawn last year following ecosystem compatibility 
> concerns:
>
>     Given the compatibility risks/impacts with existing providers and
>     JSSE implementations, we've decided to withdraw this CSR for the
>     time being.
>
>
> I reached out to the BouncyCastle project [3] and they are basically 
> OK with the OpenJDK project to go ahead and remove the APIs:
>
>     It's a just cause, so go ahead and deal with it, I think all we
>     need is
>     someone to let us know when it's done and point us at a JVM so we can
>     start organising the new jar.
>
>
> I have also contributed the following PRs to make Tomcat, Netty, 
> Vert.x and Undertow aware of the plans of removal and also to provide 
> the actual code changes:
>
> https://github.com/apache/tomcat/pull/608
> https://github.com/netty/netty/pull/13326
> https://github.com/eclipse-vertx/vert.x/pull/4665
> https://github.com/undertow-io/undertow/pull/1468
>
> Implementing these PRs was mostly?straightforward, indicating that the 
> impact in these projects would be relatively low if these APIs would 
> be removed today.
>
> I think we are in a bit of a knotty situation where the ecosystem is 
> now basically just waiting for OpenJDK to actually remove these APIs.
> Based on my recent interaction with these projects I'm hopeful that 
> the ecosystem impact is lower than what has been assessed previously. 
> I believe we should go ahead with this removal, sooner rather than later.
>
> Any thoughts?
>
Kudos for reaching out the BC and for creating PRs to several projects 
to remove their usage, this is a great way to contribute!

Removing anything is hard. The changes in JDK-8241047 were intended to 
allow SSLSession implementations drop their dependence on 
javax.security.cert.X509Certificate but it may take time if 
implementations are still expecting to be able to compile to a wide 
range of releases that include JDK 14 or older. I also be concerned that 
existing releases of this frameworks/libs with dependences on 
javax.security.cert.X509Certificate will be in use for some time. I'll 
defer to Sean and Brad but it feels like it might have to stay around 
for another few releases at least.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230415/6e0a1b35/attachment.htm>

From eirbjo at gmail.com  Sat Apr 15 14:23:06 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 15 Apr 2023 16:23:06 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
Message-ID: <CA+pBWhukV6e1puWvonGYV5suyTv_HosV1+RrQSGTZe092CGDNg@mail.gmail.com>

>
> The changes in JDK-8241047 were intended to allow SSLSession
> implementations drop their dependence on
> javax.security.cert.X509Certificate but it may take time if implementations
> are still expecting to be able to compile to a wide range of releases that
> include JDK 14 or older.


JDK-8241047 was indeed a very good move, and seems to be a key enabler for
projects to easily drop their dependencies on javax.security.cert. It is
really unfortunate we missed the train on backporting this to the 11 MR.

I understand the concerns regarding implementations expecting to be able to
compile to a wide range of releases. However, if we indefinitely continue
to meet this expectation, then when can we ever remove anything? Besides
that, BouncyCastle provides an example that it is very possible to move
forward while still compiling to a wide range of releases - it just puts a
burden on projects needing this to maintain a more complex build and
release system.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230415/c6194ebd/attachment.htm>

From valeriep at openjdk.org  Mon Apr 17 04:50:40 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 17 Apr 2023 04:50:40 GMT
Subject: Integrated: 8305336: java.security.debug=sunpkcs11 breaks PKCS#11
 configuration with slotListIndex
In-Reply-To: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>
References: <cCRP9Cs8oTmiGWuc-Mbc3CUdl6dvr6rIdjpgGy2yoGw=.a4ac31b5-da64-4087-9f9e-55af791f134c@github.com>
Message-ID: <pKRVD73ah9yOwtWytAsPwoGBzv-hJQgZY--AaFbBdOw=.24f652e6-3991-45dc-95fc-09db3d3a4388@github.com>

On Fri, 14 Apr 2023 21:53:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this trivial fix?
> 
> Inside the debugging block, the slot list variable "slots" is overridden with slots with tokens, this causes problem when trying to access the slot list with slotListIndex configuration option. Fix is to print out the slot with tokens info w/o storing it into the slot list variable.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: e5759241
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e575924131672c3ae662bbc44435c7acea3959d5
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8305336: java.security.debug=sunpkcs11 breaks PKCS#11 configuration with slotListIndex

Reviewed-by: mpowers, weijun

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

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


From eirbjo at gmail.com  Mon Apr 17 07:59:45 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 17 Apr 2023 09:59:45 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
Message-ID: <CA+pBWhvr1orUj_PMAV_2ehaGyBVg-akHRRszhHtOTwAO2H8yqg@mail.gmail.com>

>
> I reached out to the BouncyCastle project [3] and they are basically OK
> with the OpenJDK project to go ahead and remove the APIs:
>
> I reached out to the Conscrypt team with a PR. While the PR cannot be
integrated in its current form, the ensuing discussion was instructive:

https://github.com/google/conscrypt/pull/1128

Pete provides a neat explanation of how Conscrypt is packaged and used in
the wider Opecosystem. I think the key takeaway for OpenJDK seems to be:

I think for OpenJDK and standalone Android builds, it's probably fine to
> simply drop support for the getPeerCertificateChain() API at a release
> boundary. Caveat emptor etc.


TBH we've never assumed that upstream OpenJDK would worry about us when
> making breaking changes. :) I don't mean that in a negative way, just that
> your priorities are not the same as ours and so it's up to us to react as
> needed.


Pete then goes on to explain that javax.security.cert currently isn't
formally marked as deprecated in Android Platform, so they are lagging
behind aim to align with OpenJDK in this respect.

The rest of his comments are mainly focused on the Android parts, it's a
good read for anyone interested in that.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/13bbd6a1/attachment.htm>

From eirbjo at gmail.com  Mon Apr 17 08:33:34 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 17 Apr 2023 10:33:34 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
Message-ID: <CA+pBWhuTx=uQo8QcPum1JP+wKg_XQXL7unpa_ZY0wSdBKc1gUA@mail.gmail.com>

>
> I also be concerned that existing releases of this frameworks/libs with
> dependences on javax.security.cert.X509Certificate will be in use for some
> time.
>

Based on my interaction with ecosystem projects so far, the prevalent
sentiment seems to be "we plan to deal with this once OpenJDK removes the
APIs". It seems this stalemate situation cannot really be broken before
OpenJDK goes ahead with the removal. Providers like BouncyCastle and
Conscrypt already have abstractions and build systems in place to handle
these kinds of platform differences. They seem well equipped to handle this
change.

Sure we can delay this a few releases, but I honestly don't see how that
will materially change the situation. The band-aid that needs to be ripped
at some point and the ecosystem seems to be waiting for OpenJDK to do so.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/9647dd99/attachment.htm>

From eirbjo at gmail.com  Mon Apr 17 09:03:33 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 17 Apr 2023 11:03:33 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <CA+pBWhuTx=uQo8QcPum1JP+wKg_XQXL7unpa_ZY0wSdBKc1gUA@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
 <CA+pBWhuTx=uQo8QcPum1JP+wKg_XQXL7unpa_ZY0wSdBKc1gUA@mail.gmail.com>
Message-ID: <CA+pBWhumMddBn4rSzaBzmCzXT0pLuv-VfRsFks5mNkmtVGQo9Q@mail.gmail.com>

>
> Sure we can delay this a few releases, but I honestly don't see how that
> will materially change the situation.
>

Rethinking this, perhaps there are some benefits to not introducing this in
an LTS release. Doing it in a release immediately following an LTS would
allow the wider ecosystem maximum time to work on their solutions and do
testing on non-LTS releases. It would even allow OpenJDK to add them back
if there are critical unforeseeable concerns.

So perhaps 22?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/41e7172f/attachment.htm>

From duke at openjdk.org  Mon Apr 17 13:34:43 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 17 Apr 2023 13:34:43 GMT
Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate
 or SSLEngineTemplate
Message-ID: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>

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

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

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

Changes: https://git.openjdk.org/jdk/pull/13494/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13494&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306014
  Stats: 1002 lines in 6 files changed: 266 ins; 693 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/13494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13494/head:pull/13494

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


From duke at openjdk.org  Mon Apr 17 13:34:46 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 17 Apr 2023 13:34:46 GMT
Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate
Message-ID: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>

I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes.

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306015
  Stats: 2397 lines in 22 files changed: 339 ins; 1724 del; 334 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 John.Gray at entrust.com  Mon Apr 17 14:04:30 2023
From: John.Gray at entrust.com (John Gray)
Date: Mon, 17 Apr 2023 14:04:30 +0000
Subject: [EXTERNAL] Re: An update on ecosystem concerns removing
 javax.security.cert
In-Reply-To: <CA+pBWhvr1orUj_PMAV_2ehaGyBVg-akHRRszhHtOTwAO2H8yqg@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
 <CA+pBWhvr1orUj_PMAV_2ehaGyBVg-akHRRszhHtOTwAO2H8yqg@mail.gmail.com>
Message-ID: <DM6PR11MB2585CEFEBB0551DC3FBA7B20EA9C9@DM6PR11MB2585.namprd11.prod.outlook.com>

I just happened to notice this on the list this morning.  We have a 20+ year old commercial Java cryptographic toolkit at Entrust that we maintain and implement security protocols and algorithms which makes use of API?s in the javax.security.cert package.  It is in used by many customers.  It looks like you are planning to remove that entire package now?    We still compile with Java 8 (because we have customers that still need Java 8 support), but we need to support later Java runtime versions.  I guess we would have eventually noticed this when we upped our base compiler to 11 which probably won?t happen until 8 no longer has extended support (which is 2030 according to this?)  https://www.oracle.com/java/technologies/java-se-support-roadmap.html).  Though.. I would hope everyone would be off 8 in the next few years?  ?

I guess we will have to make a number of changes to our toolkit because this change will break things in a number of areas in Java 19.    I guess we have until the next LTS to do all this work?  ?

John Gray
Entrust


From: security-dev <security-dev-retn at openjdk.org> On Behalf Of Eirik Bj?rsn?s
Sent: Monday, April 17, 2023 4:00 AM
To: security-dev at openjdk.org
Subject: [EXTERNAL] Re: An update on ecosystem concerns removing javax.security.cert

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
I reached out to the BouncyCastle project [3] and they are basically OK with the OpenJDK project to go ahead and remove the APIs:
I reached out to the Conscrypt team with a PR. While the PR cannot be integrated in its current form, the ensuing discussion was instructive:

https://github.com/google/conscrypt/pull/1128<https://urldefense.com/v3/__https:/github.com/google/conscrypt/pull/1128__;!!FJ-Y8qCqXTj2!ar5kpb1r1i5Xsn4u_CR5zwdcmGLyTQNySwfvEMWPMEjNW17SrO-GOrkWEQGnrbFi3MfR3pKBr-yZvfDVFa_8$>

Pete provides a neat explanation of how Conscrypt is packaged and used in the wider Opecosystem. I think the key takeaway for OpenJDK seems to be:

I think for OpenJDK and standalone Android builds, it's probably fine to simply drop support for the getPeerCertificateChain() API at a release boundary. Caveat emptor etc.

TBH we've never assumed that upstream OpenJDK would worry about us when making breaking changes. :) I don't mean that in a negative way, just that your priorities are not the same as ours and so it's up to us to react as needed.

Pete then goes on to explain that javax.security.cert currently isn't formally marked as deprecated in Android Platform, so they are lagging behind aim to align with OpenJDK in this respect.

The rest of his comments are mainly focused on the Android parts, it's a good read for anyone interested in that.

Thanks,
Eirik.
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/3babd9f0/attachment.htm>

From eirbjo at gmail.com  Mon Apr 17 14:57:31 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 17 Apr 2023 16:57:31 +0200
Subject: [EXTERNAL] Re: An update on ecosystem concerns removing
 javax.security.cert
In-Reply-To: <DM6PR11MB2585CEFEBB0551DC3FBA7B20EA9C9@DM6PR11MB2585.namprd11.prod.outlook.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
 <CA+pBWhvr1orUj_PMAV_2ehaGyBVg-akHRRszhHtOTwAO2H8yqg@mail.gmail.com>
 <DM6PR11MB2585CEFEBB0551DC3FBA7B20EA9C9@DM6PR11MB2585.namprd11.prod.outlook.com>
Message-ID: <CA+pBWhtY1ts4CGqATxkn7M8T28v+AU2F1QiBiT0tgNrOWuEbFA@mail.gmail.com>

Hi John, thanks for reaching out!

I just happened to notice this on the list this morning.  We have a 20+
> year old commercial Java cryptographic toolkit at Entrust that we maintain
> and implement security protocols and algorithms which makes use of API?s in
> the javax.security.cert package.  It is in used by many customers.
>

Would you be able to share a bit more about how your product is exposed to
these APIs? The APIs were introduced around 2002 for compatibility concerns
with unbundled JSSE releases. They deprecated in Java 9, but has had a
notice discouraging their use since they were introduced.

It looks like you are planning to remove that entire package now?
>

No decision or commitment has been made yet. But yes, there is an ongoing
effort to get this removed, we just don't know when yet.

The topic of removal has been discussed for about five years now. The APIs
were marked deprecated for-removal in Java 13. In Java 15, the
SSLSession.getPeerCertificateChain interface method was changed to be a
default method which throws UnsupportedOperationException.


> We still compile with Java 8 (because we have customers that still need
> Java 8 support), but we need to support later Java runtime versions.
>

This will compile fine with the current LTS, which is Java 17. The next LTS
will be 21, coming this fall.

I would recommend that you start looking at any use of
javax.security.cert.X509Certificate for parsing certificates. That should
be replaced with java.security.cert.CertificateFactory. Then I'd look to
see if you have any calls to SSLSession.getPeerCertificateChain. Those
should be replaced with SSLSession.getPeerCertificate.

Once you've done this, you might be left with your own implementations of
SSLSession.getPeerCertificateChain. If you have any of those, you'll need
to override them to compile on Java 11. From Java 17, there is the
mentioned default getPeerCertificate method, so your implementation will
not need to override this method.

If you need to support Java 8 AND Java X (where X has removed the package),
then you'll need to look into versioned jars, modularization or other forms
of build changes such that you can compile against this wide range of Java
versions.


> I guess we would have eventually noticed this when we upped our base
> compiler to 11 which probably won?t happen until 8 no longer has extended
> support (which is 2030 according to this?)
>

This would give you the deprecation warning introduced in Java 9, yes.


> I guess we will have to make a number of changes to our toolkit because
> this change will break things in a number of areas in Java 19.
>

I believe there were no changes in this area in Java 19. The removal will
not happen until 21, 22, 23 or later.

Thanks again for your feedback, much appreciated!

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/8da1a33a/attachment.htm>

From cslucas at openjdk.org  Mon Apr 17 16:17:30 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 17 Apr 2023 16:17:30 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
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: <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@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:

  Fix tests. Remember previous reducible Phis.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/a10b0a4c..aec1b07a

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

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 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 jiangli at openjdk.org  Mon Apr 17 17:25:16 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Apr 2023 17:25:16 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and
 friends when statically linking with JDK native libraries
Message-ID: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>

- Make functions 'static' when feasible:
  - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
  - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
  - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
  - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
  - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
  - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.

- Rename functions by following the existing naming usages in different libraries code:
  - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
  - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
  - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
  - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
  - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.

- Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
- Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

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

Commit messages:
 - - Fix whitespaces in p11_util.c.
 - 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries

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

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


From Alan.Bateman at oracle.com  Mon Apr 17 18:42:48 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Apr 2023 19:42:48 +0100
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <CA+pBWhumMddBn4rSzaBzmCzXT0pLuv-VfRsFks5mNkmtVGQo9Q@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
 <CA+pBWhuTx=uQo8QcPum1JP+wKg_XQXL7unpa_ZY0wSdBKc1gUA@mail.gmail.com>
 <CA+pBWhumMddBn4rSzaBzmCzXT0pLuv-VfRsFks5mNkmtVGQo9Q@mail.gmail.com>
Message-ID: <66dbc59a-317f-2cf5-399b-91dc5e9222b4@oracle.com>

On 17/04/2023 10:03, Eirik Bj?rsn?s wrote:
>
>     Sure we can delay this a few releases, but I honestly don't see
>     how that will?materially change the situation.
>
>
> Rethinking this, perhaps there are some benefits to not introducing 
> this in an LTS release. Doing it in a release immediately following an 
> LTS would allow the wider ecosystem maximum time to work on their 
> solutions and do testing on non-LTS releases. It would even allow 
> OpenJDK to add them back if there are critical unforeseeable concerns.
>
> So perhaps 22?
>
I don't think it's possible to suggest a release at this time. Ideally 
javax.security.cert would have been removed a long time ago but the 
references from classes in javax.net.ssl make it difficult for both 
implementers and users of the API. So I think we are forced to kick it 
down the road for now. Your effort to track down projects with usages 
and create PRs is very welcome as it helps to move things along.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/bdbf2997/attachment.htm>

From eirbjo at gmail.com  Mon Apr 17 19:28:29 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 17 Apr 2023 21:28:29 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <66dbc59a-317f-2cf5-399b-91dc5e9222b4@oracle.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
 <CA+pBWhuTx=uQo8QcPum1JP+wKg_XQXL7unpa_ZY0wSdBKc1gUA@mail.gmail.com>
 <CA+pBWhumMddBn4rSzaBzmCzXT0pLuv-VfRsFks5mNkmtVGQo9Q@mail.gmail.com>
 <66dbc59a-317f-2cf5-399b-91dc5e9222b4@oracle.com>
Message-ID: <CA+pBWhtsMqOJnU6mSxW12D3r3eaA2rJs9r3Dpaopxog5onQUZQ@mail.gmail.com>

>
> Ideally javax.security.cert would have been removed a long time ago but
> the references from classes in javax.net.ssl make it difficult for both
> implementers and users of the API. So I think we are forced to kick it down
> the road for now.
>

I think we may disagree a bit on the assessment on the difficulty and
impact for implementers and users, but that's OK, I understand we would
need consensus to proceed.

Your effort to track down projects with usages and create PRs is very
> welcome as it helps to move things along.
>

In the "good news" department, my Netty 5 PR was merged today:

https://github.com/netty/netty/pull/13326#event-9027065789

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/9f976fee/attachment.htm>

From castuloramirez at gmail.com  Mon Apr 17 19:39:34 2023
From: castuloramirez at gmail.com (=?UTF-8?B?Q8Ohc3R1bG8gUmFtw61yZXogTG9uZG/DsW8=?=)
Date: Mon, 17 Apr 2023 21:39:34 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
Message-ID: <CA+4c0s__5PWZka2E8oAyOE0J-OzDU6dNSUaxnY-GmJvF02uGbA@mail.gmail.com>

On Sat, 15 Apr 2023 at 11:16, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

> Hi,
>
> JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests removing
> the deprecated classes in javax.security.cert.
>
> The CSR was withdrawn last year following ecosystem compatibility concerns:
>
> Given the compatibility risks/impacts with existing providers and JSSE
>> implementations, we've decided to withdraw this CSR for the time being.
>
>
> I reached out to the BouncyCastle project [3] and they are basically OK
> with the OpenJDK project to go ahead and remove the APIs:
>
> It's a just cause, so go ahead and deal with it, I think all we need is
>> someone to let us know when it's done and point us at a JVM so we can
>> start organising the new jar.
>
>
> I have also contributed the following PRs to make Tomcat, Netty, Vert.x
> and Undertow aware of the plans of removal and also to provide the actual
> code changes:
>
> https://github.com/apache/tomcat/pull/608
> https://github.com/netty/netty/pull/13326
> https://github.com/eclipse-vertx/vert.x/pull/4665
> https://github.com/undertow-io/undertow/pull/1468
>
> Implementing these PRs was mostly straightforward, indicating that the
> impact in these projects would be relatively low if these APIs would be
> removed today.
>
> I think we are in a bit of a knotty situation where the ecosystem is now
> basically just waiting for OpenJDK to actually remove these APIs.
>
> Based on my recent interaction with these projects I'm hopeful that the
> ecosystem impact is lower than what has been assessed previously. I believe
> we should go ahead with this removal, sooner rather than later.
>
> Any thoughts?
>
> Thanks,
> Eirik.
>
> [1] https://bugs.openjdk.org/browse/JDK-8227024
> [2] https://bugs.openjdk.org/browse/JDK-8227395
> [3] https://marc.info/?l=bouncycastle-crypto-dev&m=168154811006840&w=2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/ddf076f7/attachment.htm>

From John.Gray at entrust.com  Mon Apr 17 21:30:40 2023
From: John.Gray at entrust.com (John Gray)
Date: Mon, 17 Apr 2023 21:30:40 +0000
Subject: [EXTERNAL] Re: An update on ecosystem concerns removing
 javax.security.cert
In-Reply-To: <CA+pBWhtY1ts4CGqATxkn7M8T28v+AU2F1QiBiT0tgNrOWuEbFA@mail.gmail.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
 <CA+pBWhvr1orUj_PMAV_2ehaGyBVg-akHRRszhHtOTwAO2H8yqg@mail.gmail.com>
 <DM6PR11MB2585CEFEBB0551DC3FBA7B20EA9C9@DM6PR11MB2585.namprd11.prod.outlook.com>
 <CA+pBWhtY1ts4CGqATxkn7M8T28v+AU2F1QiBiT0tgNrOWuEbFA@mail.gmail.com>
Message-ID: <DM6PR11MB2585BF0DED876C487359981FEA9C9@DM6PR11MB2585.namprd11.prod.outlook.com>

Thanks for the reply!

If it is not happening until 22 or later that gives us more time.   I understand we already had lots of years, I guess that is the problem with code that has just worked for so many years.  You don?t look at it until it breaks.  Fortunately I noticed this before it breaks?  ?

There aren?t that many places that use getPeerCertificateChain() anymore, and it looks like a couple places in some older code from around 2002 are using javax.security.cert.X509Certificate when they could easily use java.security.cert.

Our toolkit has been around since the Java 1.2 days? So it has gone through all the various incarnations of bundled extensions, installed extension, signed and unsigned jars (JDK 1.4), all that fun stuff from the past.   ?

Looks like its not going to be hard to ?modernize? that old stuff.   On a positive note, we support bleeding edge stuff like composite algorithms and hybrid certificates.  ?   So the JCA has stood up well after so many years.   I?m looking forward to the new KEM API?s that you are adding for us.

Cheers,

John Gray


From: Eirik Bj?rsn?s <eirbjo at gmail.com>
Sent: Monday, April 17, 2023 10:58 AM
To: John Gray <John.Gray at entrust.com>
Cc: security-dev at openjdk.org
Subject: Re: [EXTERNAL] Re: An update on ecosystem concerns removing javax.security.cert

Hi John, thanks for reaching out!

I just happened to notice this on the list this morning.  We have a 20+ year old commercial Java cryptographic toolkit at Entrust that we maintain and implement security protocols and algorithms which makes use of API?s in the javax.security.cert package.  It is in used by many customers.

Would you be able to share a bit more about how your product is exposed to these APIs? The APIs were introduced around 2002 for compatibility concerns with unbundled JSSE releases. They deprecated in Java 9, but has had a notice discouraging their use since they were introduced.

It looks like you are planning to remove that entire package now?

No decision or commitment has been made yet. But yes, there is an ongoing effort to get this removed, we just don't know when yet.

The topic of removal has been discussed for about five years now. The APIs were marked deprecated for-removal in Java 13. In Java 15, the SSLSession.getPeerCertificateChain interface method was changed to be a default method which throws UnsupportedOperationException.

We still compile with Java 8 (because we have customers that still need Java 8 support), but we need to support later Java runtime versions.

This will compile fine with the current LTS, which is Java 17. The next LTS will be 21, coming this fall.

I would recommend that you start looking at any use of javax.security.cert.X509Certificate for parsing certificates. That should be replaced with java.security.cert.CertificateFactory. Then I'd look to see if you have any calls to SSLSession.getPeerCertificateChain. Those should be replaced with SSLSession.getPeerCertificate.

Once you've done this, you might be left with your own implementations of SSLSession.getPeerCertificateChain. If you have any of those, you'll need to override them to compile on Java 11. From Java 17, there is the mentioned default getPeerCertificate method, so your implementation will not need to override this method.

If you need to support Java 8 AND Java X (where X has removed the package), then you'll need to look into versioned jars, modularization or other forms of build changes such that you can compile against this wide range of Java versions.

I guess we would have eventually noticed this when we upped our base compiler to 11 which probably won?t happen until 8 no longer has extended support (which is 2030 according to this?)

This would give you the deprecation warning introduced in Java 9, yes.

I guess we will have to make a number of changes to our toolkit because this change will break things in a number of areas in Java 19.

I believe there were no changes in this area in Java 19. The removal will not happen until 21, 22, 23 or later.

Thanks again for your feedback, much appreciated!

Eirik.
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/28416bca/attachment.htm>

From cslucas at openjdk.org  Mon Apr 17 22:11:46 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 17 Apr 2023 22:11:46 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v8]
In-Reply-To: <egFiUX18gxHTK7vDPXekBEkmxr-MoJG4jtZQKxwwWfo=.9c1e6c40-7601-4f5d-88c6-c9903ca295b7@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Mf1vAYk5EpwlcuZ2P1Nj8WjjtD0Mh9IWFvt0Tl69tPE=.8a27d12b-61c2-49fa-adbe-48b4e91974a4@github.com>
 <egFiUX18gxHTK7vDPXekBEkmxr-MoJG4jtZQKxwwWfo=.9c1e6c40-7601-4f5d-88c6-c9903ca295b7@github.com>
Message-ID: <VP9YB2OxaX1nmINO2hqPrSJvHzL01WUUvclX0RCpNGE=.099b42b9-ce20-4fda-a2a9-4dd40e7c567a@github.com>

On Sat, 15 Apr 2023 00:17:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR review 3. Some comments and be able to abort compilation.
>
> New test failed in tier1 on all platforms. Here is list:
> 
> 1) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.TestTrapAfterMerge(boolean,int,int)" - [Failed IR rules: 1]:
> 2) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testCondLoadAfterMerge(boolean,boolean,int,int)" - [Failed IR rules: 1]:
> 3) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testLoadInCondAfterMerge(boolean,int,int)" - [Failed IR rules: 1]:
> 4) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testMergesAndMixedEscape(boolean,int,int)" - [Failed IR rules: 1]:
> 5) Method "compiler.c2.irTests.scalarReplacement.AllocationMergesTests$Point[] compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testNestedObjectsArray(boolean,int,int)" - [Failed IR rules: 1]:
> 6) Method "int compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testNestedObjectsNoEscapeObject(boolean,int,int)" - [Failed IR rules: 1]:
> 7) Method "compiler.c2.irTests.scalarReplacement.AllocationMergesTests$Point compiler.c2.irTests.scalarReplacement.AllocationMergesTests.testNestedObjectsObject(boolean,int,int)" - [Failed IR rules: 1]:

@vnkozlov - sorry about that. I fixed the code now and all GHA tests are passing.

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

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


From jpai at openjdk.org  Tue Apr 18 06:06:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Apr 2023 06:06:42 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <oNxI2MVV8qkNiHH6hYNzV6W_RizUShm_D0m3WC171ms=.51242691-0f2e-45fb-aa2b-710f3db88a2b@github.com>

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Hello Jiangli, I have no experience in C language or the symbol linking that's involved in this PR, but given similar PRs that have been merged recently, is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues? I realize that you have been working on JDK-8303796 which proposes to build statically linked JDK image. Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in?

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1512486343


From eirbjo at gmail.com  Tue Apr 18 07:53:17 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 18 Apr 2023 09:53:17 +0200
Subject: An update on ecosystem concerns removing javax.security.cert
In-Reply-To: <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
References: <CA+pBWhvtcoHF9FE=uUciyFnAU=1V7NQu8cUYUBpo8ODjCinbGw@mail.gmail.com>
 <3560bbe1-ddf6-f140-374b-c44c2144a2a6@oracle.com>
Message-ID: <CA+pBWhsi0xUwY9756F9kGznQ0aZ2Gy_ywxOJT8Hr-jTnhNJNMw@mail.gmail.com>

>
> Given the compatibility risks/impacts with existing providers and JSSE
>> implementations, we've decided to withdraw this CSR for the time being.
>
>
One of the concerns raised by Alan in the CSR was related to SPECjbb2015:

The Grizzly framework is used in SPECjbb2015 for example, will it mean that
> this benchmark will no longer run on JDK main line?


I don't have access to SPECjbb2015, but it seems it is using some version
of Grizzly 2.x. I decided to check out the 2.4.4-RELEASE branch and it
seems the exposure to javax.security.cert is fairly limited and contained
to two method implementations in a single class SSLSupportImpl. This class
uses SSLSession, but does not implement it.

An interesting note is that the implementation methods actually do call
SSLContext.getPeerCertificateChain(), but then goes on to convert the
results to java.security.cert.X509Certificate. This makes no sense, so it
is probably an artifact of history. Anyhow, this actually means that
Grizzly 2 is already broken on mainline JDKs where the
getPeerCertificateChain throws and has no implementation.

This also means that _if_ SPECjbb2015 works on today's mainline, it will
probably continue to do so after the removal, because it's not calling the
affected methods in SSLSupportImpl.

It would be interesting to confirm this by running SPECjbb2015 on a JDK
with these APIs removed, but I'm not a licensee so I cannot explore that.

I'll consider contributing a PR to Grizzly 2.x to replace the
SSLSession.getPeerCertificateChain() with SSLSession.getPeerCertificates()
and drop the conversion. But I'm not so sure there will be interest in
releasing from this branch which seems dormant.

Cheers,
Eirik.



> I reached out to the BouncyCastle project [3] and they are basically OK
> with the OpenJDK project to go ahead and remove the APIs:
>
> It's a just cause, so go ahead and deal with it, I think all we need is
>> someone to let us know when it's done and point us at a JVM so we can
>> start organising the new jar.
>
>
> I have also contributed the following PRs to make Tomcat, Netty, Vert.x
> and Undertow aware of the plans of removal and also to provide the actual
> code changes:
>
> https://github.com/apache/tomcat/pull/608
> https://github.com/netty/netty/pull/13326
> https://github.com/eclipse-vertx/vert.x/pull/4665
> https://github.com/undertow-io/undertow/pull/1468
>
> Implementing these PRs was mostly straightforward, indicating that the
> impact in these projects would be relatively low if these APIs would be
> removed today.
>
> I think we are in a bit of a knotty situation where the ecosystem is now
> basically just waiting for OpenJDK to actually remove these APIs.
>
> Based on my recent interaction with these projects I'm hopeful that the
> ecosystem impact is lower than what has been assessed previously. I believe
> we should go ahead with this removal, sooner rather than later.
>
> Any thoughts?
>
> Kudos for reaching out the BC and for creating PRs to several projects to
> remove their usage, this is a great way to contribute!
>
> Removing anything is hard. The changes in JDK-8241047 were intended to
> allow SSLSession implementations drop their dependence on
> javax.security.cert.X509Certificate but it may take time if implementations
> are still expecting to be able to compile to a wide range of releases that
> include JDK 14 or older. I also be concerned that existing releases of this
> frameworks/libs with dependences on javax.security.cert.X509Certificate
> will be in use for some time. I'll defer to Sean and Brad but it feels like
> it might have to stay around for another few releases at least.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230418/9b454c0c/attachment.htm>

From weijun at openjdk.org  Tue Apr 18 16:24:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 16:24:56 GMT
Subject: RFR: 8297878: KEM: Implementation [v4]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <jTz9bBYmIWrYDtHVfGSXVc6Y_7YLvhTawmcJ5ifi3OQ=.bcca212e-5229-4c76-b95d-42a4ceea20b2@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:

  let implementor validate arguments, null key throws IKE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/b398b03e..6455a521

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

  Stats: 252 lines in 5 files changed: 51 ins; 180 del; 21 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 Apr 18 16:24:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 16:24:58 GMT
Subject: RFR: 8297878: KEM: Implementation [v3]
In-Reply-To: <-a9sn7ro1yid9nsdJr45IZdWtsjTArWnF9uLYsEtzHg=.8f09208b-4503-4ffa-b27e-5a39c8c8d79e@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <-a9sn7ro1yid9nsdJr45IZdWtsjTArWnF9uLYsEtzHg=.8f09208b-4503-4ffa-b27e-5a39c8c8d79e@github.com>
Message-ID: <q3pnGC5YX7ruitkIYreiCIBeXktgXjEdbKBe1SoWhkE=.ae5e638d-1d82-436e-b9a2-bbb5223edb8e@github.com>

On Fri, 14 Apr 2023 16:54:49 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:
> 
>   spec changes

New commit pushed. The "the caller has validated" sentences are removed since that will be an implementation detail. Now each provider needs to validate the arguments themselves.

Also, when a null key is provided to `newEncapsulator` and `newDecapsulator`, they throw an `InvalidKeyException` instead of a `NullPointerException` now.

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

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


From weijun at openjdk.org  Tue Apr 18 16:27:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 16:27:57 GMT
Subject: RFR: 8297878: KEM: Implementation [v4]
In-Reply-To: <g8zEGhdpDGNlLGuUtuXdnP9kbC4uzqFLfEZ_mrMHNjA=.598437b2-8195-48c2-937a-c148bbb7475c@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
 <g8zEGhdpDGNlLGuUtuXdnP9kbC4uzqFLfEZ_mrMHNjA=.598437b2-8195-48c2-937a-c148bbb7475c@github.com>
Message-ID: <OvoKDli3ilzkypgwqH90J9906SBxdw_CrP2wvqj17yo=.d179cabd-6463-4575-9095-1cf692809161@github.com>

On Fri, 14 Apr 2023 14:33:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEM.java line 94:
>> 
>>> 92:      * @see KEM#newEncapsulator(PublicKey, AlgorithmParameterSpec, SecureRandom)
>>> 93:      */
>>> 94:     public record Encapsulated(SecretKey key, byte[] encapsulation, byte[] params) {
>> 
>> We need to decide if the encapsulation and params arrays should be defensively cloned. I would lean towards cloning it since immutability is a feature of this API, and I think it would be surprising if this type was not. 
>> 
>> We can potentially switch to frozen arrays later.
>
> If we need to clone defensively I'll switch back to normal class, and then we can clone in both the constructor and the getters. IMO records are meant to be deadly simple.

Rewrite in plain normal class. Clone on both sides.

>> src/java.base/share/classes/javax/crypto/KEMSpi.java line 211:
>> 
>>> 209:      * The caller of this method has already validated the parameters to
>>> 210:      * ensure that {@code pk} is not {@code null}. Therefore an implementation
>>> 211:      * of this method does not to validate it.
>> 
>> s/not to/not need to/
>> 
>> Also, suggest saying who the caller is, "The caller (KEM.newEncapsulator) of this method ..."
>
> Fixed.
> 
> Not sure if the caller needs to be written out. `KEM.newEncapsulator` is the ultimate caller, but for delayed provider selection, the direct caller is in `Delayed`. Also, this can be considered as implementation detail. If I write out the name, then we cannot change.
> 
> `engineEncapsulate` and `engineDecapsulate` also use "the caller of this method".

Removed.

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

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


From weijun at openjdk.org  Tue Apr 18 16:27:59 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 16:27:59 GMT
Subject: RFR: 8297878: KEM: Implementation [v2]
In-Reply-To: <TOImpg-bF0OZpJVNLzyCDWI0BlOYuSnbpuwqEh6Qb64=.954ecb37-d4ae-4e6d-a8f5-033392231a63@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <b-fWG2NyBvcTlndU2dbYaikRCKV1dhbGNMpp5wrxVKg=.3f88d922-b014-4f94-a264-fe5767f83650@github.com>
 <CxJi-KDqF97yK_d9Y31ZkF1n_B8cYBI__ga-1frGK5U=.defe89f1-2269-4beb-aa57-6433eab5c024@github.com>
 <TOImpg-bF0OZpJVNLzyCDWI0BlOYuSnbpuwqEh6Qb64=.954ecb37-d4ae-4e6d-a8f5-033392231a63@github.com>
Message-ID: <8CiXminE-7Jkb4976iYrN5YFCQb19RFtXNETMjsvsUE=.14600dba-b18f-4df7-b258-8b0f63999541@github.com>

On Fri, 14 Apr 2023 14:21:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEM.java line 242:
>> 
>>> 240:          *          shared secret as a key with algorithm being "Generic",
>>> 241:          *          the key encapsulation message, and optional parameters.
>>> 242:          *          The return value should not be {@code null}.
>> 
>> "should" means it *could* still return null. I assume that is not what we want. Although I would be more inclined to only specify cases where null may be returned, and if it isn't mentioned, then it should be implied that null is not a legal return value. If in doubt, perhaps check with Joe/CCC for advice when you file the CSR.
>> 
>> This general comment applies to the other return types in this API where you say "not null". I think you can omit those.
>
> I do mean "must not be null". Maybe I can ask Joe directly.

I've removed the "not null" words for return values.

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

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


From weijun at openjdk.org  Tue Apr 18 16:28:02 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 16:28:02 GMT
Subject: RFR: 8297878: KEM: Implementation [v4]
In-Reply-To: <HqfIY7foJ0lQvhXO6Au9f7R1Vuz2Ct_7XHrm41VxSW0=.de8fd166-d86d-4e88-8544-f250892dea6f@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <4Rl87srCoqcWDcczqYgcDU9x9T5dPJ4M7o9KyxVHsEM=.c00d116f-89c7-40e5-8372-0c5ddbdb6b84@github.com>
 <HjEDcdSQVwVuWuwXKYCXCTSJSaIlzDaBjboHhEUb2P0=.c96c5df0-2c59-4bc3-87af-d9ee8981c266@github.com>
 <HqfIY7foJ0lQvhXO6Au9f7R1Vuz2Ct_7XHrm41VxSW0=.de8fd166-d86d-4e88-8544-f250892dea6f@github.com>
Message-ID: <6607bXjhpXmOeUwV4UZI6OEO7pmp-IeBr0hZ3gK-wBI=.d0db4b16-b823-4550-a0b9-f88aa05d33df@github.com>

On Fri, 14 Apr 2023 01:59:59 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I can rewrite this into something like "The caller of this method must validate..." so it becomes a requirement. We'll make sure the `KEM` class follows it. Any other class that wishes to call it directly must do it as well.
>
> You can make it a required part of the specification.  But it is a error-prone design.  What happens if an application does not follow the spec?  It may be more complicated to handle the case.

No more validation for providers.

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

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


From weijun at openjdk.org  Tue Apr 18 16:32:49 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 16:32:49 GMT
Subject: RFR: 8297878: KEM: Implementation [v5]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <aONJGHlkXd08h-g5jxDsIOdenSm24oENHAcl50e1L_A=.94938127-7fe1-4c9b-9fca-1f8aabf0e6bf@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:

  fine tune spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/6455a521..39c3a202

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

  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 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 Apr 18 17:24:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 17:24:01 GMT
Subject: RFR: 8297878: KEM: Implementation [v6]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <tttYHjL1liKGTB9ki98_RdKMNKcX8JSlTESxrpvBmyQ=.8f3570e6-19e0-4989-8840-b7956b9fd331@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:

  move Encapsulator before Decapsulator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/39c3a202..fe6d73b3

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

  Stats: 114 lines in 1 file changed: 22 ins; 22 del; 70 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 Apr 18 17:24:05 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 17:24:05 GMT
Subject: RFR: 8297878: KEM: Implementation [v5]
In-Reply-To: <aONJGHlkXd08h-g5jxDsIOdenSm24oENHAcl50e1L_A=.94938127-7fe1-4c9b-9fca-1f8aabf0e6bf@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <aONJGHlkXd08h-g5jxDsIOdenSm24oENHAcl50e1L_A=.94938127-7fe1-4c9b-9fca-1f8aabf0e6bf@github.com>
Message-ID: <TA7bhDs18DFbjl5ntQPcMyPGVqt95g3exkwKDclJ9V8=.3d793fc7-8ee3-4331-92c9-3a4fa2411777@github.com>

On Tue, 18 Apr 2023 16:32:49 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:
> 
>   fine tune spec

The latest commit only moves the `Encapsulator` class before `Decapsulator` class. No content update at all.

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

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


From jiangli at openjdk.org  Tue Apr 18 17:52:51 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Apr 2023 17:52:51 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <wJE7_bO6dl_V_iAPJbMXiWhlgtJPj1TvmahSFDddsjU=.587379dd-4453-4253-b517-0fe15d6c14f8@github.com>

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Hi Jaikiran,

Thanks for looking into this.

> is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues?

The symbol issues are reported as linker errors when statically linking the executable with JDK native libraries and libjvm. I just created a branch with the preliminary makefile changes for optionally statically linking JDK, which can be used to demonstrate/identify the issues:

  https://github.com/jianglizhou/jdk/pull/new/JDK-8303796

The branch is based on our prototype on JDK 11, but mostly reworked. It re-uses the existing JDK make infrastructure based on the feedback from Severin Gehwolf in https://bugs.openjdk.org/browse/JDK-8303796. Still need to clean up the makefile changes before making it ready for review. Early feedback/input is also welcomed.

> Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in?

Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1513574228


From weijun at openjdk.org  Tue Apr 18 22:07:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 22:07:11 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@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:

  fine tuning spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/fe6d73b3..d1a7f3e8

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

  Stats: 85 lines in 2 files changed: 29 ins; 18 del; 38 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 Apr 18 22:07:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Apr 2023 22:07:12 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <J5YWmwZB2yDr6iSoJyekzGiVwsRAPfowsMzXC13ylc4=.6173874e-1fda-4f01-96c0-1abf238abe13@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <7Xj-WnXLQlGYh-v2inO0vIig-m0ZN8pMy2_AotsSsEg=.48e6f920-03ab-4e41-8ac2-7b7ebb759b56@github.com>
 <J5YWmwZB2yDr6iSoJyekzGiVwsRAPfowsMzXC13ylc4=.6173874e-1fda-4f01-96c0-1abf238abe13@github.com>
Message-ID: <pzTPi2ortgk5DFRwS-0D-gyRH-1frxUn9WXMbna31b4=.12db2985-859a-4720-9204-4d7df5928f47@github.com>

On Fri, 14 Apr 2023 00:42:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEM.java line 246:
>> 
>>> 244: 
>>> 245:         /**
>>> 246:          * The key encapsulation function.
>> 
>> I think it would be useful to add a sentence explaining when this method would be useful.
>
> Then at the same time I should add a sentence to the usage of the other method. However, it's a little difficult to describe it if KDF is not defined yet.

Added some words in the latest commit.

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

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


From mbalao at openjdk.org  Wed Apr 19 03:51:52 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 19 Apr 2023 03:51:52 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: <zstEhEOT1ukEQk2HD97cTn6Wt5UmAo-7cu0czp95L1o=.cf30dcba-12c0-4eb6-82bb-b269fc19f946@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 overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> 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>

Please keep this open.

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

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1514092250


From eirbjo at gmail.com  Wed Apr 19 06:36:12 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 19 Apr 2023 08:36:12 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
Message-ID: <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>

>
> Given that removing these APIs would cause TCK issues in these cases, I
> have been reticent to remove the APIs. At this point, I view this to be
> in a holding pattern until we have a very strong confidence that it
> won't break EE implementations.
>

I have been exploring the effects of removing these APIs on JBoss Wildfly
20, the latest version to support Java EE 8.

The Wildfly implementations of EJBContext.getCallerIdentity and
EJBContext.isCallerInRole(Identity) both throw unconditionally,
respectively UnsupportedOperationException and IllegalStateException (?).

My first attempt to start Wildfly 20 failed on Java 17, because of
encapsulation issues related to reflective access to proxies. That was
easily fixed by upgrading the 'jboss-ejb-client' dependency to a version
where this issue is fixed, and then building 20.0.2.Final-SNAPSHOT. After
this change, Wildfly started just fine with my 21-internal JDK where the
APIs have been removed.

I then went on to deploy and run the 'ejb-security-context-propagation'
sample project [1]. This sample uses EJBContext, so it allows testing of
the removed APIs.

The existing sample rightfully does not call any of the deprecated methods.
The sample client runs just fine against the 21-internal Wildfly server.

I then went on to add a call to 'EJBContext.getCallerIdentity()'. Since the
method throws unconditionally, the return type is never resolved, so we get
the expected UnsupportedOperationException (so, no ClassNotFoundException
or similar):

Exception in thread "main" javax.ejb.EJBException:
> java.lang.UnsupportedOperationException: WFLYEJB0246: getCallerIdentity is
> deprecated
> at org.jboss.as.ejb3 at 20.0.2.Final-SNAPSHOT
> //org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:266)


Based on this testing, it seems removing 'Identity' and related APIs will
have no observable effect on Wildfly at runtime. Building will still need
to happen using a JDK containing the APIs.

I wanted to explore this scenario also on Glassfish, but it seems the last
version of Glassfish supporting Java EE 8 cannot even start on Java 11
(which removed javax.annotation.PostConstruct) and I did not investigate
fixing that.

It seems to me that other Java EE 8 implementations could achieve similar
results by also throwing UnsupportedOperation in their
'EJBContext.getCallerIdentity()' implementation, either unconditionally, or
perhaps just when then detect that they are running on a JRE where the
Identity' class is removed.

To summarize, I'm hopeful that removing 'Identity' and friends have limited
effect on Java EE 8 implementations and apps and that workarounds exist for
problems which may occur. Apps using the deprecated APIs in EJBContext
would of course need to be updated, but that's a straightforward
replacement job.

(Based on my observations of GlassFish and Wildfly, it is not at all clear
to me that they have any plans of fixing their Java EE 8 implementations
to work on Java 11 or 17, regardless of the API removal discussed here)

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230419/3be77b83/attachment.htm>

From Alan.Bateman at oracle.com  Wed Apr 19 07:09:13 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Apr 2023 08:09:13 +0100
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
Message-ID: <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>

On 19/04/2023 07:36, Eirik Bj?rsn?s wrote:
>
>
> To summarize, I'm hopeful that removing 'Identity' and friends have 
> limited effect on Java EE 8 implementations and apps and that 
> workarounds exist for problems which may occur. Apps using the 
> deprecated APIs in EJBContext would of course need to be updated, but 
> that's a straightforward replacement?job.

Sean put it well when he said we are in a "holding pattern" on these 
APIs right now. I don't think it's a holding pattern for perpetuity but 
I think it will take time for the big proprietary and legacy app servers 
to move beyond Java EE 8 and not expect build+deploy with new JDK 
releases at the same time. From the JDK side, it is annoying to be keep 
around classes such as java.security.Identity that have been deprecated 
since 1998. Ideally enhanced deprecation would have been introduced long 
before Java 9 and that Java EE or EJB would have removed its dependence 
on this API a long time ago. I think we are where we are and it should 
be possible to re-visit this one in a few releases.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230419/25d7f217/attachment.htm>

From eirbjo at gmail.com  Wed Apr 19 07:23:08 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 19 Apr 2023 09:23:08 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
 <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>
Message-ID: <CA+pBWht5LDvYBmcuLTMyyovx=_RBHHMQ9j22W8aitWi3jVrN0Q@mail.gmail.com>

>
> Sean put it well when he said we are in a "holding pattern" on these APIs
> right now.
>

I did understand Sean's statement on this and I'm not challenging
the current decision / status quo. My efforts to explore the effects on the
ecosystem is really just an exploration, if it becomes useful background
information to inform future reconsiderations of this issue, that's great.
If not, I'm at least learning a lot! :-)

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230419/ea6d1920/attachment.htm>

From Alan.Bateman at oracle.com  Wed Apr 19 07:37:14 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Apr 2023 08:37:14 +0100
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWht5LDvYBmcuLTMyyovx=_RBHHMQ9j22W8aitWi3jVrN0Q@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
 <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>
 <CA+pBWht5LDvYBmcuLTMyyovx=_RBHHMQ9j22W8aitWi3jVrN0Q@mail.gmail.com>
Message-ID: <eaa86df7-46b9-f9da-a8d3-c1285d6fc24e@oracle.com>

On 19/04/2023 08:23, Eirik Bj?rsn?s wrote:
>
>     Sean put it well when he said we are in a "holding pattern" on
>     these APIs right now.
>
>
> I did understand Sean's statement on this and I'm not challenging 
> the?current decision / status quo. My efforts to explore the effects 
> on the ecosystem?is really just an exploration, if it becomes useful 
> background information to inform future reconsiderations of this 
> issue, that's great. If not, I'm at least learning?a lot! :-)
>
I applaud your efforts. It's great to make projects aware that they are 
depending on APIs that are long deprecated and PRs with changes for them 
to consider. This is real contribution, and I think it will ultimately 
inform and help move these issues forward.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230419/80e996e3/attachment.htm>

From jpai at openjdk.org  Wed Apr 19 11:03:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Apr 2023 11:03:42 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <WXO66GUhEsyKKiGqeXyPiXelTU4uYW_30drXwykWFJc=.bc5c584d-6d95-49e4-b0ab-18cfd167ced0@github.com>

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Thank you for those details, Jiangli.

> 
> 
> > Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in?
> 
> Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK.

Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514538152


From eirbjo at gmail.com  Wed Apr 19 14:05:01 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 19 Apr 2023 16:05:01 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
Message-ID: <CA+pBWhs8RBu=bUDpeE1Q9QFDWG0D+tFxDmk9hTG5f9AOyceF+Q@mail.gmail.com>

TLDR: Payara 5 seems to work fine
with java.security.{Certificate,Identity,IdentityScope,Signer} classes
removed

I have been exploring the effects of removing these APIs on JBoss Wildfly
> 20, the latest version to support Java EE 8.
>

Repeating the experiment using Payara 5 shows similar results to Wildfly
20. EJBs calling methods in EJBContext continue to work as expected with
21-internal. If the deprecated EJBContext.getCallerIdentity() method is
called, an exception is thrown (not because of the API removal, but because
Payara decided to throw for this method):

Caused by: java.lang.RuntimeException: getCallerIdentity() is deprecated,
> please use getCallerPrincipal().
>         at
> com.sun.ejb.containers.EJBContextImpl.getCallerIdentity(EJBContextImpl.java:382)


I had to make a minor change to Payara 5 to make it run on Java 21, which
was to upgrade ASM from 9.4 to 9.5. I'll consider a PR for this, although
it seems they don't plan any more releases of Payara 5 Community edition.
Maybe a PR can prod them to upgrade the Enterprise offering.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230419/e7036e5f/attachment.htm>

From jiangli at openjdk.org  Wed Apr 19 15:18:44 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Apr 2023 15:18:44 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <WXO66GUhEsyKKiGqeXyPiXelTU4uYW_30drXwykWFJc=.bc5c584d-6d95-49e4-b0ab-18cfd167ced0@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
 <WXO66GUhEsyKKiGqeXyPiXelTU4uYW_30drXwykWFJc=.bc5c584d-6d95-49e4-b0ab-18cfd167ced0@github.com>
Message-ID: <Fx_cGxCivYtKssnHBwEXcd3PwVwAX5Nmq177-gGkuJU=.6c68fc95-2a7b-4c91-b4c5-793deeb5d224@github.com>

On Wed, 19 Apr 2023 11:01:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process.

Agreed, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514918976


From kvn at openjdk.org  Wed Apr 19 17:16:50 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 19 Apr 2023 17:16:50 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
In-Reply-To: <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
Message-ID: <Tmu6s4pnYsU6hGCtZHxIYVsC0YQptCXv6mVQEBaFARA=.7f0f59af-8af0-4ff1-84e4-6596c34356b3@github.com>

On Mon, 17 Apr 2023 16:17:30 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:
> 
>   Fix tests. Remember previous reducible Phis.

Submitted new testing

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

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


From kvn at openjdk.org  Thu Apr 20 00:37:49 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Apr 2023 00:37:49 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
In-Reply-To: <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
Message-ID: <W_0rFB3ABAoqAc8zlgxYp9NXzp_n4oNtBjrDviAm7P0=.5b83a96a-8e96-42aa-9b3a-e46908612416@github.com>

On Mon, 17 Apr 2023 16:17:30 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:
> 
>   Fix tests. Remember previous reducible Phis.

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]

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

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


From kvn at openjdk.org  Thu Apr 20 00:50:59 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Apr 2023 00:50:59 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
In-Reply-To: <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
Message-ID: <09b2gzJOWHojxvBpg79PfgQgD0qh56CqHJk484zJX-8=.f1df20ad-c202-4a20-a98b-c334e808eaae@github.com>

On Mon, 17 Apr 2023 16:17:30 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:
> 
>   Fix tests. Remember previous reducible Phis.

Also next 2 JVMCI tests failed:

compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java

#  Internal Error (/workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:829), pid=2430194, tid=2430218
#  fatal error: DEBUG MESSAGE: exact klass and actual klass differ

Could be due to [12810](https://git.openjdk.org/jdk/pull/12810)

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

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


From eirbjo at gmail.com  Thu Apr 20 07:14:07 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 20 Apr 2023 09:14:07 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <eaa86df7-46b9-f9da-a8d3-c1285d6fc24e@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
 <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>
 <CA+pBWht5LDvYBmcuLTMyyovx=_RBHHMQ9j22W8aitWi3jVrN0Q@mail.gmail.com>
 <eaa86df7-46b9-f9da-a8d3-c1285d6fc24e@oracle.com>
Message-ID: <CA+pBWhshYn0ZNuoOkgrQ-ed+3Uw78jV9txzRZKMJJ8izmdefQQ@mail.gmail.com>

>
> It's great to make projects aware that they are depending on APIs that are
> long deprecated and PRs with changes for them to consider.
>

I noticed that both the Payara and TomEE implementations of
jakarta.ejb.EJBContext include stale implementations of the methods
getEnvironment, getCallerIdentity and isCallerInRole(Identity), removed in
Jakarta 9. I have filed PRs to these projects to get those removed and also
add @Override where appropriate:

https://github.com/payara/Payara/pull/6268
https://github.com/apache/tomee/pull/1035

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230420/dfaf9094/attachment.htm>

From eirbjo at gmail.com  Thu Apr 20 10:32:43 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 20 Apr 2023 12:32:43 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <eaa86df7-46b9-f9da-a8d3-c1285d6fc24e@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
 <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>
 <CA+pBWht5LDvYBmcuLTMyyovx=_RBHHMQ9j22W8aitWi3jVrN0Q@mail.gmail.com>
 <eaa86df7-46b9-f9da-a8d3-c1285d6fc24e@oracle.com>
Message-ID: <CA+pBWhuRq6w2xqHEdhN4tUSUNdSRg_RL-1Ogr5WdVOE-dz97HA@mail.gmail.com>

> It's great to make projects aware that they are depending on APIs that are
> long deprecated
>

I gave Oracle WebLogic Server 14.1.1 a spin on 21-internal with Identity
and friends removed. This version of WLS supports Java EE 8.

Accessing an EJB with an injected EJBContext somewhat predictably fails
with a NoClassDefFoundError / ClassNotFoundException:

Root cause of ServletException.
> java.lang.NoClassDefFoundError: java/security/Identity
>         at
> weblogic.ejb.container.manager.StatefulSessionManager.allocateContext(StatefulSessionManager.java:947)
> [..]
> Caused By: java.lang.ClassNotFoundException: java.security.Identity
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)


I believe this NoClassDefFoundError has an easily fix, which is to move any
BaseEJBContext code touching java/security/Identity out of
the BaseEJBContext class, such that any class loading of
java/security/Identity is deferred until any of the deprecated methods are
actually called. This fix would allow apps not calling the deprecated
methods to deploy as usual in WLS using a JDK with these classes removed.

If anyone knows how to get in touch with relevant people in the WebLogic
organization to discuss this, please let me know in a private email.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230420/ae7ffce6/attachment.htm>

From cslucas at openjdk.org  Thu Apr 20 19:27:58 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 20 Apr 2023 19:27:58 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
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: <iGZ2Wdc6L3p5cys_sZxdZslylpQnF5q_zMk8q3uO-ro=.88cd8f67-17dc-4435-890a-b69d64059173@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 10 commits:

 - 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.
 - Merge master
 - Add support for rematerializing scalar replaced objects participating in allocation merges

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

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=09
  Stats: 2253 lines in 26 files changed: 1992 ins; 108 del; 153 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  Thu Apr 20 20:19:51 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 20 Apr 2023 20:19:51 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <iGZ2Wdc6L3p5cys_sZxdZslylpQnF5q_zMk8q3uO-ro=.88cd8f67-17dc-4435-890a-b69d64059173@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>
Message-ID: <bcUFa22sc7pIgMiv5bwPuBPNqwE5z1o_WzObgMEhW-4=.26b28dca-d2c7-4345-bb10-7224954df4de@github.com>

On Thu, 20 Apr 2023 19:27:58 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 10 commits:
> 
>  - 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.
>  - Merge master
>  - Add support for rematerializing scalar replaced objects participating in allocation merges

Thank you for testing, Vladimir. I was able to reproduce the IR test failures on AArch64 with -UseTLAB. I'll push a fix later today. 

Looks like the other failures are due to: https://bugs.openjdk.org/browse/JDK-8306581

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

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


From eirbjo at gmail.com  Thu Apr 20 22:19:14 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 21 Apr 2023 00:19:14 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWhuRq6w2xqHEdhN4tUSUNdSRg_RL-1Ogr5WdVOE-dz97HA@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhuZHdgkqnoJNA-OzXB2xz4Ytqy6B9A9RQajc4igYasDXQ@mail.gmail.com>
 <ed198bd1-1281-249c-9480-a02f044002a3@oracle.com>
 <CA+pBWht5LDvYBmcuLTMyyovx=_RBHHMQ9j22W8aitWi3jVrN0Q@mail.gmail.com>
 <eaa86df7-46b9-f9da-a8d3-c1285d6fc24e@oracle.com>
 <CA+pBWhuRq6w2xqHEdhN4tUSUNdSRg_RL-1Ogr5WdVOE-dz97HA@mail.gmail.com>
Message-ID: <CA+pBWhsvr=f1-FmSGQXfCg-sq7F6K9S80CzVF5VXEPyTRxmfbQ@mail.gmail.com>

>
> I gave Oracle WebLogic Server 14.1.1 a spin on 21-internal with Identity
> and friends removed. This version of WLS supports Java EE 8.
>

I tried the same for OpenLiberty (used in IBM WebSphere), and found two
separate problems:

1: The non-deprecated EJBContext.getCallerPrincipal() returns an instance
of java.security.Identity for the unauthenticated case. This method should
not initiate loading of this deprecated class, so an instance of
java.security.Principal should be returned instead.
2: A support class for the EJBContext implementation is loaded via
reflection using OSGi. The reflective Class.getConstructors() call fails
with java.security.Identity not present. This can be fixed by instead
constructing the instance of the service in Java via an OSGi ServiceFactory.

With these two issues fixed, OpenLiberty seems able to load and run apps
without the Identity class, as long as they are well behaved and don't call
the deprecated getCallerIdentity() method.

The above changes have been contributed to OpenLiberty as a PR:

https://github.com/OpenLiberty/open-liberty/pull/25070

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230421/5693f836/attachment.htm>

From eirbjo at gmail.com  Fri Apr 21 08:11:42 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 21 Apr 2023 10:11:42 +0200
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
Message-ID: <CA+pBWhvOEoQY1GzvvQguaL7YeEioXop4+qEDpBy60E5HoBxWWw@mail.gmail.com>

>
> Given that removing these APIs would cause TCK issues in these cases, I
> have been reticent to remove the APIs.
>

To assess TCK impact, I downloaded jakarta-jakartaeetck-8.0.2.zip [1] and
did a grep for getCallerIdentity:

% grep -R getCallerIdentity .
> ./src/com/sun/ts/tests/signaturetest/signature-repository/javax.ejb.sig_3.2_se8:meth
> public abstract java.security.Identity getCallerIdentity()


So it seems no TCK tests actually call the deprecated method, but there is
a set of API signature tests which seems to expect the EJBContext methods
to be present:

>From javax.ejb.sig_3.2_se8:

CLSS public abstract interface javax.ejb.EJBContext
> meth public abstract boolean getRollbackOnly()
> meth public abstract boolean isCallerInRole(java.lang.String)
> meth public abstract boolean isCallerInRole(java.security.Identity)
> meth public abstract java.lang.Object lookup(java.lang.String)
> meth public abstract java.security.Identity getCallerIdentity()
> ...


I have not been able to determine whether these signature tests will accept
the EJBContext signatures as present even when the JRE removes the class.
However, I'm hopeful that is the case, since it does seem that
./lib/sigtest.jar has a BinaryClassDescrLoader class which parses class
files directly, without any reflection.

Based on these observations, it seems running the TCK on a JRE without
java.security.Identity should either be a non-issue, or it should require
relatively small efforts to allow the TCK to run on such JREs.

Thanks,
Eirik.

[1] https://download.eclipse.org/jakartaee/platform/8/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230421/d4d07aa6/attachment.htm>

From Alan.Bateman at oracle.com  Fri Apr 21 08:35:20 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Apr 2023 09:35:20 +0100
Subject: Status: JDK-8191136 Remove deprecated java.security.{Certificate, 
 Identity, IdentityScope, Signer} APIs
In-Reply-To: <CA+pBWhvOEoQY1GzvvQguaL7YeEioXop4+qEDpBy60E5HoBxWWw@mail.gmail.com>
References: <CA+pBWhuY-jqUkCE3RSLs5BTqpAy0jj2TtNJtf7Lt9ixSNs4mGg@mail.gmail.com>
 <4b4db405-668e-67b9-abd0-c359d5e2c6bb@oracle.com>
 <CA+pBWhstD=53B=MYYwgeRPLVjGtXKSzjAd6U+7aFrab=S8cWLg@mail.gmail.com>
 <c72b8f2b-b36a-c07e-efa2-4eb256ec0185@oracle.com>
 <CA+pBWhvOEoQY1GzvvQguaL7YeEioXop4+qEDpBy60E5HoBxWWw@mail.gmail.com>
Message-ID: <2240d1d9-d3f5-93b8-625f-db62e9d2b1ea@oracle.com>

On 21/04/2023 09:11, Eirik Bj?rsn?s wrote:
> :
>
> Based on these observations, it seems running the TCK on a JRE without 
> java.security.Identity should either be a non-issue, or it should 
> require relatively small efforts to allow the TCK to run on such JREs.
>
I don't have access to the Java EE CTS or to the Jakarta equivalent. 
However, both Sean and I have been involved in several discussions about 
removing these APIs for several years.? There is uproar from legacy app 
servers maintainers whenever it comes up as they seem to certify against 
a wide range of both EE and JDK releases. I think we will eventually get 
there but I don't think it can happen right now.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230421/6330b046/attachment.htm>

From cslucas at openjdk.org  Fri Apr 21 15:10:49 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 21 Apr 2023 15:10:49 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
In-Reply-To: <W_0rFB3ABAoqAc8zlgxYp9NXzp_n4oNtBjrDviAm7P0=.5b83a96a-8e96-42aa-9b3a-e46908612416@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>
Message-ID: <8AmU_ta4meiUmO99Em5bV7XLAV4H9fAcil519yh70fU=.1a28f4a9-a992-43a7-8c4a-d1cf96835963@github.com>

On Thu, 20 Apr 2023 00:35:19 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?

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

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


From kvn at openjdk.org  Fri Apr 21 19:26:48 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 21 Apr 2023 19:26:48 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
In-Reply-To: <8AmU_ta4meiUmO99Em5bV7XLAV4H9fAcil519yh70fU=.1a28f4a9-a992-43a7-8c4a-d1cf96835963@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>
Message-ID: <vcnGjfICEd6umoRJsqkPk8ay68P3FqCTdy2I6IJbkCQ=.bc9d87d2-c2f4-4738-b934-830688a5d922@github.com>

On Fri, 21 Apr 2023 15:08:21 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> 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.

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

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


From eirbjo at gmail.com  Fri Apr 21 21:59:51 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 21 Apr 2023 23:59:51 +0200
Subject: Should deprecated classes CertException,
 CertParseError be marked forRemoval=true?
Message-ID: <CA+pBWhte_akR=jC9g7k2jsUyeXP-b2-ttaE3oa096PxyuOhKHQ@mail.gmail.com>

Hi,

JDK-8157707 [1] deprecated the java.security.Certificate API. In a comment
in that issue, Sean writes:

As part of this change, the internal classes
> sun.security.x509.CertException and sun.security.x509.CertParseError should
> be marked for removal (they are already deprecated) and removed when
> java.security.Certificate is removed.


I see that neither sun.security.x509.CertException
nor sun.security.x509.CertParseError are marked forRemoval today.

Was this an oversight? Should we fix it? Would be strange to
remove java.security.Certificate but leave these two, right?

I'm happy to do a PR and also CSR if that's required for these internal
classes.

Thanks,
Eirik.

[1] https://bugs.openjdk.org/browse/JDK-8157707
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230421/e45fd876/attachment.htm>

From xliu at openjdk.org  Fri Apr 21 22:02:50 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 21 Apr 2023 22:02:50 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <lolqjMiNtN45uvnBHAais5xsCOzKam6LhVJ-a1WXHi4=.9c2cfece-3bd4-40da-8db1-4872d91d77db@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <Fco8XVAwjuZJoOaK-fb7UzAu3y9utPQk17D6ncUAH6E=.f097a54d-8883-42f7-b81a-2a7b423511d5@github.com>
 <lolqjMiNtN45uvnBHAais5xsCOzKam6LhVJ-a1WXHi4=.9c2cfece-3bd4-40da-8db1-4872d91d77db@github.com>
Message-ID: <XOXwBtBOcscR3sZp12mqeNDCQ3FlJPMi-VAQhTOasrE=.40f73934-4ce2-4d2d-af60-83a97d53c82d@github.com>

On Fri, 14 Apr 2023 20:50:03 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/opto/escape.cpp line 457:
>> 
>>> 455:         found_sr_allocate = true;
>>> 456:       } else {
>>> 457:         ptn->set_scalar_replaceable(false);
>> 
>> This member function is const. Do we really need to change ptn's property here? 
>> 
>> My reading is ophi is profitable as long as we spot any input object which can be eliminated.  how about you just return at line 455?
>
> This is actually necessary here. By setting the input to NSR I don't need to later, when performing reduction, check that I can eliminate the node. I can just check that I can scalar replace the input. If I removed this line I'd hit a problem if the merge had an input that is SR but that ME can't eliminate.

okay. I see you mean.

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

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


From eirbjo at gmail.com  Fri Apr 21 22:14:01 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 22 Apr 2023 00:14:01 +0200
Subject: Should deprecated classes CertException,
 CertParseError be marked forRemoval=true?
In-Reply-To: <CA+pBWhte_akR=jC9g7k2jsUyeXP-b2-ttaE3oa096PxyuOhKHQ@mail.gmail.com>
References: <CA+pBWhte_akR=jC9g7k2jsUyeXP-b2-ttaE3oa096PxyuOhKHQ@mail.gmail.com>
Message-ID: <CA+pBWhtMVXUCHkbuLD=2iQR0Z1Cep9VVZHkTFEejsYcLMQvEGA@mail.gmail.com>

>
> JDK-8157707 [1] deprecated the java.security.Certificate API. In a comment
> in that issue, Sean writes:
>

Sorry, I meant to say that java.security.Certificate was marked
forRemoval=true in JDK-8157707, it was of course deprecated long before
that.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230422/2cb231e7/attachment.htm>

From vlivanov at openjdk.org  Sat Apr 22 02:00:56 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 22 Apr 2023 02:00:56 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <iGZ2Wdc6L3p5cys_sZxdZslylpQnF5q_zMk8q3uO-ro=.88cd8f67-17dc-4435-890a-b69d64059173@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>
Message-ID: <hIoa1Z7p8xL1ZsJtyPm6795tNohDHS1RngYI3RcxXlk=.534b69a9-1d47-455c-a66f-72035e1c3e81@github.com>

On Thu, 20 Apr 2023 19:27:58 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 10 commits:
> 
>  - 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.
>  - Merge master
>  - Add support for rematerializing scalar replaced objects participating in allocation merges

Nice work, Cesar! I like how the patch shapes now.

I'm not done with the review yet, but decided to share the comments I have so far.

src/hotspot/share/code/debugInfo.cpp line 232:

> 230:   // If we call select again on the same merge we should return the same result
> 231:   if (_selected != nullptr) {
> 232:     return _selected;

I'm not sure I understand how it is intended to work. The code below initializes `_selected`, but returns `nullptr` when `selector >= 0`. Subsequent calls will return non-null value.

src/hotspot/share/code/debugInfo.cpp line 257:

> 255:   } else {
> 256:     assert(selector < _possible_objects.length(), "sanity");
> 257:     _selected = (ObjectValue*) _possible_objects.at(selector);

Any particular reason to reuse `ObjectValue` from `_possible_objects` instead of allocating a fresh one (as you do on `selector == -1` bracnh)? I'd prefer `ObjectMergeValue::select()` to always allocate a fresh `ObjectValue` when converting `ObjectMergeValue` + `ObjectMergeCandidateValue` into `ObjectValue`.

src/hotspot/share/code/debugInfo.hpp line 199:

> 197: // ObjectValue describing an object that was scalar replaced.
> 198: 
> 199: class ObjectMergeValue: public ObjectValue {

I find the decision to subclass`ObjectValue` confusing and error prone: now `is_object()` returns true for `ObjectMergeValue`, but you have to apply the selector first to turn it into `ObjectValue`. And now the order of checks matter, so you always have to perform `is_object_merge()` first and then follow it with `is_object()` guard.

You have 3 flavors of `ObjectValue` now:
* good old `ObjectValue`;
* `ObjectMergeValue`
* merge candidates (`ObjectMergeCandidateValue`?)

Does it make sense to introduce 3 different subclasses under `ObjectValue` to clearly distinguish the scenarios?

src/hotspot/share/code/debugInfo.hpp line 242:

> 240:   bool                       is_cached() const          { return _cached; }
> 241:   void                       set_cached(bool cached)    { _cached = cached; }
> 242:   AutoBoxObjectValue(int id, ScopeValue* klass, bool only_merge_candidate = false) : ObjectValue(id, klass, only_merge_candidate), _cached(false) { }

Any particular reason to allow `AutoBoxObjectValue` to be a merge candidate?

src/hotspot/share/opto/escape.hpp line 593:

> 591:   // Methods related to Reduce Allocation Merges
> 592: 
> 593:   bool can_reduce_this_phi(PhiNode* ophi) const;

On naming: IMO referring to "this" doesn't help, but adds noise. If you drop it ("can_reduce_this_phi" => "can_reduce_phi"), it's still clear what the method does.

src/java.base/share/classes/java/security/AccessController.java line 786:

> 784:         // allocation merge Phi leading to it) might become NonEscaping and get
> 785:         // scalar replaced. The call below enforces 'result' to always escape.
> 786:         ensureMaterializedForStackWalk(result);

Why don't you add the same call in the other `executePrivileged` overload? It has the very same code shape.

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

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1396497913
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1174242946
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1174249820
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1174248472
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1174250881
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1174248735
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1174235850


From eirbjo at gmail.com  Mon Apr 24 06:32:41 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 24 Apr 2023 08:32:41 +0200
Subject: X509Factory cache control
Message-ID: <CA+pBWhsq6JOxoi7wGNRNO+2KS_N16BObWV_tnmA5MDvWFzrAjg@mail.gmail.com>

Hi,

When reaching out to the BouncyCastle community regarding the deprecated
javax.security.cert APIs, I got some interesting feedback from Matti Aarnio
of Methics Ltd:

Long ago we did encounter problems with JRE's X509CertImpl.java  class, and
> more so with X509CRLImpl.java. Both have internal caches of binary form
> input that is then converted to parsed forms.



Especially the CRL cache did not (still does not?) have nice "that version
> is obsoleted, drop it to garbage collection" handling of parsed CRLs, while
> it had way too large cache size.
> A server running for months and getting a new CRL every 12 hours
> eventually grew the memory footprint of obsolete parsed data up to
> ridiculous amounts of gigabytes of heap footprint.



Once we realized that also certificate parser had such a cache and that
> there is no official way to control that cache, we became very much averse
> of using those APIs.


It seems the lack of cache control of these static implementation caches
can be problematic, especially in the CRL case. The default for both caches
is a max number of entries of 750 with an unlimited lifetime. The inability
of expiring outdated CRLs seems particularly problematic for Matti.

A similar issue was reported in JDK-8059007 back in 2014, with the
following comment from Sean:

We need to introduce some system properties (or something similar) to allow
> the crl/cert caches to be adjusted. Changing to RFE.


While it would certainly be nice to add some form of cache control, the
solution space is large:

-1: Remove the cache. One could claim that the parser/factory level is the
wrong level to introduce parsing. There are so many ways to tune parsing,
there exists many excellent libraries. If apps need caching, they should
take care of it at the app level.

0: Do nothing, there haven't been that many complaints

1: Add an option to entirely disable the cache such that apps can do their
own caching (or not) without wasting space in the default cache.

2: Add two system properties to control max entries of the cert and crl
cache. Setting these to 0 would disable the cache.

3: Add four system properties to control max entries and max lifetime for
each of the cert and crl caches. Setting max entries to 0 would disable a
cache.

4: Tune the default max entries and lifetime to make everyone happy.

5: Add a pluggable API to control caching. Think
AbstractCacheControllingMaxEntrySizeProxyFactoryContext :-)

6: Something I did not consider.

-1 is probably not desired/possible because of the behavioural change. 1 is
simple but very constrained. 2 and 3 are similar in shape where 3 allows
more flexibility introducing lifetime. 4 seems like wishful thinking. You
could probably guess I'm not a big fan of 5. 6 seems promising :-)

I have a sketch implementation of 3 available, but it would be great to
gather some opinions before I put more work into this:

https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:x509factory-cache-config

Thanks,
Eirik.

[1] https://bugs.openjdk.org/browse/JDK-8059007
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230424/1143fbcb/attachment.htm>

From ecki at zusammenkunft.net  Mon Apr 24 08:27:57 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 24 Apr 2023 10:27:57 +0200
Subject: X509Factory cache control
In-Reply-To: <CA+pBWhsq6JOxoi7wGNRNO+2KS_N16BObWV_tnmA5MDvWFzrAjg@mail.gmail.com>
References: <CA+pBWhsq6JOxoi7wGNRNO+2KS_N16BObWV_tnmA5MDvWFzrAjg@mail.gmail.com>
Message-ID: <5046E38A-F1D5-B54A-BAED-F2B5375D9241@hxcore.ol>

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

From eirbjo at gmail.com  Mon Apr 24 09:00:31 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 24 Apr 2023 11:00:31 +0200
Subject: X509Factory cache control
In-Reply-To: <5046E38A-F1D5-B54A-BAED-F2B5375D9241@hxcore.ol>
References: <CA+pBWhsq6JOxoi7wGNRNO+2KS_N16BObWV_tnmA5MDvWFzrAjg@mail.gmail.com>
 <5046E38A-F1D5-B54A-BAED-F2B5375D9241@hxcore.ol>
Message-ID: <CA+pBWhsAHi=D0UsiMfY0SHkqpEak2wJAiZN-aPtrodQkuLOV9Q@mail.gmail.com>

On Mon, Apr 24, 2023 at 10:28?AM Bernd <ecki at zusammenkunft.net> wrote:

>  Not sure what exactly is cached, but for CRL only the latest CRL version
> should be cached and only for its lifetime (refresh time).
>

The current cache is not that sophisticated. It uses the encoded byte array
as a key which maps to the parsed CRL / cert. The lifetime is unlimited.

It is possible flush the (whole) cache by passing null parameters to
CertificateFactory methods (this is undocumented from what I can tell).

Also, CRLs get quite large, is it compressing the entire it caches?
>

My understanding is it caches the parsed CRL, yes. CRLs with an encoded
size larger than 4MB will not be cached, but 4MB parses into a more heap
memory.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230424/9aef31f3/attachment.htm>

From jiangli at openjdk.org  Mon Apr 24 17:27:44 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 24 Apr 2023 17:27:44 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <pwP2mPH3mRpd7e_5DTCz0mwrn4u8I7l9lXaJsWvZk5c=.23a79a2e-fbf9-4e32-b60a-3089d0ee9f1e@github.com>

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Gentle ping, please help review this PR. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1520559203


From sean.mullan at oracle.com  Mon Apr 24 17:39:25 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 24 Apr 2023 13:39:25 -0400
Subject: Should deprecated classes CertException, CertParseError be marked
 forRemoval=true?
In-Reply-To: <CA+pBWhte_akR=jC9g7k2jsUyeXP-b2-ttaE3oa096PxyuOhKHQ@mail.gmail.com>
References: <CA+pBWhte_akR=jC9g7k2jsUyeXP-b2-ttaE3oa096PxyuOhKHQ@mail.gmail.com>
Message-ID: <3d9de836-f933-dd5f-fb05-1f14ad7c789b@oracle.com>

I think these classes can be simply removed. These are internal classes 
which are not supported externally and strongly encapsulated by default. 
This is an internal class so it does not have to go through a 
"forRemoval" process before it is removed.

For my comment below, I was probably being overcareful, as
the sun.security.x509 classes have been in the JDK for a long time, and 
there may have been some external usages (even though not supported). 
But applications have had plenty of warnings by now not to use these 
internal APIs.

So I think it is safe to remove these now. It should not require a CSR.

--Sean

On 4/21/23 5:59 PM, Eirik Bj?rsn?s wrote:
> Hi,
> 
> JDK-8157707 [1] deprecated the java.security.Certificate API. In a 
> comment in that issue, Sean writes:
> 
>     As part of this change, the internal classes
>     sun.security.x509.CertException and sun.security.x509.CertParseError
>     should be marked for removal (they are already deprecated) and
>     removed when java.security.Certificate is removed.
> 
> 
> I see that neither?sun.security.x509.CertException 
> nor?sun.security.x509.CertParseError are marked forRemoval today.
> 
> Was this an oversight? Should we fix it? Would be strange to 
> remove?java.security.Certificate but leave these two, right?
> 
> I'm happy to do a PR and also CSR if that's required for these internal 
> classes.
> 
> Thanks,
> Eirik.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8157707 
> <https://bugs.openjdk.org/browse/JDK-8157707>
> 


From ascarpino at openjdk.org  Mon Apr 24 18:14:43 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 24 Apr 2023 18:14:43 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
Message-ID: <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>

On Tue, 18 Apr 2023 22:07:11 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:
> 
>   fine tuning spec

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 175:

> 173:             this.keyAlgorithm = keyAlgorithm;
> 174:             this.hkdfAlgorithm = hkdfAlgorithm;
> 175:             suiteId = concat("KEM".getBytes(StandardCharsets.UTF_8),

This is a general comment for all the `getBytes()` calls.  I think these should be static final values.  Each one of these usages is allocating a new String and byte[] every time.

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 202:

> 200:             } else {
> 201:                 byte[] uArray = ((XECPublicKey) k).getU().toByteArray();
> 202:                 return Arrays.copyOf(reverse(uArray), Npk);

You could just return the reversed array.  It is already a copy of the BigInteger 'u'.

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 206:

> 204:         }
> 205: 
> 206:         private static byte[] reverse(byte[] arr) {

It would be better to swap the bytes than allocating another array.
DeserializePublicKey() may need to copy 'data' or have two different reverse methods

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 346:

> 344:     private Params paramsFromKey(Key k) throws InvalidKeyException {
> 345:         if (k instanceof ECKey eckey) {
> 346:             if (ECUtil.equals(eckey.getParams(), CurveDB.lookup("secp256r1"))) {

These lookup calls look like they could be static final values

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 366:

> 364:     private static byte[] concat(byte[]... inputs) {
> 365:         ByteArrayOutputStream o = new ByteArrayOutputStream();
> 366:         Arrays.stream(inputs).forEach(o::writeBytes);

Unless I'm missing something there is no `stream(byte[])` support, so I'm not sure how this is compiling.  I didn't think  the generics would work with this.
More importantly, `forEach()` the API states that stream is in a non-deterministic order.  I think you want `forEachOrdered()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1175614103
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1174211748
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1174224442
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1175620516
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1175630598


From eirbjo at gmail.com  Mon Apr 24 18:20:52 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 24 Apr 2023 20:20:52 +0200
Subject: Should deprecated classes CertException,
 CertParseError be marked forRemoval=true?
In-Reply-To: <3d9de836-f933-dd5f-fb05-1f14ad7c789b@oracle.com>
References: <CA+pBWhte_akR=jC9g7k2jsUyeXP-b2-ttaE3oa096PxyuOhKHQ@mail.gmail.com>
 <3d9de836-f933-dd5f-fb05-1f14ad7c789b@oracle.com>
Message-ID: <CA+pBWht0TssaAkVnjUOERzdmpMRBiQhck4awCGiXi6SBVQirxg@mail.gmail.com>

On Mon, Apr 24, 2023 at 7:39?PM Sean Mullan <sean.mullan at oracle.com> wrote:

> So I think it is safe to remove these now. It should not require a CSR.
>

Great!

I've filed https://bugs.openjdk.org/browse/JDK-8306772 to track this.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230424/c8a01832/attachment.htm>

From duke at openjdk.org  Mon Apr 24 18:53:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 24 Apr 2023 18:53:23 GMT
Subject: RFR: 8306772: Remove sun.security.x509.CertException,
 sun.security.x509.CertParseError
Message-ID: <6RF1wxpWYwQKBj3cfJ3gjKLcUQYZPiI4K93MGd__OIA=.a74d77f6-ac9b-495c-bd7b-1769ba5445b9@github.com>

Please review this patch removes the classes `sun.security.x509.CertException` and `sun.security.x509.CertParseError`.

The classes have been deprecated since before OpenJDK. They are internal classes which are not supported externally and strongly encapsulated by default.

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

Commit messages:
 - Remove deprecated internal classes sun.security.x509.CertException, sun.security.x509.CertParseError

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

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


From weijun at openjdk.org  Mon Apr 24 19:40:43 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 24 Apr 2023 19:40:43 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
 <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
Message-ID: <4fNqd1oltzl7MdlXtZYubwfNl2uNF5nfh8PVJ-ovNss=.6bda3802-560a-461c-87f6-8155bc064913@github.com>

On Fri, 21 Apr 2023 22:50:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tuning spec
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 202:
> 
>> 200:             } else {
>> 201:                 byte[] uArray = ((XECPublicKey) k).getU().toByteArray();
>> 202:                 return Arrays.copyOf(reverse(uArray), Npk);
> 
> You could just return the reversed array.  It is already a copy of the BigInteger 'u'.

Is the size always `Npk`? It could be less (if small) or bigger (if MSB is 1).

> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 206:
> 
>> 204:         }
>> 205: 
>> 206:         private static byte[] reverse(byte[] arr) {
> 
> It would be better to swap the bytes than allocating another array.
> DeserializePublicKey() may need to copy 'data' or have two different reverse methods

Yes, I can.

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

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


From cslucas at openjdk.org  Mon Apr 24 19:50:22 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 24 Apr 2023 19:50:22 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <hIoa1Z7p8xL1ZsJtyPm6795tNohDHS1RngYI3RcxXlk=.534b69a9-1d47-455c-a66f-72035e1c3e81@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>
Message-ID: <h2n-P_I9GfDC9FqTeF1eIq2avKCc_57BleXaQNQwUw4=.0bc07139-63cd-4c3c-ad88-c1b33fea0e87@github.com>

On Sat, 22 Apr 2023 01:12:32 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 10 commits:
>> 
>>  - 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.
>>  - Merge master
>>  - Add support for rematerializing scalar replaced objects participating in allocation merges
>
> src/hotspot/share/code/debugInfo.cpp line 232:
> 
>> 230:   // If we call select again on the same merge we should return the same result
>> 231:   if (_selected != nullptr) {
>> 232:     return _selected;
> 
> I'm not sure I understand how it is intended to work. The code below initializes `_selected`, but returns `nullptr` when `selector >= 0`. Subsequent calls will return non-null value.

This can be improved. I'll fix it.

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

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


From weijun at openjdk.org  Mon Apr 24 19:54:24 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 24 Apr 2023 19:54:24 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
 <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
Message-ID: <7GOO4BdfXpk4LMTHyU7enVuJgDvucK2kKg1d7bqElDs=.62ad2c5a-2406-4a76-bcc0-ee8c36767252@github.com>

On Mon, 24 Apr 2023 17:53:09 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tuning spec
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 175:
> 
>> 173:             this.keyAlgorithm = keyAlgorithm;
>> 174:             this.hkdfAlgorithm = hkdfAlgorithm;
>> 175:             suiteId = concat("KEM".getBytes(StandardCharsets.UTF_8),
> 
> This is a general comment for all the `getBytes()` calls.  I think these should be static final values.  Each one of these usages is allocating a new String and byte[] every time.

OK.

> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 346:
> 
>> 344:     private Params paramsFromKey(Key k) throws InvalidKeyException {
>> 345:         if (k instanceof ECKey eckey) {
>> 346:             if (ECUtil.equals(eckey.getParams(), CurveDB.lookup("secp256r1"))) {
> 
> These lookup calls look like they could be static final values

Maybe I can define the static final values inside `CurveDB`.

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

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


From weijun at openjdk.org  Mon Apr 24 19:58:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 24 Apr 2023 19:58:21 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
 <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
Message-ID: <95zju77TlKmy9QgfylZ375rsyB_Iu-VnlAEeDRuxPpQ=.75f8d38a-0112-4d11-a3b4-ceb6ea9a978b@github.com>

On Mon, 24 Apr 2023 18:11:03 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tuning spec
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 366:
> 
>> 364:     private static byte[] concat(byte[]... inputs) {
>> 365:         ByteArrayOutputStream o = new ByteArrayOutputStream();
>> 366:         Arrays.stream(inputs).forEach(o::writeBytes);
> 
> Unless I'm missing something there is no `stream(byte[])` support, so I'm not sure how this is compiling.  I didn't think  the generics would work with this.
> More importantly, `forEach()` the API states that stream is in a non-deterministic order.  I think you want `forEachOrdered()`

`inputs` is `byte[][]` and there is a `Arrays.stream(T[])`.

The above method says a `sequential Stream` is returned. Does that mean calling `forEach` is safe?

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

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


From ascarpino at openjdk.org  Mon Apr 24 20:53:18 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 24 Apr 2023 20:53:18 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <4fNqd1oltzl7MdlXtZYubwfNl2uNF5nfh8PVJ-ovNss=.6bda3802-560a-461c-87f6-8155bc064913@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
 <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
 <4fNqd1oltzl7MdlXtZYubwfNl2uNF5nfh8PVJ-ovNss=.6bda3802-560a-461c-87f6-8155bc064913@github.com>
Message-ID: <SXF7N7wac3H3mnEP2_PH8hqy26jPinhUqAfGGaT2O9c=.0dbfbefd-fcb9-4e33-bef2-794bfe77b4d0@github.com>

On Mon, 24 Apr 2023 19:36:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 202:
>> 
>>> 200:             } else {
>>> 201:                 byte[] uArray = ((XECPublicKey) k).getU().toByteArray();
>>> 202:                 return Arrays.copyOf(reverse(uArray), Npk);
>> 
>> You could just return the reversed array.  It is already a copy of the BigInteger 'u'.
>
> Is the size always `Npk`? It could be less (if small) or bigger (if MSB is 1).

If I understand what your saying, if `Npk` is larger than `uArray`, then `copyOf()` will pad with zeros at the end.  I think that would change the value.  And I don't see why `Npk` would be smaller than `uArray` otherwise this would be returning an invalid key

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

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


From mark.powers at oracle.com  Mon Apr 24 22:01:38 2023
From: mark.powers at oracle.com (Mark Powers)
Date: Mon, 24 Apr 2023 22:01:38 +0000
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <pwP2mPH3mRpd7e_5DTCz0mwrn4u8I7l9lXaJsWvZk5c=.23a79a2e-fbf9-4e32-b60a-3089d0ee9f1e@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
 <pwP2mPH3mRpd7e_5DTCz0mwrn4u8I7l9lXaJsWvZk5c=.23a79a2e-fbf9-4e32-b60a-3089d0ee9f1e@github.com>
Message-ID: <DM6PR10MB30337A408C63380F5B1C6F6594679@DM6PR10MB3033.namprd10.prod.outlook.com>

I'll take a look.
________________________________
From: security-dev <security-dev-retn at openjdk.org> on behalf of Jiangli Zhou <jiangli at openjdk.org>
Sent: Monday, April 24, 2023 10:27 AM
To: jmx-dev at openjdk.org <jmx-dev at openjdk.org>; security-dev at openjdk.org <security-dev at openjdk.org>; serviceability-dev at openjdk.org <serviceability-dev at openjdk.org>
Subject: Re: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
>
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
>
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Gentle ping, please help review this PR. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1520559203
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230424/74e3816c/attachment.htm>

From mpowers at openjdk.org  Mon Apr 24 22:45:13 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 24 Apr 2023 22:45:13 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <brFM_0RQJsdxgHnI4YqjmbRON0r3CReyHZf4DxmMgJ4=.07f8e006-daa5-480f-924a-81e4a7db0cfe@github.com>

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Update copyrights to 2023.

src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201:

> 199:   cb = malloc(sizeof(struct gss_channel_bindings_struct));
> 200:   if (cb == NULL) {
> 201:     gssThrowOutOfMemoryError(env,NULL);

While you're fixing this, add a space between arguments, e.g. `(env,NULL) `becomes `(env, NULL)`.

src/java.security.jgss/share/native/libj2gss/NativeUtil.c line 456:

> 454: 
> 455: /* Throws a Java Exception by name */
> 456: static void throwByName(JNIEnv *env, const char *name, const char *msg) {

Why can't you move the few lines of `throwByName()` into `gssThrowOutOfMemoryError()` and totally remove `throwByName()`?

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

PR Review: https://git.openjdk.org/jdk/pull/13497#pullrequestreview-1398895019
PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175839776
PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175840162


From weijun at openjdk.org  Mon Apr 24 22:56:18 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 24 Apr 2023 22:56:18 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <SXF7N7wac3H3mnEP2_PH8hqy26jPinhUqAfGGaT2O9c=.0dbfbefd-fcb9-4e33-bef2-794bfe77b4d0@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
 <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
 <4fNqd1oltzl7MdlXtZYubwfNl2uNF5nfh8PVJ-ovNss=.6bda3802-560a-461c-87f6-8155bc064913@github.com>
 <SXF7N7wac3H3mnEP2_PH8hqy26jPinhUqAfGGaT2O9c=.0dbfbefd-fcb9-4e33-bef2-794bfe77b4d0@github.com>
Message-ID: <WCDmT6h_HBUhHhDrsYJpCuMwAjYx0CFUrqwzSaLf6zs=.cca73d81-da7c-4cf0-b7a7-4c8a208d632b@github.com>

On Mon, 24 Apr 2023 20:50:23 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Is the size always `Npk`? It could be less (if small) or bigger (if MSB is 1).
>
> If I understand what your saying, if `Npk` is larger than `uArray`, then `copyOf()` will pad with zeros at the end.  I think that would change the value.  And I don't see why `Npk` would be smaller than `uArray` otherwise this would be returning an invalid key

In fact, since the byte array is reversed, it's actually OK to pad zeros at the end without changing the value.

On the other hand, if the big integer's size is exact `Npk` but the most-significant-bit is 1, `toByteArray` will add an extra 00 at the beginning to keep it positive. In this case, the byte array length is `Npk + 1`. After reversed we can truncate the extra 00 byte now at the end.

Fascinating, isn't it?

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

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


From cslucas at openjdk.org  Tue Apr 25 00:14:13 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 25 Apr 2023 00:14:13 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <hIoa1Z7p8xL1ZsJtyPm6795tNohDHS1RngYI3RcxXlk=.534b69a9-1d47-455c-a66f-72035e1c3e81@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>
Message-ID: <aNMOXsTlucgR8Plv8JLhzixCxqovWrV3jz29tRH7c78=.b9f0b781-b7c3-457e-b125-c521a9ad5a6e@github.com>

On Sat, 22 Apr 2023 01:52:37 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 10 commits:
>> 
>>  - 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.
>>  - Merge master
>>  - Add support for rematerializing scalar replaced objects participating in allocation merges
>
> src/hotspot/share/code/debugInfo.cpp line 257:
> 
>> 255:   } else {
>> 256:     assert(selector < _possible_objects.length(), "sanity");
>> 257:     _selected = (ObjectValue*) _possible_objects.at(selector);
> 
> Any particular reason to reuse `ObjectValue` from `_possible_objects` instead of allocating a fresh one (as you do on `selector == -1` bracnh)? I'd prefer `ObjectMergeValue::select()` to always allocate a fresh `ObjectValue` when converting `ObjectMergeValue` + `ObjectMergeCandidateValue` into `ObjectValue`.

@iwanowww - may I ask why always allocating a fresh object might be better than returning a pointer to a previous "selected" object?

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

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


From cslucas at openjdk.org  Tue Apr 25 00:38:23 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 25 Apr 2023 00:38:23 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <hIoa1Z7p8xL1ZsJtyPm6795tNohDHS1RngYI3RcxXlk=.534b69a9-1d47-455c-a66f-72035e1c3e81@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>
Message-ID: <svqmY6m7RaZrsMBG7wp-gsMbbzTan4u31NuDL2ErhVk=.7cd11ca0-f298-4789-be73-d338a0dd2cc5@github.com>

On Sat, 22 Apr 2023 01:42:41 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Does it make sense to introduce 3 different subclasses under ObjectValue to clearly distinguish the scenarios?

I think that's a good idea. I'll give it a shot. Thanks.

> src/java.base/share/classes/java/security/AccessController.java line 786:
> 
>> 784:         // allocation merge Phi leading to it) might become NonEscaping and get
>> 785:         // scalar replaced. The call below enforces 'result' to always escape.
>> 786:         ensureMaterializedForStackWalk(result);
> 
> Why don't you add the same call in the other `executePrivileged` overload? It has the very same code shape.

Totally missed that!

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

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


From jiangli at openjdk.org  Tue Apr 25 00:47:17 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 25 Apr 2023 00:47:17 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries [v2]
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <epypaaWkZiKosa7Laxu-zAi78fyL-AgUaQZdMHlCXzM=.ce88c62c-51f3-49aa-82e5-74325ec38391@github.com>

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

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

  Minor updates, as suggested by mcpowers:
  - Update copyright headers in affected files.
  - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c.
  - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13497/files
  - new: https://git.openjdk.org/jdk/pull/13497/files/9d319df6..fcb35192

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

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

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


From jiangli at openjdk.org  Tue Apr 25 00:47:20 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 25 Apr 2023 00:47:20 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries [v2]
In-Reply-To: <brFM_0RQJsdxgHnI4YqjmbRON0r3CReyHZf4DxmMgJ4=.07f8e006-daa5-480f-924a-81e4a7db0cfe@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
 <brFM_0RQJsdxgHnI4YqjmbRON0r3CReyHZf4DxmMgJ4=.07f8e006-daa5-480f-924a-81e4a7db0cfe@github.com>
Message-ID: <4ezRtZpp6IfNoO_w2nyu2FA9GAy5k8FUrppmfd0pCqQ=.36ad7365-ae7f-40af-b0ff-86f1cfc60175@github.com>

On Mon, 24 Apr 2023 22:41:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Update copyrights to 2023.

Done, thanks.

> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201:
> 
>> 199:   cb = malloc(sizeof(struct gss_channel_bindings_struct));
>> 200:   if (cb == NULL) {
>> 201:     gssThrowOutOfMemoryError(env,NULL);
> 
> While you're fixing this, add a space between arguments, e.g. `(env,NULL) `becomes `(env, NULL)`.

Done, thanks.

> src/java.security.jgss/share/native/libj2gss/NativeUtil.c line 456:
> 
>> 454: 
>> 455: /* Throws a Java Exception by name */
>> 456: static void throwByName(JNIEnv *env, const char *name, const char *msg) {
> 
> Why can't you move the few lines of `throwByName()` into `gssThrowOutOfMemoryError()` and totally remove `throwByName()`?

Updated as suggested, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1521007212
PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175910048
PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175910110


From mullan at openjdk.org  Tue Apr 25 14:16:12 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Apr 2023 14:16:12 GMT
Subject: RFR: 8304845: Update PCSC-Lite for Suse Linux to 1.9.9 and fix
 incomplete license wording [v2]
In-Reply-To: <teAe1iz0CJvcYBiYW1uiAyfJAMKCeh7jY_C_gNQk5uA=.2f47f526-a208-461a-a4a0-3c52b11a7564@github.com>
References: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
 <teAe1iz0CJvcYBiYW1uiAyfJAMKCeh7jY_C_gNQk5uA=.2f47f526-a208-461a-a4a0-3c52b11a7564@github.com>
Message-ID: <XgGfV6uH0m1Irr6s1I1S7uwiD-NnlY5UqyKVFVYS0Yo=.10bf4564-1501-4f3a-b2a2-eed0236707ca@github.com>

On Wed, 12 Apr 2023 18:39:40 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone please help review this fix? Besides updating the md and COPYING files to address the incomplete license issue, this PR also updates the version to 1.9.9.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo fix

For the JBS issue, I suggest using a different `noreg` tag than `noreg-doc` since technically there is source code (`psclite.h`) that has been changed. Perhaps `noreg-trivial` or `noreg-other`. Otherwise, looks good.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13409#pullrequestreview-1400022233


From mullan at openjdk.org  Tue Apr 25 16:01:08 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Apr 2023 16:01:08 GMT
Subject: RFR: 8306772: Remove sun.security.x509.CertException,
 sun.security.x509.CertParseError
In-Reply-To: <6RF1wxpWYwQKBj3cfJ3gjKLcUQYZPiI4K93MGd__OIA=.a74d77f6-ac9b-495c-bd7b-1769ba5445b9@github.com>
References: <6RF1wxpWYwQKBj3cfJ3gjKLcUQYZPiI4K93MGd__OIA=.a74d77f6-ac9b-495c-bd7b-1769ba5445b9@github.com>
Message-ID: <qKNiSRZy-wqDMPV5o-WLFjFtc8jsSBZUphadGg1XJ_8=.cfcaa322-cd6e-4199-8221-07669d18e936@github.com>

On Mon, 24 Apr 2023 18:42:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this patch which removes the classes `sun.security.x509.CertException` and `sun.security.x509.CertParseError`.
> 
> These classes have been deprecated since before OpenJDK. They are internal classes which are not supported externally and strongly encapsulated by default.

Add a `noreg` label to the issue. Otherwise, LGTM. Just for added assurance, I also ran a search on usages of these classes in Maven artifacts using an internal tool, and it found 0 matches.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13624#pullrequestreview-1400253611


From duke at openjdk.org  Tue Apr 25 16:11:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 25 Apr 2023 16:11:11 GMT
Subject: RFR: 8306772: Remove sun.security.x509.CertException,
 sun.security.x509.CertParseError
In-Reply-To: <qKNiSRZy-wqDMPV5o-WLFjFtc8jsSBZUphadGg1XJ_8=.cfcaa322-cd6e-4199-8221-07669d18e936@github.com>
References: <6RF1wxpWYwQKBj3cfJ3gjKLcUQYZPiI4K93MGd__OIA=.a74d77f6-ac9b-495c-bd7b-1769ba5445b9@github.com>
 <qKNiSRZy-wqDMPV5o-WLFjFtc8jsSBZUphadGg1XJ_8=.cfcaa322-cd6e-4199-8221-07669d18e936@github.com>
Message-ID: <FAxnr-3Or77FmGPNLG7-jwr8ak88gW5CLxaFJHIiMpo=.a92fc4b7-003b-46b4-b40f-f0e56cc08c6d@github.com>

On Tue, 25 Apr 2023 15:58:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Add a `noreg` label to the issue. Otherwise, LGTM.

Added "noreg-cleanup" with an small justification in the description.

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

PR Comment: https://git.openjdk.org/jdk/pull/13624#issuecomment-1522058524


From duke at openjdk.org  Tue Apr 25 16:36:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 25 Apr 2023 16:36:16 GMT
Subject: Integrated: 8306772: Remove sun.security.x509.CertException,
 sun.security.x509.CertParseError
In-Reply-To: <6RF1wxpWYwQKBj3cfJ3gjKLcUQYZPiI4K93MGd__OIA=.a74d77f6-ac9b-495c-bd7b-1769ba5445b9@github.com>
References: <6RF1wxpWYwQKBj3cfJ3gjKLcUQYZPiI4K93MGd__OIA=.a74d77f6-ac9b-495c-bd7b-1769ba5445b9@github.com>
Message-ID: <XACmur9_t8nJQznmsMfN1pFRayhGLnfwCPtLlVKnOo4=.50a67918-961c-441b-bd10-88242fbdf29d@github.com>

On Mon, 24 Apr 2023 18:42:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this patch which removes the classes `sun.security.x509.CertException` and `sun.security.x509.CertParseError`.
> 
> These classes have been deprecated since before OpenJDK. They are internal classes which are not supported externally and strongly encapsulated by default.

This pull request has now been integrated.

Changeset: c92883a3
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c92883a3d540b8b6d28e31e1525d74b48161578c
Stats:     220 lines in 2 files changed: 0 ins; 220 del; 0 mod

8306772: Remove sun.security.x509.CertException, sun.security.x509.CertParseError

Reviewed-by: mullan

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

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


From valeriep at openjdk.org  Tue Apr 25 17:47:08 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 25 Apr 2023 17:47:08 GMT
Subject: RFR: 8304845: Update PCSC-Lite for Suse Linux to 1.9.9 and fix
 incomplete license wording [v2]
In-Reply-To: <XgGfV6uH0m1Irr6s1I1S7uwiD-NnlY5UqyKVFVYS0Yo=.10bf4564-1501-4f3a-b2a2-eed0236707ca@github.com>
References: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
 <teAe1iz0CJvcYBiYW1uiAyfJAMKCeh7jY_C_gNQk5uA=.2f47f526-a208-461a-a4a0-3c52b11a7564@github.com>
 <XgGfV6uH0m1Irr6s1I1S7uwiD-NnlY5UqyKVFVYS0Yo=.10bf4564-1501-4f3a-b2a2-eed0236707ca@github.com>
Message-ID: <f2lw-rCpvZIa1igBwaPBw_h0XW6apwZq-zZewplvelw=.42c48844-2013-4689-a1f4-92fc14d5a40e@github.com>

On Tue, 25 Apr 2023 14:13:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> For the JBS issue, I suggest using a different `noreg` tag than `noreg-doc` since technically there is source code (`psclite.h`) that has been changed. Perhaps `noreg-trivial` or `noreg-other`. Otherwise, looks good.

Makes sense, will change. Thanks for the review~

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

PR Comment: https://git.openjdk.org/jdk/pull/13409#issuecomment-1522175775


From valeriep at openjdk.org  Tue Apr 25 17:52:19 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 25 Apr 2023 17:52:19 GMT
Subject: Integrated: 8304845: Update PCSC-Lite for Suse Linux to 1.9.9 and fix
 incomplete license wording
In-Reply-To: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
References: <MUuOCGJ4CJuQSBSa7kCKiMF4xvHPb5nuOvMarRaV3R8=.f9923590-4386-4156-8edb-3ce95c41a924@github.com>
Message-ID: <l_GhfvIy8FZLg2pqZeAhHuHqoSY-VWJMTLZ44KGCnuo=.3e79fde8-069e-4784-a0c6-a25f96d549dd@github.com>

On Mon, 10 Apr 2023 16:56:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this fix? Besides updating the md and COPYING files to address the incomplete license issue, this PR also updates the version to 1.9.9.

This pull request has now been integrated.

Changeset: 33d66141
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33d661415056107742e16d24efdd5a063a2eb81f
Stats:     123 lines in 3 files changed: 36 ins; 69 del; 18 mod

8304845: Update PCSC-Lite for Suse Linux to 1.9.9 and fix incomplete license wording

Reviewed-by: manc, mullan

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

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


From vlivanov at openjdk.org  Tue Apr 25 21:22:35 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Apr 2023 21:22:35 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <aNMOXsTlucgR8Plv8JLhzixCxqovWrV3jz29tRH7c78=.b9f0b781-b7c3-457e-b125-c521a9ad5a6e@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>
 <aNMOXsTlucgR8Plv8JLhzixCxqovWrV3jz29tRH7c78=.b9f0b781-b7c3-457e-b125-c521a9ad5a6e@github.com>
Message-ID: <8OlLs3nmBxAKP_OcaZPhC3g1lNpfXJQ6zYCx2XNB43A=.055edcf3-96b7-4f97-9153-fdfe26bb0c0b@github.com>

On Tue, 25 Apr 2023 00:10:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/code/debugInfo.cpp line 257:
>> 
>>> 255:   } else {
>>> 256:     assert(selector < _possible_objects.length(), "sanity");
>>> 257:     _selected = (ObjectValue*) _possible_objects.at(selector);
>> 
>> Any particular reason to reuse `ObjectValue` from `_possible_objects` instead of allocating a fresh one (as you do on `selector == -1` bracnh)? I'd prefer `ObjectMergeValue::select()` to always allocate a fresh `ObjectValue` when converting `ObjectMergeValue` + `ObjectMergeCandidateValue` into `ObjectValue`.
>
> @iwanowww - may I ask why always allocating a fresh object might be better than returning a pointer to a previous "selected" object?

I don't mind there's caching happening if it gives any noticeable benefit. As of now, the code around doesn't care, probably, because it is allocated in resource arena.

What I'm against is repurposing existing instances: don't modify a candidate object into a "real object", allocate a fresh one instead.

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

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


From duke at openjdk.org  Tue Apr 25 21:24:43 2023
From: duke at openjdk.org (Sergey Chernyshev)
Date: Tue, 25 Apr 2023 21:24:43 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity
Message-ID: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@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

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

Commit messages:
 - 8168469: Memory leak in JceSecurity

Changes: https://git.openjdk.org/jdk/pull/13658/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8168469
  Stats: 110 lines in 2 files changed: 84 ins; 7 del; 19 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 cslucas at openjdk.org  Tue Apr 25 21:40:15 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 25 Apr 2023 21:40:15 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <8OlLs3nmBxAKP_OcaZPhC3g1lNpfXJQ6zYCx2XNB43A=.055edcf3-96b7-4f97-9153-fdfe26bb0c0b@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>
 <aNMOXsTlucgR8Plv8JLhzixCxqovWrV3jz29tRH7c78=.b9f0b781-b7c3-457e-b125-c521a9ad5a6e@github.com>
 <8OlLs3nmBxAKP_OcaZPhC3g1lNpfXJQ6zYCx2XNB43A=.055edcf3-96b7-4f97-9153-fdfe26bb0c0b@github.com>
Message-ID: <5HmQ644vtSgf7NylFeEsQXfU8DC9W-zk3ayYq373LF4=.8fba7762-07b2-45b8-a002-1ad2c0c05b0e@github.com>

On Tue, 25 Apr 2023 21:19:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> @iwanowww - may I ask why always allocating a fresh object might be better than returning a pointer to a previous "selected" object?
>
> I don't mind there's caching happening if it gives any noticeable benefit. As of now, the code around doesn't care, probably, because it is allocated in resource arena.
> 
> What I'm against is repurposing existing instances: don't modify a candidate object into a "real object", allocate a fresh one instead.

Thanks for clarifying. There is one scenario where turning the candidate into a "real object" simplify the implementation _greatly_. The scenario is when the ObjectValue is not just a candidate. I.e., the ObjectValue is also used independently of the merge. Example:


Point p = new Point();
Point q = new Point();
if (cond) p = q;
trap(p, q);


Second issue, is that allocating a fresh ObjectValue will require copying the array of field values from the candidate object to the newly allocated object. That's not a big issue, just pointing that out, though.

I propose that we allocate a fresh ObjectValue if the candidate is just a candidate (not used independent of merge) and if the candidate is not just a candidate we return the existing ObjectValue (turned 'real object'). I have that implemented, I can push it for you to take a look. What do you think?

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

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


From weijun at openjdk.org  Tue Apr 25 23:47:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Apr 2023 23:47:38 GMT
Subject: RFR: 8302182: Update Public Suffix List to 88467c9
Message-ID: <ltatey3heycqYvUR9eU0RI69QVATls7H-NwX7MWpi20=.478b64b2-3454-4815-9e84-35ec70727fe4@github.com>

Update PSL for JDK 21.

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

Commit messages:
 - the upgrade

Changes: https://git.openjdk.org/jdk/pull/13662/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302182
  Stats: 1479 lines in 5 files changed: 647 ins; 697 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/13662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13662/head:pull/13662

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


From weijun at openjdk.org  Wed Apr 26 00:04:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 00:04:53 GMT
Subject: RFR: 8297878: KEM: Implementation [v8]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <sZfke_4JXYcpHt8YUopU3Nem3Iayqc5ukNhSJ5mUTm4=.62c51167-08cb-47a4-b4ba-3e8f066b6a82@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:

  some constants, no local reverse

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/d1a7f3e8..38608993

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

  Stats: 75 lines in 4 files changed: 25 ins; 22 del; 28 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 jpai at openjdk.org  Wed Apr 26 10:28:02 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Apr 2023 10:28:02 GMT
Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match
 resuming session
Message-ID: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>

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.

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

Commit messages:
 - 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session

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

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


From duke at openjdk.org  Wed Apr 26 11:22:04 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 26 Apr 2023 11:22:04 GMT
Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match
 resuming session
In-Reply-To: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
References: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
Message-ID: <eEcsPFmh-tpG5Ab4sJLWmdS3Z8PEnUbry7OEsJ2YMCM=.f7d13192-7b86-404b-b7d2-67fcea72ec38@github.com>

On Wed, 26 Apr 2023 10:02:49 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.

test/jdk/javax/net/ssl/SSLSession/ServerNameRejectedTLSSessionResumption.java line 44:

> 42:  *          during TLS handshake, then the subsequent communication between the server and the
> 43:  *          client happens correctly without any errors
> 44:  * @run main/othervm -Djavax.net.ssl.keyStore=${test.src}/../etc/keystore

We've been trying to move away from using the binary keystore and truststore files. The alternative is to extend `SSLContextTemplate` and use `createServerSSLContext()` and `createClientSSLContext()` methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13669#discussion_r1177724752


From alanb at openjdk.org  Wed Apr 26 11:22:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Apr 2023 11:22:23 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries [v2]
In-Reply-To: <epypaaWkZiKosa7Laxu-zAi78fyL-AgUaQZdMHlCXzM=.ce88c62c-51f3-49aa-82e5-74325ec38391@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
 <epypaaWkZiKosa7Laxu-zAi78fyL-AgUaQZdMHlCXzM=.ce88c62c-51f3-49aa-82e5-74325ec38391@github.com>
Message-ID: <ocN6qj7DshViPbhpeLvU8likJEuGEihuBCiqW4z2t0Y=.eb7aaa8f-21f8-423c-a4f6-2d60da129ae7@github.com>

On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> - Make functions 'static' when feasible:
>>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
>> 
>> - Rename functions by following the existing naming usages in different libraries code:
>>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
>> 
>> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
>> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor updates, as suggested by mcpowers:
>   - Update copyright headers in affected files.
>   - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c.
>   - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.

I think this looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13497#pullrequestreview-1401741433


From jpai at openjdk.org  Wed Apr 26 11:51:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Apr 2023 11:51:23 GMT
Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match
 resuming session [v2]
In-Reply-To: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
References: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
Message-ID: <EiV-EIgnQQUQj5XlZM4wm7k3hMsq-8a3yh54lzMLE6g=.2ca17327-6fd8-40ee-8231-06ac0a74b1d9@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13669/files
  - new: https://git.openjdk.org/jdk/pull/13669/files/33cb85fe..57df739d

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

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

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


From jpai at openjdk.org  Wed Apr 26 11:55:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Apr 2023 11:55:24 GMT
Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match
 resuming session [v2]
In-Reply-To: <eEcsPFmh-tpG5Ab4sJLWmdS3Z8PEnUbry7OEsJ2YMCM=.f7d13192-7b86-404b-b7d2-67fcea72ec38@github.com>
References: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
 <eEcsPFmh-tpG5Ab4sJLWmdS3Z8PEnUbry7OEsJ2YMCM=.f7d13192-7b86-404b-b7d2-67fcea72ec38@github.com>
Message-ID: <khuJXJx-cFIObCSOiFcvrWfETVZSxl4k7THx4r-iA6I=.0e39883b-8db2-4ec4-b438-fd72383a8fc2@github.com>

On Wed, 26 Apr 2023 11:14:57 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> 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
>
> test/jdk/javax/net/ssl/SSLSession/ServerNameRejectedTLSSessionResumption.java line 44:
> 
>> 42:  *          during TLS handshake, then the subsequent communication between the server and the
>> 43:  *          client happens correctly without any errors
>> 44:  * @run main/othervm -Djavax.net.ssl.keyStore=${test.src}/../etc/keystore
> 
> We've been trying to move away from using the binary keystore and truststore files. The alternative is to extend `SSLContextTemplate` and use `createServerSSLContext()` and `createClientSSLContext()` methods.

Thank you Matthew for that review. I've now updated the PR to extend the `SSLContextTemplate` and use its APIs for `SSLContext` creation in the test.

With this updated test, I've verified that the test continues to fail (as expected) without the source fix and passes with the fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13669#discussion_r1177748488


From weijun at openjdk.org  Wed Apr 26 14:29:25 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 14:29:25 GMT
Subject: RFR: 8297878: KEM: Implementation [v9]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <NPgYS8mla8CiXJ3xbR5dMO3yqw32HOCyH6AvrOORNBM=.573e1e91-0ade-46c5-a570-b62dd1fbe6b9@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:

  small spec change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/38608993..c33ef612

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

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 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 jiangli at openjdk.org  Wed Apr 26 15:02:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Apr 2023 15:02:23 GMT
Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries [v2]
In-Reply-To: <epypaaWkZiKosa7Laxu-zAi78fyL-AgUaQZdMHlCXzM=.ce88c62c-51f3-49aa-82e5-74325ec38391@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
 <epypaaWkZiKosa7Laxu-zAi78fyL-AgUaQZdMHlCXzM=.ce88c62c-51f3-49aa-82e5-74325ec38391@github.com>
Message-ID: <mF1MpDqHZA3_tc1y7_x5va4bY8d8ltRTCCwGA6qG7eU=.2cf00a75-d9f6-4066-a49f-7fdaffcc3c7f@github.com>

On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> - Make functions 'static' when feasible:
>>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
>> 
>> - Rename functions by following the existing naming usages in different libraries code:
>>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
>> 
>> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
>> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor updates, as suggested by mcpowers:
>   - Update copyright headers in affected files.
>   - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c.
>   - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1523566931


From jiangli at openjdk.org  Wed Apr 26 16:16:02 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Apr 2023 16:16:02 GMT
Subject: Integrated: 8306033: Resolve multiple definition of 'throwIOException'
 and friends when statically linking with JDK native libraries
In-Reply-To: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
References: <oioyxT6B6d_kZXiR467NBpcVMkuIfChI5d3JC7Juia4=.56c9faa6-b64e-4442-905d-3075eb385652@github.com>
Message-ID: <KkAiXxB0J_uT1Qhpn6Oi1WUsF7FshpyXioRgso93PPc=.5ee51a5f-d2c0-42ff-8bc6-a52b3ae51184@github.com>

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

This pull request has now been integrated.

Changeset: 9bc6a212
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bc6a212f70eede108a8d3bc1ba1f780722b6e33
Stats:     194 lines in 25 files changed: 17 ins; 34 del; 143 mod

8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries

Reviewed-by: alanb

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

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


From cslucas at openjdk.org  Wed Apr 26 17:28:53 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 26 Apr 2023 17:28:53 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v11]
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: <6I1KVkFSekhMTTDq6nXQNoKPE96bycERRtsPrTnZZvU=.c1933f7f-e659-4e22-93a3-e7fbbcdf53a1@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 part of PR review 4 & fix a bug setting only_candidate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/329d9f40..78435065

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

  Stats: 72 lines in 8 files changed: 15 ins; 17 del; 40 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 mullan at openjdk.org  Wed Apr 26 17:40:52 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Apr 2023 17:40:52 GMT
Subject: RFR: 8302182: Update Public Suffix List to 88467c9
In-Reply-To: <ltatey3heycqYvUR9eU0RI69QVATls7H-NwX7MWpi20=.478b64b2-3454-4815-9e84-35ec70727fe4@github.com>
References: <ltatey3heycqYvUR9eU0RI69QVATls7H-NwX7MWpi20=.478b64b2-3454-4815-9e84-35ec70727fe4@github.com>
Message-ID: <pnpIRu8ldrGOz2NHiOBf3xDE3YqxoJvKoxOKZwoZggE=.e303a9fe-5b3b-43cd-92e3-e9f1ea66b0db@github.com>

On Tue, 25 Apr 2023 23:40:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update PSL for JDK 21.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13662#pullrequestreview-1402478499


From weijun at openjdk.org  Wed Apr 26 17:41:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 17:41:23 GMT
Subject: Integrated: 8302182: Update Public Suffix List to 88467c9
In-Reply-To: <ltatey3heycqYvUR9eU0RI69QVATls7H-NwX7MWpi20=.478b64b2-3454-4815-9e84-35ec70727fe4@github.com>
References: <ltatey3heycqYvUR9eU0RI69QVATls7H-NwX7MWpi20=.478b64b2-3454-4815-9e84-35ec70727fe4@github.com>
Message-ID: <kZB73-IW_1MDWkBlNRMis0W05XMgjE3tT1Qcth6oYHg=.0899d7fc-c5d8-48e1-be60-3aa34d7f873e@github.com>

On Tue, 25 Apr 2023 23:40:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update PSL for JDK 21.

This pull request has now been integrated.

Changeset: 01b85129
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01b85129116dd2cc762e518ac631305bd8511764
Stats:     1479 lines in 5 files changed: 647 ins; 697 del; 135 mod

8302182: Update Public Suffix List to 88467c9

Reviewed-by: mullan

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

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


From mullan at openjdk.org  Wed Apr 26 17:54:52 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Apr 2023 17:54:52 GMT
Subject: RFR: 8297878: KEM: Implementation [v9]
In-Reply-To: <8bHDa13a4vgSx2M3EBpjxnMZEIvXRlmDeDEETErwUM8=.0d9c7013-dfc0-4342-b5d2-52b07ef33dde@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <8bHDa13a4vgSx2M3EBpjxnMZEIvXRlmDeDEETErwUM8=.0d9c7013-dfc0-4342-b5d2-52b07ef33dde@github.com>
Message-ID: <PgUxbczfU2R0659vHP9XWsP4i3didmKYn52VTSqUpjU=.06fd4ccf-a5cc-4774-be3b-7052821b2655@github.com>

On Wed, 12 Apr 2023 15:22:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small spec change
>
> src/java.base/share/classes/javax/crypto/KEMSpi.java line 236:
> 
>> 234:      *
>> 235:      * @param sk the receiver's private key. This argument is never {@code null}.
>> 236:      * @param spec the parameter, can be {@code null}
> 
> "the optional parameter, ..." (use same wording as engineNewEncapsulator).

Don't see that this is fixed yet.

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

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


From vlivanov at openjdk.org  Wed Apr 26 17:53:25 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 26 Apr 2023 17:53:25 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <5HmQ644vtSgf7NylFeEsQXfU8DC9W-zk3ayYq373LF4=.8fba7762-07b2-45b8-a002-1ad2c0c05b0e@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>
 <aNMOXsTlucgR8Plv8JLhzixCxqovWrV3jz29tRH7c78=.b9f0b781-b7c3-457e-b125-c521a9ad5a6e@github.com>
 <8OlLs3nmBxAKP_OcaZPhC3g1lNpfXJQ6zYCx2XNB43A=.055edcf3-96b7-4f97-9153-fdfe26bb0c0b@github.com>
 <5HmQ644vtSgf7NylFeEsQXfU8DC9W-zk3ayYq373LF4=.8fba7762-07b2-45b8-a002-1ad2c0c05b0e@github.com>
Message-ID: <PrPzf4KFAxqGUNc3KrJWK65Z5vHqPpWc_9oghQ11FDs=.65405dbc-ec00-484b-86f8-5bd2b9ec44f7@github.com>

On Tue, 25 Apr 2023 21:37:11 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> ObjectValue is not just a candidate. I.e., the ObjectValue is also used independently of the merge.

And now I'm wondering how it all plays with `is_only_merge_candidate()()`/`set_merge_candidate()`... 

Is it possible for an `ObjectValue` to be shared between multiple merges?

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

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


From mullan at openjdk.org  Wed Apr 26 18:06:55 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Apr 2023 18:06:55 GMT
Subject: RFR: 8297878: KEM: Implementation [v9]
In-Reply-To: <NPgYS8mla8CiXJ3xbR5dMO3yqw32HOCyH6AvrOORNBM=.573e1e91-0ade-46c5-a570-b62dd1fbe6b9@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <NPgYS8mla8CiXJ3xbR5dMO3yqw32HOCyH6AvrOORNBM=.573e1e91-0ade-46c5-a570-b62dd1fbe6b9@github.com>
Message-ID: <d_t4q79D9AcLjVCu4jUhGEwr14hxY3Swo_nP_bfjZzE=.2c32dac9-f277-4031-89a6-968b1a6f3725@github.com>

On Wed, 26 Apr 2023 14:29:25 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:
> 
>   small spec change

src/java.base/share/classes/javax/crypto/KEMSpi.java line 111:

> 109:          * The key encapsulation function.
> 110:          * <p>
> 111:          * Each invocation of this method must generates a new secret key and key

s/generates/generate/

src/java.base/share/classes/javax/crypto/KEMSpi.java line 115:

> 113:          * <p>
> 114:          * An implementation must support the case where {@code from} is 0,
> 115:          * {@code from} is the same as the output of {@code secretSize()},

Should "from" be "to"?

Maybe also say "return value" instead of "output".

src/java.base/share/classes/javax/crypto/KEMSpi.java line 125:

> 123:          * @return an {@link KEM.Encapsulated} object containing a portion of
> 124:          *          the shared secret as a key with the specified algorithm,
> 125:          *          the key encapsulation message, and optional parameters.

Remove "the".

src/java.base/share/classes/javax/crypto/KEMSpi.java line 127:

> 125:          *          the key encapsulation message, and optional parameters.
> 126:          * @throws ArrayIndexOutOfBoundsException if {@code from < 0},
> 127:          *     {@code from > to}, or {@code to > secretSize()}

Should this throw an `IndexOutOfBoundsException` instead here? That's what the DHKEM impl does and this seems more reasonable since you aren't actually trying to access an array.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 168:

> 166:          * <p>
> 167:          * An implementation must support the case where {@code from} is 0,
> 168:          * {@code from} is the same as the output of {@code secretSize()},

Same comment as above.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 184:

> 182:          * @throws DecapsulateException if an error occurs during the
> 183:          *          decapsulation process
> 184:          * @throws ArrayIndexOutOfBoundsException if {@code from < 0},

Same comment as above.

src/java.base/share/classes/javax/crypto/KEMSpi.java line 242:

> 240:      * @see KEM#newDecapsulator(PrivateKey, AlgorithmParameterSpec)
> 241:      */
> 242:     DecapsulatorSpi engineNewDecapsulator(PrivateKey sk, AlgorithmParameterSpec spec)

Bit of a nit, but suggest changing variable names to be more descriptive: `privKey` (or `privateKey`) and `pubKey` (or `publicKey`), for the `engineEncapsulate` method. I assume `sk` is taken from RFC 9180, but I don't think we need to use the same variable names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178210665
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178212708
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178214239
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178219972
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178221846
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178220363
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178207872


From weijun at openjdk.org  Wed Apr 26 18:41:05 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 18:41:05 GMT
Subject: RFR: 8297878: KEM: Implementation [v9]
In-Reply-To: <d_t4q79D9AcLjVCu4jUhGEwr14hxY3Swo_nP_bfjZzE=.2c32dac9-f277-4031-89a6-968b1a6f3725@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <NPgYS8mla8CiXJ3xbR5dMO3yqw32HOCyH6AvrOORNBM=.573e1e91-0ade-46c5-a570-b62dd1fbe6b9@github.com>
 <d_t4q79D9AcLjVCu4jUhGEwr14hxY3Swo_nP_bfjZzE=.2c32dac9-f277-4031-89a6-968b1a6f3725@github.com>
Message-ID: <3h-h0KXw09oF__8Z3jXxaRoEEK2rxylXXNsF1n5l664=.774612ea-eb91-4147-9662-bde2d74a4f99@github.com>

On Wed, 26 Apr 2023 17:56:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small spec change
>
> src/java.base/share/classes/javax/crypto/KEMSpi.java line 127:
> 
>> 125:          *          the key encapsulation message, and optional parameters.
>> 126:          * @throws ArrayIndexOutOfBoundsException if {@code from < 0},
>> 127:          *     {@code from > to}, or {@code to > secretSize()}
> 
> Should this throw an `IndexOutOfBoundsException` instead here? That's what the DHKEM impl does and this seems more reasonable since you aren't actually trying to access an array.

Yes, you're right. I actually didn't realize the difference between IOOBE and AIOOBE at all. In fact, I checked for IOOBE in the `Compliance.java` test.

> src/java.base/share/classes/javax/crypto/KEMSpi.java line 168:
> 
>> 166:          * <p>
>> 167:          * An implementation must support the case where {@code from} is 0,
>> 168:          * {@code from} is the same as the output of {@code secretSize()},
> 
> Same comment as above.

Will fix.

> src/java.base/share/classes/javax/crypto/KEMSpi.java line 184:
> 
>> 182:          * @throws DecapsulateException if an error occurs during the
>> 183:          *          decapsulation process
>> 184:          * @throws ArrayIndexOutOfBoundsException if {@code from < 0},
> 
> Same comment as above.

Will fix.

> src/java.base/share/classes/javax/crypto/KEMSpi.java line 242:
> 
>> 240:      * @see KEM#newDecapsulator(PrivateKey, AlgorithmParameterSpec)
>> 241:      */
>> 242:     DecapsulatorSpi engineNewDecapsulator(PrivateKey sk, AlgorithmParameterSpec spec)
> 
> Bit of a nit, but suggest changing variable names to be more descriptive: `privKey` (or `privateKey`) and `pubKey` (or `publicKey`), for the `engineEncapsulate` method. I assume `sk` is taken from RFC 9180, but I don't think we need to use the same variable names.

OK, I'll change them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178254497
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178256035
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178255927
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1178247018


From weijun at openjdk.org  Wed Apr 26 18:41:24 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 18:41:24 GMT
Subject: RFR: 8297878: KEM: Implementation [v9]
In-Reply-To: <PgUxbczfU2R0659vHP9XWsP4i3didmKYn52VTSqUpjU=.06fd4ccf-a5cc-4774-be3b-7052821b2655@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <8bHDa13a4vgSx2M3EBpjxnMZEIvXRlmDeDEETErwUM8=.0d9c7013-dfc0-4342-b5d2-52b07ef33dde@github.com>
 <PgUxbczfU2R0659vHP9XWsP4i3didmKYn52VTSqUpjU=.06fd4ccf-a5cc-4774-be3b-7052821b2655@github.com>
Message-ID: <ktbfQdEJn2KehzLsKsIw12aSERYaAgi0ImagLXWwmXk=.e4f9ea7c-b4a7-4606-950d-e0495ecdc090@github.com>

On Wed, 26 Apr 2023 17:34:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEMSpi.java line 236:
>> 
>>> 234:      *
>>> 235:      * @param sk the receiver's private key. This argument is never {@code null}.
>>> 236:      * @param spec the parameter, can be {@code null}
>> 
>> "the optional parameter, ..." (use same wording as engineNewEncapsulator).
>
> Don't see that this is fixed yet.

Oops. Will fix now.

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

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


From cslucas at openjdk.org  Wed Apr 26 18:52:00 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 26 Apr 2023 18:52:00 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <PrPzf4KFAxqGUNc3KrJWK65Z5vHqPpWc_9oghQ11FDs=.65405dbc-ec00-484b-86f8-5bd2b9ec44f7@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>
 <aNMOXsTlucgR8Plv8JLhzixCxqovWrV3jz29tRH7c78=.b9f0b781-b7c3-457e-b125-c521a9ad5a6e@github.com>
 <8OlLs3nmBxAKP_OcaZPhC3g1lNpfXJQ6zYCx2XNB43A=.055edcf3-96b7-4f97-9153-fdfe26bb0c0b@github.com>
 <5HmQ644vtSgf7NylFeEsQXfU8DC9W-zk3ayYq373LF4=.8fba7762-07b2-45b8-a002-1ad2c0c05b0e@github.com>
 <PrPzf4KFAxqGUNc3KrJWK65Z5vHqPpWc_9oghQ11FDs=.65405dbc-ec00-484b-86f8-5bd2b9ec44f7@github.com>
Message-ID: <06yEWgFGq-XvgFp61UllqFWWpkYSY9fMqQRmkaNwi7Y=.2316f990-2ba1-4fa0-848e-b7e84fc744f7@github.com>

On Wed, 26 Apr 2023 17:42:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Is it possible for an ObjectValue to be shared between multiple merges?

When I posted my previous comment I thought that could happen. But now I realize that in the current implementation that won't happen: an ObjectValue is created for a combination of Phi x SafePointNode.

However, one situation would _require_ sharing the ObjectValue in multiple merges: when different merges share at least one SR input are used as debug info _in the same_ SafePointNode. It's required because in the same SafePointNode all ObjectValues coming from same Allocate needs to have the same value. I think the example below will trigger that - I'll check and patch the current implementation to not RAM in that case.


Point p = new Point();
Point q = new Point();
Point r = new Point();
if (cond_one) p = q;
if (cond_two) r = q;
trap(p, q, r);

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

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


From weijun at openjdk.org  Wed Apr 26 19:02:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 19:02:53 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@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:

  no more pk/sk, AIOOBE to IOOBE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/c33ef612..7ada6f0b

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

  Stats: 59 lines in 2 files changed: 3 ins; 0 del; 56 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 Apr 26 19:25:24 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 19:25:24 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
Message-ID: <q8osAJnGhjSwnV4mTbLeLy3rAwJdG_0mDtcZcW5dOFQ=.dcbe1beb-6f0c-442b-b0f1-6906ca796eaf@github.com>

On Wed, 26 Apr 2023 19:02: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:
> 
>   no more pk/sk, AIOOBE to IOOBE

CSR also updated.

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

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


From sean.mullan at oracle.com  Wed Apr 26 19:40:27 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 26 Apr 2023 15:40:27 -0400
Subject: X509Factory cache control
In-Reply-To: <CA+pBWhsq6JOxoi7wGNRNO+2KS_N16BObWV_tnmA5MDvWFzrAjg@mail.gmail.com>
References: <CA+pBWhsq6JOxoi7wGNRNO+2KS_N16BObWV_tnmA5MDvWFzrAjg@mail.gmail.com>
Message-ID: <dfa16c3f-0a5e-a8df-40ab-85a827e671ab@oracle.com>

Hi Eirik,

Thanks for thinking about this issue. First, I agree that some changes 
are probably useful, but we probably need to discuss this more, and 
maybe try to address the more pressing issues first. Some of my thoughts:

- I don't think the cache should be removed. I think it can improve 
performance (especially for certs), and is not an unreasonable thing for 
the JDK to try to help with.

- I do think there should be a *supported* way to turn each of the 
caches off individually. If an application has their own caching 
mechanism, then they should be able to use it instead of the JDKs.

- We have evidence from at least 2 customers that the CRL cache is the 
more problematic issue. I don't remember the history, but I think the 
"750" size may have been chosen arbitrarily to match the certificate 
cache. As a short-term fix, I would probably be ok with lowering this 
default value to something more reasonable, but I am not sure what that 
should be offhand.

- I think knobs to control the cache properties sound like they would be 
useful, but I also think many users would not know what to use as 
reasonable values, and may end up just turning off the cache and seeing 
if that helps.

- I'm a little surprised the SoftReferences still caused so many entries 
to be retained. A comment (which may be out of date) in 
sun.security.util.Cache.java says that they may be purged too eagerly, 
which would seem to have helped the issues that the customers reported. 
Some testing may be in order to see what the current behavior is with 
different VM settings.

--Sean

On 4/24/23 2:32 AM, Eirik Bj?rsn?s wrote:
> Hi,
> 
> When reaching out to the BouncyCastle community regarding the deprecated 
> javax.security.cert APIs, I got some interesting feedback from Matti 
> Aarnio of?Methics Ltd:
> 
>     Long ago we did encounter problems with JRE's X509CertImpl.java
>      ?class, and more so with X509CRLImpl.java. Both have internal
>     caches of binary form input that is then converted to parsed forms.
> 
>     Especially the CRL cache did not (still does not?) have nice "that
>     version is obsoleted, drop it to garbage collection" handling of
>     parsed CRLs, while it had way too large cache size.
>     A server running for months and getting a new CRL every 12 hours
>     eventually grew the memory footprint of obsolete parsed data up to
>     ridiculous amounts of gigabytes of heap footprint.
> 
>     Once we realized that also certificate parser had such a cache and
>     that there is no official way to control that cache, we became very
>     much averse of using those APIs. 
> 
> It seems the lack of cache control of these static implementation caches 
> can be problematic, especially in the CRL case. The default for both 
> caches is a max number of entries of 750 with an unlimited lifetime. The 
> inability of expiring outdated CRLs seems?particularly problematic 
> for?Matti.
> 
> A similar issue was reported in JDK-8059007 back in 2014, with the 
> following comment from Sean:
> 
>     We need to introduce some system properties (or something similar)
>     to allow the crl/cert caches to be adjusted. Changing to RFE.
> 
> 
> While it would certainly be nice to add some form of cache control, the 
> solution space is large:
> 
> -1: Remove the cache. One could claim that the parser/factory level is 
> the wrong level to introduce parsing. There are so many ways to tune 
> parsing, there exists many excellent libraries. If apps need caching, 
> they should take care of it at the app level.
> 
> 0: Do nothing, there haven't been that many complaints
> 
> 1: Add an option to entirely disable the cache such that apps can do 
> their own caching (or not) without wasting space in the default cache.
> 
> 2: Add two system properties to control max entries of the cert and crl 
> cache. Setting these to 0 would disable the cache.
> 
> 3: Add four system properties to control?max entries and max lifetime 
> for each of the cert and crl caches. Setting max entries to 0 would 
> disable a cache.
> 
> 4: Tune the default max entries and lifetime to make everyone happy.
> 
> 5: Add a pluggable API to control caching. Think 
> AbstractCacheControllingMaxEntrySizeProxyFactoryContext :-)
> 
> 6: Something I did not consider.
> 
> -1 is probably not desired/possible because of the behavioural change. 1 
> is simple but very constrained. 2 and 3 are similar in shape where 3 
> allows more flexibility introducing lifetime. 4 seems like wishful 
> thinking. You could probably guess I'm not a big fan of 5.?6 seems 
> promising :-)
> 
> I have a sketch implementation of 3 available, but it would be great to 
> gather some opinions before I put more work into this:
> 
> https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:x509factory-cache-config <https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:x509factory-cache-config>
> 
> Thanks,
> Eirik.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8059007 
> <https://bugs.openjdk.org/browse/JDK-8059007>
> 
> 
> 


From mullan at openjdk.org  Wed Apr 26 20:33:27 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Apr 2023 20:33:27 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
Message-ID: <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>

On Wed, 26 Apr 2023 19:02: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:
> 
>   no more pk/sk, AIOOBE to IOOBE

src/java.base/share/classes/javax/crypto/KEM.java line 606:

> 604:      * @param publicKey the receiver's public key, must not be {@code null}
> 605:      * @return the encapsulator for this key
> 606:      * @throws InvalidKeyException if {@code publicKey} is invalid

What about throwing `NullPointerException` if `publicKey` is `null`? In this case a `RuntimeException` seems more appropriate, and throwing NPE seems more consistent with how you treat `null` parameters of other methods.

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

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


From weijun at openjdk.org  Wed Apr 26 20:55:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 20:55:57 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>
Message-ID: <LQBSuX2uXCLWNg-BMqU5WboHdiipsQlU_0cdU6dLe2A=.9603ed6b-bbb1-4628-849c-e4cb929e7ae7@github.com>

On Wed, 26 Apr 2023 20:21:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   no more pk/sk, AIOOBE to IOOBE
>
> src/java.base/share/classes/javax/crypto/KEM.java line 606:
> 
>> 604:      * @param publicKey the receiver's public key, must not be {@code null}
>> 605:      * @return the encapsulator for this key
>> 606:      * @throws InvalidKeyException if {@code publicKey} is invalid
> 
> What about throwing `NullPointerException` if `publicKey` is `null`? In this case a `RuntimeException` seems more appropriate, and throwing NPE seems more consistent with how you treat `null` parameters of other methods.

Every other crypto engine class throws IKE when initing with a null key, including `Signature`, `Cipher`, `KeyAgreement`, 'Mac`. So I follow the same style.

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

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


From mullan at openjdk.org  Wed Apr 26 21:06:53 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Apr 2023 21:06:53 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <LQBSuX2uXCLWNg-BMqU5WboHdiipsQlU_0cdU6dLe2A=.9603ed6b-bbb1-4628-849c-e4cb929e7ae7@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>
 <LQBSuX2uXCLWNg-BMqU5WboHdiipsQlU_0cdU6dLe2A=.9603ed6b-bbb1-4628-849c-e4cb929e7ae7@github.com>
Message-ID: <IXatqI-Q88cMv6UH-NzhFlMwC4SaV_lUpDfiYwtWpN8=.31bbaf60-3166-4211-82a6-e87f4de22611@github.com>

On Wed, 26 Apr 2023 20:36:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KEM.java line 606:
>> 
>>> 604:      * @param publicKey the receiver's public key, must not be {@code null}
>>> 605:      * @return the encapsulator for this key
>>> 606:      * @throws InvalidKeyException if {@code publicKey} is invalid
>> 
>> What about throwing `NullPointerException` if `publicKey` is `null`? In this case a `RuntimeException` seems more appropriate, and throwing NPE seems more consistent with how you treat `null` parameters of other methods.
>
> Every other crypto engine class throws IKE when initing with a null key, including `Signature`, `Cipher`, `KeyAgreement`, 'Mac`. So I follow the same style.

Hmm, while I understand your thinking, this seems like the wrong pattern to follow though (ex: see Effective Java, Item 70), and it doesn't seem like something we should have to adhere to for API consistency. There are various bugs filed over the years on confusion over this style (search for "Cipher init NullPointerException"), where providers threw NPE or users thought the APIs should. Actually, there is still an open bug: https://bugs.openjdk.org/browse/JDK-4955097

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

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


From weijun at openjdk.org  Wed Apr 26 21:51:02 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Apr 2023 21:51:02 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <IXatqI-Q88cMv6UH-NzhFlMwC4SaV_lUpDfiYwtWpN8=.31bbaf60-3166-4211-82a6-e87f4de22611@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>
 <LQBSuX2uXCLWNg-BMqU5WboHdiipsQlU_0cdU6dLe2A=.9603ed6b-bbb1-4628-849c-e4cb929e7ae7@github.com>
 <IXatqI-Q88cMv6UH-NzhFlMwC4SaV_lUpDfiYwtWpN8=.31bbaf60-3166-4211-82a6-e87f4de22611@github.com>
Message-ID: <Jt1GY0YnQmo3bt2oE2e4kF-PkswNDbj9oADRi5qEoKc=.2e4b9947-5e2f-4a64-ba84-09aa406181ee@github.com>

On Wed, 26 Apr 2023 20:56:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Every other crypto engine class throws IKE when initing with a null key, including `Signature`, `Cipher`, `KeyAgreement`, `Mac`. So I follow the same style.
>
> Hmm, while I understand your thinking, this seems like the wrong pattern to follow though (ex: see Effective Java, Item 70), and it doesn't seem like something we should have to adhere to for API consistency. There are various bugs filed over the years on confusion over this style (search for "Cipher init NullPointerException"), where providers threw NPE or users thought the APIs should. Actually, there is still an open bug: https://bugs.openjdk.org/browse/JDK-4955097

I checked for our implementations, and until now all I found is IKE. Even the PBEWithMD5AndDES algorithm mentioned in https://bugs.openjdk.org/browse/JDK-4953551 also throws an IKE.

I'd rather follow the existing style. If it?s not clear enough, I can update the line to

@throws InvalidKeyException if {@code publicKey} is {@code null} or invalid


If we are worried that a security provider might throw an NPE, how about we add a check on the user API side:

    public Encapsulator newEncapsulator(PublicKey publicKey,
            AlgorithmParameterSpec spec, SecureRandom secureRandom)
            throws InvalidAlgorithmParameterException, InvalidKeyException {
        if (publicKey == null) {
            throw new InvalidKeyException("Null key provided");
        }
        return delayed != null
                ? delayed.newEncapsulator(publicKey, spec, secureRandom)
                : new Encapsulator(spi.engineNewEncapsulator(publicKey, spec, secureRandom), provider);
    }

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

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


From jiangli at openjdk.org  Thu Apr 27 00:30:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Apr 2023 00:30:27 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition issues
 when statically linking JDK/VM natives with standard launcher
Message-ID: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>

Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):

- Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
- Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
- Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
- Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

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

Commit messages:
 - Update copyright headers.
 - 8306949: Resolve miscellaneous multiple symbol definition issues when statically linking JDK/VM natives with standard launcher

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

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


From serb at openjdk.org  Thu Apr 27 07:37:22 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Apr 2023 07:37:22 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <guPNDUfPDIzsTKAgeu5xml7U33e85wsKiOwQxYJ1DLc=.019b0582-5698-471e-a162-195b676ce42d@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

The changes for jvm_xawt looks fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/13682#issuecomment-1524973461


From weijun at openjdk.org  Thu Apr 27 13:11:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 13:11:55 GMT
Subject: RFR: 8297878: KEM: Implementation [v11]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <v375Vt6QV-MvINO1FzlX5CbAL5OKa6Kix7TNIKPzIas=.85f3f5f6-05a1-4bc8-9cd2-47b586927b8c@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 11 additional commits since the last revision:

 - Merge branch 'master' into 8297878
 - no more pk/sk, AIOOBE to IOOBE
 - small spec change
 - some constants, no local reverse
 - fine tuning spec
 - move Encapsulator before Decapsulator
 - fine tune spec
 - let implementor validate arguments, null key throws IKE
 - spec changes
 - spec change, getAlgorithm
 - ... and 1 more: https://git.openjdk.org/jdk/compare/13457d46...8ba16065

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/7ada6f0b..8ba16065

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

  Stats: 311246 lines in 3091 files changed: 261349 ins; 31771 del; 18126 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 Apr 27 13:28:57 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Apr 2023 13:28:57 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
Message-ID: <dWIvfh1RJ8ATqSzMiGI5-jBeIybhcvZSWyYHn7N_XY4=.782532ef-28fa-44e8-862d-72f6afca08a5@github.com>

On Wed, 26 Apr 2023 19:02: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:
> 
>   no more pk/sk, AIOOBE to IOOBE

src/java.base/share/classes/javax/crypto/KEM.java line 90:

> 88: 
> 89:     /**
> 90:      * This class specifies the returned value of the encapsulate method of

s/returned/return/

src/java.base/share/classes/javax/crypto/KEM.java line 100:

> 98:      * @see Encapsulator#encapsulate(int, int, String)
> 99:      */
> 100:     public static final class Encapsulated {

Missing `@since 21`.

src/java.base/share/classes/javax/crypto/KEM.java line 148:

> 146:          * Returns the optional parameters in a byte array.
> 147:          *
> 148:          * @return the optional parameters in a byte array. A new copy of the

Should probably say "the optional parameters in a byte array or `null` if not specified`.

src/java.base/share/classes/javax/crypto/KEM.java line 239:

> 237:          * Returns the size of the shared secret.
> 238:          * <p>
> 239:          * This method can be called to find out the length of the share secret

s/share/shared/

src/java.base/share/classes/javax/crypto/KEM.java line 362:

> 360:          * Returns the size of the shared secret.
> 361:          * <p>
> 362:          * This method can be called to find out the length of the share secret

s/share/shared/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179113396
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179115920
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179119002
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179122638
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179127665


From mullan at openjdk.org  Thu Apr 27 13:28:57 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Apr 2023 13:28:57 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <Jt1GY0YnQmo3bt2oE2e4kF-PkswNDbj9oADRi5qEoKc=.2e4b9947-5e2f-4a64-ba84-09aa406181ee@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>
 <LQBSuX2uXCLWNg-BMqU5WboHdiipsQlU_0cdU6dLe2A=.9603ed6b-bbb1-4628-849c-e4cb929e7ae7@github.com>
 <IXatqI-Q88cMv6UH-NzhFlMwC4SaV_lUpDfiYwtWpN8=.31bbaf60-3166-4211-82a6-e87f4de22611@github.com>
 <Jt1GY0YnQmo3bt2oE2e4kF-PkswNDbj9oADRi5qEoKc=.2e4b9947-5e2f-4a64-ba84-09aa406181ee@github.com>
Message-ID: <Pn1Bs0imrX6syuZ8yDPT8wiNJRXqv6S_x64bo9gK7KY=.b32baaa7-4723-45ad-b98f-e0efa24303c6@github.com>

On Wed, 26 Apr 2023 21:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I checked for our implementations, and until now all I found is IKE. Even the PBEWithMD5AndDES algorithm mentioned in https://bugs.openjdk.org/browse/JDK-4953551 also throws an IKE.
> 
> I'd rather follow the existing style. If it?s not clear enough, I can update the line to
> 
> ```
> @throws InvalidKeyException if {@code publicKey} is {@code null} or invalid
> ```

I'll leave it up to you, or consensus from others. This one particular issue is probably not going to overly affect the API much.

The APIs you referenced were created a long time ago before more accepted API best practices evolved. Also, this API already throws NPE in other methods when a required parameter is `null`, so these methods seem inconsistent with the way it treats `null` parameters.

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

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


From alanb at openjdk.org  Thu Apr 27 14:00:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Apr 2023 14:00:25 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <lTnWw8tIWfWu-mvLSGjO0a33PBWreWquVzSuaVN10pA=.2c17937d-2044-4463-933d-c994951b2665@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

Marked as reviewed by alanb (Reviewer).

Looks okay.

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

PR Review: https://git.openjdk.org/jdk/pull/13682#pullrequestreview-1404102039
Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13682#pullrequestreview-1404103532


From weijun at openjdk.org  Thu Apr 27 14:49:24 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 14:49:24 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <dWIvfh1RJ8ATqSzMiGI5-jBeIybhcvZSWyYHn7N_XY4=.782532ef-28fa-44e8-862d-72f6afca08a5@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <dWIvfh1RJ8ATqSzMiGI5-jBeIybhcvZSWyYHn7N_XY4=.782532ef-28fa-44e8-862d-72f6afca08a5@github.com>
Message-ID: <R-Fi8qFZOQhe8odp3XWs9LzcUd__Vk47WFnDpn5jQ3w=.2c8b281e-f995-4635-b8f8-81bd4b82ab6d@github.com>

On Thu, 27 Apr 2023 12:54:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   no more pk/sk, AIOOBE to IOOBE
>
> src/java.base/share/classes/javax/crypto/KEM.java line 90:
> 
>> 88: 
>> 89:     /**
>> 90:      * This class specifies the returned value of the encapsulate method of
> 
> s/returned/return/

OK.

> src/java.base/share/classes/javax/crypto/KEM.java line 100:
> 
>> 98:      * @see Encapsulator#encapsulate(int, int, String)
>> 99:      */
>> 100:     public static final class Encapsulated {
> 
> Missing `@since 21`.

I thought there is no need to add this to an inner class. I'll ask Joe for advice.

> src/java.base/share/classes/javax/crypto/KEM.java line 148:
> 
>> 146:          * Returns the optional parameters in a byte array.
>> 147:          *
>> 148:          * @return the optional parameters in a byte array. A new copy of the
> 
> Should probably say "the optional parameters in a byte array or `null` if not specified`.

OK.

> src/java.base/share/classes/javax/crypto/KEM.java line 239:
> 
>> 237:          * Returns the size of the shared secret.
>> 238:          * <p>
>> 239:          * This method can be called to find out the length of the share secret
> 
> s/share/shared/

Oops.

> src/java.base/share/classes/javax/crypto/KEM.java line 362:
> 
>> 360:          * Returns the size of the shared secret.
>> 361:          * <p>
>> 362:          * This method can be called to find out the length of the share secret
> 
> s/share/shared/

Oops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179263143
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179262971
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179262197
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179261989
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1179261856


From jiangli at openjdk.org  Thu Apr 27 15:08:54 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Apr 2023 15:08:54 GMT
Subject: RFR: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <HIkIovQEj3ZKo4QAeaWGAorjbh_bWL6mJJkYPrFvZUc=.d8dc4b68-730d-4fb9-8309-4250c7d2ea04@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13682#issuecomment-1525845560


From weijun at openjdk.org  Thu Apr 27 15:40:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 15:40:53 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@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:

  more @since and about nulls

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

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

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

  Stats: 22 lines in 2 files changed: 10 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 Apr 27 15:41:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 15:41:23 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: <pzke1q-6hR6Vf5w98fpP-HXgQEVY9nZtDrCr-KkPhQc=.3793f252-3d6c-4ab4-bff1-2fb705147bb7@github.com>

On Thu, 27 Apr 2023 15:22:17 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

I didn't realize `@` in a commit message can still be linked to a user.

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

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


From weijun at openjdk.org  Thu Apr 27 15:42:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 15:42:23 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <R-Fi8qFZOQhe8odp3XWs9LzcUd__Vk47WFnDpn5jQ3w=.2c8b281e-f995-4635-b8f8-81bd4b82ab6d@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <dWIvfh1RJ8ATqSzMiGI5-jBeIybhcvZSWyYHn7N_XY4=.782532ef-28fa-44e8-862d-72f6afca08a5@github.com>
 <R-Fi8qFZOQhe8odp3XWs9LzcUd__Vk47WFnDpn5jQ3w=.2c8b281e-f995-4635-b8f8-81bd4b82ab6d@github.com>
Message-ID: <IhOHuoxXsZeEufnKsZ_M6K9ZcBavjOK6hdGIcWlGSwQ=.59eb208d-4be5-4653-9e1c-f3c72a98dd58@github.com>

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

>> src/java.base/share/classes/javax/crypto/KEM.java line 100:
>> 
>>> 98:      * @see Encapsulator#encapsulate(int, int, String)
>>> 99:      */
>>> 100:     public static final class Encapsulated {
>> 
>> Missing `@since 21`.
>
> I thought there is no need to add this to an inner class. I'll ask Joe for advice.

I've added `@since` to all inner classes.

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

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


From jiangli at openjdk.org  Thu Apr 27 16:11:55 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Apr 2023 16:11:55 GMT
Subject: Integrated: 8306949: Resolve miscellaneous multiple symbol definition
 issues when statically linking JDK/VM natives with standard launcher
In-Reply-To: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
References: <HzkHF3rMSsB0OreQ4QCSiuMlIo7zl7aUHB5WqOMTZ90=.3e0e3871-a397-42b3-a214-0d40c014fd2a@github.com>
Message-ID: <AWDpUaSa56ZgYKpo9xdTGylOcHJw6dNdyIW1evrJ7Cs=.25bb6d74-6709-45b7-8237-cf956c0b5060@github.com>

On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Resolve misc symbol issues observed when statically linking JDK/VM natives with the standard Java launcher executable. Use the same approaches adopted by earlier fixes for static linking related symbol problems (e.g. JDK-8306033):
> 
> - Change findFunction() to be a static function in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - Rename findFunction() to p11FindFunction() in libj2pkcs11 code.
> - Rename 'debug' to 'debug_j2pkcs11' in libj2pkcs11 code.
> - Rename 'jvm' to 'jvm_xawt' in libawt_xawt code.

This pull request has now been integrated.

Changeset: fed262a9
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fed262a9cf324ce7f2c61f4471c88bc84af8e3d0
Stats:     28 lines in 11 files changed: 0 ins; 1 del; 27 mod

8306949: Resolve miscellaneous multiple symbol definition issues when statically linking JDK/VM natives with standard launcher

Reviewed-by: alanb

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

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


From ascarpino at openjdk.org  Thu Apr 27 17:57:24 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Apr 2023 17:57:24 GMT
Subject: RFR: 8297878: KEM: Implementation [v7]
In-Reply-To: <95zju77TlKmy9QgfylZ375rsyB_Iu-VnlAEeDRuxPpQ=.75f8d38a-0112-4d11-a3b4-ceb6ea9a978b@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <cXBZSGv5-idHMUhLV-tK-HX-qI9x1s6CW5-jySyp198=.60bafe3d-1c33-4834-a764-e70614d60ae3@github.com>
 <GEoXKGpdrY9d31C3OfFkbcxXGbKPaHixh1x5yBbnhgo=.e849256d-d48f-4c1f-9153-545932f60485@github.com>
 <95zju77TlKmy9QgfylZ375rsyB_Iu-VnlAEeDRuxPpQ=.75f8d38a-0112-4d11-a3b4-ceb6ea9a978b@github.com>
Message-ID: <Kurx_ElAxVszEpJB_mb-X-u_Z5UxPRpjnD_0yhUWyaE=.9f812540-13e1-4b71-941b-f3fb684c0737@github.com>

On Mon, 24 Apr 2023 19:55:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 366:
>> 
>>> 364:     private static byte[] concat(byte[]... inputs) {
>>> 365:         ByteArrayOutputStream o = new ByteArrayOutputStream();
>>> 366:         Arrays.stream(inputs).forEach(o::writeBytes);
>> 
>> Unless I'm missing something there is no `stream(byte[])` support, so I'm not sure how this is compiling.  I didn't think  the generics would work with this.
>> More importantly, `forEach()` the API states that stream is in a non-deterministic order.  I think you want `forEachOrdered()`
>
> `inputs` is `byte[][]` and there is a `Arrays.stream(T[])`.
> 
> The above method says a `sequential Stream` is returned. Does that mean calling `forEach` is safe?

Ok, this is fine, I didn't realize sequential streams were default

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

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


From weijun at openjdk.org  Thu Apr 27 18:33:26 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 18:33:26 GMT
Subject: RFR: 8297878: KEM: Implementation [v10]
In-Reply-To: <Pn1Bs0imrX6syuZ8yDPT8wiNJRXqv6S_x64bo9gK7KY=.b32baaa7-4723-45ad-b98f-e0efa24303c6@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <rYWHDieSygIkJ1gTzHVL9D10ZPWP7aDxPYCcE7oQPnU=.1432bab7-d4ef-46d5-ac49-6c9239593463@github.com>
 <q2uZ9xOXNvXj5aytvxAAwcm3xHoDfBQCt7tZ2ghDvBk=.0a47f763-047e-4b61-a57d-1bff44f60851@github.com>
 <LQBSuX2uXCLWNg-BMqU5WboHdiipsQlU_0cdU6dLe2A=.9603ed6b-bbb1-4628-849c-e4cb929e7ae7@github.com>
 <IXatqI-Q88cMv6UH-NzhFlMwC4SaV_lUpDfiYwtWpN8=.31bbaf60-3166-4211-82a6-e87f4de22611@github.com>
 <Jt1GY0YnQmo3bt2oE2e4kF-PkswNDbj9oADRi5qEoKc=.2e4b9947-5e2f-4a64-ba84-09aa406181ee@github.com>
 <Pn1Bs0imrX6syuZ8yDPT8wiNJRXqv6S_x64bo9gK7KY=.b32baaa7-4723-45ad-b98f-e0efa24303c6@github.com>
Message-ID: <Ck29lbKQJ5dvNGrIsUrsB_MYTzRsHWjY2BBv4kwnYfg=.6c66a75d-96a3-4806-9bbb-c2e6afa758e5@github.com>

On Thu, 27 Apr 2023 13:22:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I checked for our implementations, and until now all I found is IKE. Even the PBEWithMD5AndDES algorithm mentioned in https://bugs.openjdk.org/browse/JDK-4953551 also throws an IKE.
>> 
>> I'd rather follow the existing style. If it?s not clear enough, I can update the line to
>> 
>> @throws InvalidKeyException if {@code publicKey} is {@code null} or invalid
>> 
>> 
>> If we are worried that a security provider might throw an NPE, how about we add a check on the user API side:
>> 
>>     public Encapsulator newEncapsulator(PublicKey publicKey,
>>             AlgorithmParameterSpec spec, SecureRandom secureRandom)
>>             throws InvalidAlgorithmParameterException, InvalidKeyException {
>>         if (publicKey == null) {
>>             throw new InvalidKeyException("Null key provided");
>>         }
>>         return delayed != null
>>                 ? delayed.newEncapsulator(publicKey, spec, secureRandom)
>>                 : new Encapsulator(spi.engineNewEncapsulator(publicKey, spec, secureRandom), provider);
>>     }
>
>> I checked for our implementations, and until now all I found is IKE. Even the PBEWithMD5AndDES algorithm mentioned in https://bugs.openjdk.org/browse/JDK-4953551 also throws an IKE.
>> 
>> I'd rather follow the existing style. If it?s not clear enough, I can update the line to
>> 
>> ```
>> @throws InvalidKeyException if {@code publicKey} is {@code null} or invalid
>> ```
> 
> I'll leave it up to you, or consensus from others. This one particular issue is probably not going to overly affect the API much.
> 
> The APIs you referenced were created a long time ago before more accepted API best practices evolved. Also, this API already throws NPE in other methods when a required parameter is `null`, so these methods seem inconsistent with the way it treats `null` parameters.

The new `KEM` class still follows the API/SPI design principal. I gave up designing `DecapsulteException` as an uncheck exception and I still use class instead of record for `Encapsulated`. So let's consistently traditional.

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

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


From rhalade at openjdk.org  Thu Apr 27 18:56:58 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 27 Apr 2023 18:56:58 GMT
Subject: RFR: 8305975: Add TWCA Global Root CA
Message-ID: <BSp38OXZ4OkmXZR46CKmHhpD30wnJpGM06Kt5oKJmb8=.59326fab-aa7b-48f0-b591-ae83b6b27533@github.com>

This PR is to add new root certificate from TWCA root. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.

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

Commit messages:
 - 8305975: Add TWCA Global Root CA
 - Merge branch 'master' into twca-certify
 - Merge branch 'master' into twca-certify
 - Add TWCA root CA

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

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


From weijun at openjdk.org  Thu Apr 27 19:21:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 19:21:23 GMT
Subject: RFR: 8307077: Convert CRLF to LF in java.xml.crypto
Message-ID: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>

Convert CRLF to LF in these files so it's consistent with other source files.

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

Commit messages:
 - the fix

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

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


From weijun.wang at oracle.com  Thu Apr 27 20:39:30 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Thu, 27 Apr 2023 20:39:30 +0000
Subject: JEP draft: Leighton-Micali Hash-Based Signatures
In-Reply-To: <382D5BA4-4E07-4D78-9D65-0903829A35F8@oracle.com>
References: <382D5BA4-4E07-4D78-9D65-0903829A35F8@oracle.com>
Message-ID: <844D945D-226E-46D5-A448-FE61148F42E4@oracle.com>

Hi All,

We haven't gotten enough feedback on the proposed new APIs and decide to drop this JEP from JDK 21. It's still open and we can reconsider it in a future release.

We are still planning on an implementation on signature verification targeting JDK 21. You can read the CSR at https://bugs.openjdk.org/browse/JDK-8305973.

Thanks,
Max

> On Mar 20, 2023, at 5:51 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi All,
> 
> We propose to add support for HSS/LMS as a Signature algorithm to JCA/JCE.
> 
> All currently widely used digital signature schemes, including DSA, RSA, ECDSA, and EdDSA, have the potential to be broken if large scale quantum computers are ever built. However, the security of HSS/LMS depends only on the security of the underlying hash functions, and it is believed that the security of hash functions will not be broken by the development of large-scale quantum computers.
> 
> We have drafted a JEP for adding this support (see link below). We propose to add a new standard name and some new APIs. We will also provide an implementation of signature verification which would be integrated into an existing JDK security provider.
> 
> We don?t plan to provide implementations of key pair generation and signature generation out-of-box as they should be implemented in hardware. However, we believe third party vendors will be interested in implementing them (in a ?hardware cryptographic module?) and exposing the functions through a Java security provider. Thus we are proposing an HSSGenParameterSpec class to initialize the KeyPairGenerator for HSS/LMS. We also are proposing to define new interfaces named HSSLMSPrivateKey and HSSLMSPublicKey where you can read parameters from the keys. There is a keysRemaining() method where you can find out how many LM-OTS keys are left.
> 
> You can read the draft JEP at https://openjdk.org/jeps/8303541.
> 
> Feel free to add any comment here.
> 
> Thanks,
> Max
> 


From cslucas at openjdk.org  Thu Apr 27 20:52:23 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 27 Apr 2023 20:52:23 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <hIoa1Z7p8xL1ZsJtyPm6795tNohDHS1RngYI3RcxXlk=.534b69a9-1d47-455c-a66f-72035e1c3e81@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>
Message-ID: <O0V74R5bmBdXS3Notd8gBpwIK60vyHrmA3h6KM-HyJg=.365896ca-6010-44b5-8bc4-3505e5f53c83@github.com>

On Sat, 22 Apr 2023 01:42:41 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 10 commits:
>> 
>>  - 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.
>>  - Merge master
>>  - Add support for rematerializing scalar replaced objects participating in allocation merges
>
> src/hotspot/share/code/debugInfo.hpp line 199:
> 
>> 197: // ObjectValue describing an object that was scalar replaced.
>> 198: 
>> 199: class ObjectMergeValue: public ObjectValue {
> 
> I find the decision to subclass`ObjectValue` confusing and error prone: now `is_object()` returns true for `ObjectMergeValue`, but you have to apply the selector first to turn it into `ObjectValue`. And now the order of checks matter, so you always have to perform `is_object_merge()` first and then follow it with `is_object()` guard.
> 
> You have 3 flavors of `ObjectValue` now:
> * good old `ObjectValue`;
> * `ObjectMergeValue`
> * merge candidates (`ObjectMergeCandidateValue`?)
> 
> Does it make sense to introduce 3 different subclasses under `ObjectValue` to clearly distinguish the scenarios?

Hi @iwanowww . I finished implementing a version of this like the illustration below (I didn't add a Candidate class). 


ScopeValue
    ObjectValue
        ObjectAllocationValue
            AutoBoxObjectValue
        ObjectMergeValue

 
Here are some observations:

- I don't think ObjectMergeValue should be under ObjectValue. The two classes only have two fields in common (_id and _visited). I think it should be a subclass of ScopeValue.
- ObjectCandidateValue would need to go under ObjectAllocationValue because it essentially _is_ an ObjectAllocationValue in most aspects.
- I didn't add a ObjectCandidateValue class because that class would need to go under ObjectAllocationValue and we would still need to do an "is_object_candidate" before all "is_object_allocation" and we would end up in much the situation that we want to avoid - needing to do is_object_merge before is_object.
- It seems the best place to flag an object as candidate is really in ObjectAllocationValue.

What do you think? As I said, I already have the code, if you want I can push it and you take a look.

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

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


From duke at openjdk.org  Thu Apr 27 23:06:25 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 27 Apr 2023 23:06:25 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification
Message-ID: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@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.

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

Commit messages:
 - LMS and HSS classes

Changes: https://git.openjdk.org/jdk/pull/13691/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298127
  Stats: 889 lines in 7 files changed: 886 ins; 0 del; 3 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 ascarpino at openjdk.org  Thu Apr 27 23:05:57 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Apr 2023 23:05:57 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: <JaV5AuzKVOpbHbzrwOn67x2d2AZNhX4b0QTBqoci3fc=.07a87ff9-8d1a-40bb-8c18-2e348113cb22@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

I feel the use of `from` and `to` is error prone.  I know I never remember if Arrays.copyOfRange() includes or excludes the `to` index.  I think less mistakes would be made if it used `index` and `length` instead.

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

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


From weijun at openjdk.org  Thu Apr 27 23:06:31 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Apr 2023 23:06:31 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification
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: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>

On Thu, 27 Apr 2023 14:16:34 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.

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

> 41: public class HSS extends SignatureSpi {
> 42:     private HSSPublicKey pubKey;
> 43:     private byte[] message;

How about using a `ByteArrayOutputStream` to store the message? Then we don't need to take care of memory management.

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

> 54: 
> 55:     protected void engineInitSign(PrivateKey publicKey) {
> 56:         throw new UnsupportedOperationException();

Sean suggested we change this to throw an `InvalidKeyException`. Otherwise, we might need to update the `Signature` spec on this.

Also, `s/publicKey/privateKey/`.

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`.

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.

src/java.base/share/classes/sun/security/provider/SunEntries.java line 190:

> 188: 
> 189:         add(p, "Signature", "HSS/LMS", "sun.security.provider.HSS");
> 190:         add(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl");

Use `addWithAlias` so we have OID has alias too. This is mentioned in the CSR. You can even add a test to ensure this.

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 651:

> 649: 
> 650:     public static final ObjectIdentifier hsslms_oid =
> 651:             ObjectIdentifier.of(KnownOIDs.HSSLMS);

You probably don't need to define this if it's not used anywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1179500780
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1179508433
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1179497232
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1179496323
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1179503653
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1179520002


From mpowers at openjdk.org  Thu Apr 27 23:14:56 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 27 Apr 2023 23:14:56 GMT
Subject: RFR: 8307077: Convert CRLF to LF in java.xml.crypto
In-Reply-To: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
References: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
Message-ID: <bhjiEU6t3IN-wQ9V2GnrLcOnmW_5GNM8APRcfyr57mg=.e10d6ef2-9748-494f-a104-294462865e9e@github.com>

On Thu, 27 Apr 2023 19:01:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Convert CRLF to LF in these files so it's consistent with other source files.

LGTM
I wrote a program to count CRLF in the four changed files in order to verify your fix.

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

PR Review: https://git.openjdk.org/jdk/pull/13700#pullrequestreview-1405025808


From vlivanov at openjdk.org  Thu Apr 27 23:50:55 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 27 Apr 2023 23:50:55 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <O0V74R5bmBdXS3Notd8gBpwIK60vyHrmA3h6KM-HyJg=.365896ca-6010-44b5-8bc4-3505e5f53c83@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>
Message-ID: <EoDfvRDKOpQGQTjwaPlPuISodyVu1pkKf6VUzbGtLlk=.7ea2b344-49d3-444a-b9a0-5f31e8d48ba2@github.com>

On Thu, 27 Apr 2023 20:33:38 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/code/debugInfo.hpp line 199:
>> 
>>> 197: // ObjectValue describing an object that was scalar replaced.
>>> 198: 
>>> 199: class ObjectMergeValue: public ObjectValue {
>> 
>> I find the decision to subclass`ObjectValue` confusing and error prone: now `is_object()` returns true for `ObjectMergeValue`, but you have to apply the selector first to turn it into `ObjectValue`. And now the order of checks matter, so you always have to perform `is_object_merge()` first and then follow it with `is_object()` guard.
>> 
>> You have 3 flavors of `ObjectValue` now:
>> * good old `ObjectValue`;
>> * `ObjectMergeValue`
>> * merge candidates (`ObjectMergeCandidateValue`?)
>> 
>> Does it make sense to introduce 3 different subclasses under `ObjectValue` to clearly distinguish the scenarios?
>
> Hi @iwanowww . I finished implementing a version of this like the illustration below (I didn't add a Candidate class). 
> 
> 
> ScopeValue
>     ObjectValue
>         ObjectAllocationValue
>             AutoBoxObjectValue
>         ObjectMergeValue
> 
>  
> Here are some observations:
> 
> - I don't think ObjectMergeValue should be under ObjectValue. The two classes only have two fields in common (_id and _visited). I think it should be a subclass of ScopeValue.
> - ObjectCandidateValue would need to go under ObjectAllocationValue because it essentially _is_ an ObjectAllocationValue in most aspects.
> - I didn't add a ObjectCandidateValue class because that class would need to go under ObjectAllocationValue and we would still need to do an "is_object_candidate" before all "is_object_allocation" and we would end up in much the situation that we want to avoid - needing to do is_object_merge before is_object.
> - It seems the best place to flag an object as candidate is really in ObjectAllocationValue.
> 
> What do you think? As I said, I already have the code, if you want I can push it and you take a look.

Can `ObjectCandidateValue` be a wrapper around a `ObjectAllocationValue`?

It does make sense to separate `ObjectMergeValue` and `ObjectValue`.

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

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


From vlivanov at openjdk.org  Thu Apr 27 23:50:56 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 27 Apr 2023 23:50:56 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <EoDfvRDKOpQGQTjwaPlPuISodyVu1pkKf6VUzbGtLlk=.7ea2b344-49d3-444a-b9a0-5f31e8d48ba2@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>
Message-ID: <LXuwj-aEpYq04Oyfa1Jt8D-slKC_xuQHapBO4xAeyv4=.d40c82a5-dda1-4370-9448-6c9da5075fe6@github.com>

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

>> Hi @iwanowww . I finished implementing a version of this like the illustration below (I didn't add a Candidate class). 
>> 
>> 
>> ScopeValue
>>     ObjectValue
>>         ObjectAllocationValue
>>             AutoBoxObjectValue
>>         ObjectMergeValue
>> 
>>  
>> Here are some observations:
>> 
>> - I don't think ObjectMergeValue should be under ObjectValue. The two classes only have two fields in common (_id and _visited). I think it should be a subclass of ScopeValue.
>> - ObjectCandidateValue would need to go under ObjectAllocationValue because it essentially _is_ an ObjectAllocationValue in most aspects.
>> - I didn't add a ObjectCandidateValue class because that class would need to go under ObjectAllocationValue and we would still need to do an "is_object_candidate" before all "is_object_allocation" and we would end up in much the situation that we want to avoid - needing to do is_object_merge before is_object.
>> - It seems the best place to flag an object as candidate is really in ObjectAllocationValue.
>> 
>> What do you think? As I said, I already have the code, if you want I can push it and you take a look.
>
> 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.

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

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


From weijun at openjdk.org  Fri Apr 28 00:32:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 00:32:01 GMT
Subject: RFR: 8307077: Convert CRLF to LF in java.xml.crypto
In-Reply-To: <bhjiEU6t3IN-wQ9V2GnrLcOnmW_5GNM8APRcfyr57mg=.e10d6ef2-9748-494f-a104-294462865e9e@github.com>
References: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
 <bhjiEU6t3IN-wQ9V2GnrLcOnmW_5GNM8APRcfyr57mg=.e10d6ef2-9748-494f-a104-294462865e9e@github.com>
Message-ID: <7v8BlVurJmB93NZ0BG7uh3x-l_nX3PaGImdT3hvS5_M=.e3319767-78f6-4c9a-a7c3-c2c273ace92d@github.com>

On Thu, 27 Apr 2023 23:06:40 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Convert CRLF to LF in these files so it's consistent with other source files.
>
> LGTM
> I wrote a program to count CRLF in the four changed files in order to verify your fix.

@mcpowers I looked at the lower-right corner of IntelliJ IDEA to ensure the line separator was modified.

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

PR Comment: https://git.openjdk.org/jdk/pull/13700#issuecomment-1526806889


From weijun at openjdk.org  Fri Apr 28 01:08:00 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 01:08:00 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <JaV5AuzKVOpbHbzrwOn67x2d2AZNhX4b0QTBqoci3fc=.07a87ff9-8d1a-40bb-8c18-2e348113cb22@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
 <JaV5AuzKVOpbHbzrwOn67x2d2AZNhX4b0QTBqoci3fc=.07a87ff9-8d1a-40bb-8c18-2e348113cb22@github.com>
Message-ID: <DWXGJi9okSXtipwWm41ewoQJ9OGfmdslR55D4uXk76M=.04264fbc-c408-4788-bd26-b00ab5c51f92@github.com>

On Thu, 27 Apr 2023 22:53:04 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I feel the use of `from` and `to` is error prone. I know I never remember if Arrays.copyOfRange() includes or excludes the `to` index. I think less mistakes would be made if it used `index` and `length` instead.

My feeling is that modern APIs use `from` and `to` instead of `from` and `length`. For example, `Arrays.copyOfRange`, `Arrays.equals` and `Arrays.compare` vs `new String(daata, from, length)`.

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

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


From duke at openjdk.org  Fri Apr 28 08:59:53 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 28 Apr 2023 08:59:53 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <DWXGJi9okSXtipwWm41ewoQJ9OGfmdslR55D4uXk76M=.04264fbc-c408-4788-bd26-b00ab5c51f92@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
 <JaV5AuzKVOpbHbzrwOn67x2d2AZNhX4b0QTBqoci3fc=.07a87ff9-8d1a-40bb-8c18-2e348113cb22@github.com>
 <DWXGJi9okSXtipwWm41ewoQJ9OGfmdslR55D4uXk76M=.04264fbc-c408-4788-bd26-b00ab5c51f92@github.com>
Message-ID: <KtO9pHnztrORY2wqApf-KqO-cwaYZnwHlM2x0i1KAWw=.78eb3f5c-f666-4fd8-912e-4f85e5940618@github.com>

On Fri, 28 Apr 2023 00:47:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I feel the use of `from` and `to` is error prone. I know I never remember if Arrays.copyOfRange() includes or excludes the `to` index. I think less mistakes would be made if it used `index` and `length` instead.

I think from and to are confusing mainly to old C programmers who got used to the "for (I = 0; I < n; i++)" way of expressing a range of length n, a syntax of "for I going from 0 to n-1" would have been more natural (to me at least). When you say "I will be on vacation from the 12th to the 14th of August", you wouldn't think you would be back at work on the 14th, would you (well, maybe an old C programmer would :-) )? To me, "from, to" and "start, length" are equivalent (provided from == start && length == to - from + 1).

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

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


From duke at openjdk.org  Fri Apr 28 11:36:53 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 28 Apr 2023 11:36:53 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
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: <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@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:

  review comments addressed

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

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

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

  Stats: 34 lines in 3 files changed: 8 ins; 12 del; 14 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  Fri Apr 28 11:37:24 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 28 Apr 2023 11:37:24 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
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: <k9YXvBneqn45SbCGKIFchWFFq-6IcZGGP_lwe-9tZbE=.9a26d14c-3d2e-475f-9dea-2395e5cc474b@github.com>

On Thu, 27 Apr 2023 17:43:02 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 43:
> 
>> 41: public class HSS extends SignatureSpi {
>> 42:     private HSSPublicKey pubKey;
>> 43:     private byte[] message;
> 
> How about using a `ByteArrayOutputStream` to store the message? Then we don't need to take care of memory management.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 56:
> 
>> 54: 
>> 55:     protected void engineInitSign(PrivateKey publicKey) {
>> 56:         throw new UnsupportedOperationException();
> 
> Sean suggested we change this to throw an `InvalidKeyException`. Otherwise, we might need to update the `Signature` spec on this.
> 
> Also, `s/publicKey/privateKey/`.

Done.

> src/java.base/share/classes/sun/security/provider/SunEntries.java line 190:
> 
>> 188: 
>> 189:         add(p, "Signature", "HSS/LMS", "sun.security.provider.HSS");
>> 190:         add(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl");
> 
> Use `addWithAlias` so we have OID has alias too. This is mentioned in the CSR. You can even add a test to ensure this.

Done.

> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 651:
> 
>> 649: 
>> 650:     public static final ObjectIdentifier hsslms_oid =
>> 651:             ObjectIdentifier.of(KnownOIDs.HSSLMS);
> 
> You probably don't need to define this if it's not used anywhere.

I need it now, with the addWithAlias() change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180274992
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180275120
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180275054
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180275220


From sean.mullan at oracle.com  Fri Apr 28 13:02:02 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 28 Apr 2023 09:02:02 -0400
Subject: There is unnecessary resource consumption in
 `SecureRandom.getInstance()`.
In-Reply-To: <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>
References: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>
 <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>
Message-ID: <5b97ea90-c5ec-bf8e-5e8b-1e7aafc5dedb@oracle.com>

[This should be discussed on the security alias so I am copying 
security-dev and -bcc-ing core-libs-dev]

As Bernd noted, use of SHA1PRNG should ideally be replaced with a 
stronger secure random algorithm, so the impact of this issue is 
probably not that significant. That said, I think this is still worthy 
of fixing.

On 4/28/23 7:40 AM, Bernd wrote:
> There are two solutions I think.
> 
> 1. Create a constructor for SecureRandom.

#1 seems easy enough. We can add a SecureRandom(SecureRandomParameters) 
to sun.security.provider.SecureRandom. (The ctor can ignore the 
parameter and just call SecureRandom()).

I can file an issue on your behalf.

> 2. Compare using getConstructors instead of getConstrctor.

--Sean


From sean.mullan at oracle.com  Fri Apr 28 13:09:45 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 28 Apr 2023 09:09:45 -0400
Subject: There is unnecessary resource consumption in
 `SecureRandom.getInstance()`.
In-Reply-To: <5b97ea90-c5ec-bf8e-5e8b-1e7aafc5dedb@oracle.com>
References: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>
 <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>
 <5b97ea90-c5ec-bf8e-5e8b-1e7aafc5dedb@oracle.com>
Message-ID: <fd5c3307-9680-258c-a07d-2dcee9a650ae@oracle.com>

Original post is pasted below.

On 4/28/23 9:02 AM, Sean Mullan wrote:
> [This should be discussed on the security alias so I am copying
> security-dev and -bcc-ing core-libs-dev]
> 
> As Bernd noted, use of SHA1PRNG should ideally be replaced with a
> stronger secure random algorithm, so the impact of this issue is
> probably not that significant. That said, I think this is still worthy
> of fixing.
> 
> On 4/28/23 7:40 AM, Bernd wrote:
>> There are two solutions I think.
>>
>> 1. Create a constructor for SecureRandom.
> 
> #1 seems easy enough. We can add a SecureRandom(SecureRandomParameters)
> to sun.security.provider.SecureRandom. (The ctor can ignore the
> parameter and just call SecureRandom()).
> 
> I can file an issue on your behalf.
> 
>> 2. Compare using getConstructors instead of getConstrctor.
> 
> --Sean
-------------- next part --------------
An embedded message was scrubbed...
From: =?UTF-8?B?6rWs7YOc7KeE?= <koo.taejin at gmail.com>
Subject: There is unnecessary resource consumption in `SecureRandom.getInstance()`.
Date: Fri, 28 Apr 2023 15:04:37 +0900
Size: 26461
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230428/d0b8ca69/ThereisunnecessaryresourceconsumptioninSecureRandom.getInstance..eml>

From mullan at openjdk.org  Fri Apr 28 13:54:03 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 28 Apr 2023 13:54:03 GMT
Subject: RFR: 8307077: Convert CRLF to LF in java.xml.crypto
In-Reply-To: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
References: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
Message-ID: <c9vPWhO6ptkag8vgfM0hH6YAlL8RjjAR1q63KGV-6Ps=.02e1cf49-bf1c-41e9-8692-38bdd8c8f58a@github.com>

On Thu, 27 Apr 2023 19:01:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Convert CRLF to LF in these files so it's consistent with other source files.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13700#pullrequestreview-1405976589


From mullan at openjdk.org  Fri Apr 28 14:05:26 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 28 Apr 2023 14:05:26 GMT
Subject: RFR: 8305975: Add TWCA Global Root CA
In-Reply-To: <BSp38OXZ4OkmXZR46CKmHhpD30wnJpGM06Kt5oKJmb8=.59326fab-aa7b-48f0-b591-ae83b6b27533@github.com>
References: <BSp38OXZ4OkmXZR46CKmHhpD30wnJpGM06Kt5oKJmb8=.59326fab-aa7b-48f0-b591-ae83b6b27533@github.com>
Message-ID: <337CwqwnM-cN3plkHvwGOKxuaxB5uS45riNbxTxb3QY=.7b86c28e-ebf6-483b-8738-9528ff2a8e55@github.com>

On Thu, 27 Apr 2023 18:38:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add new root certificate from TWCA root. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13699#pullrequestreview-1406000678


From weijun at openjdk.org  Fri Apr 28 15:26:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 15:26:23 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
Message-ID: <bfjDLLQq5iRP6upmpV33EB-qmY094XjnrsUBTpnzqw4=.e58581e5-e55f-4858-9735-526dc8936837@github.com>

On Fri, 28 Apr 2023 11:36:53 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:
> 
>   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.

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.

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?

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".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180439364
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180478493
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180442130
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1180416477


From weijun at openjdk.org  Fri Apr 28 15:28:22 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 15:28:22 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <k9YXvBneqn45SbCGKIFchWFFq-6IcZGGP_lwe-9tZbE=.9a26d14c-3d2e-475f-9dea-2395e5cc474b@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>
Message-ID: <9RRITm9kBt_cSdt_NMnOJoWpJ83acPy0Xnof8Ss7y9g=.4b23380d-1886-4925-aa8b-42ba63590045@github.com>

On Fri, 28 Apr 2023 11:05:33 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 651:
>> 
>>> 649: 
>>> 650:     public static final ObjectIdentifier hsslms_oid =
>>> 651:             ObjectIdentifier.of(KnownOIDs.HSSLMS);
>> 
>> You probably don't need to define this if it's not used anywhere.
>
> I need it now, with the addWithAlias() change.

`addWithAlias` search for an OID by its name using the `KnownOIDs` class.

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

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


From dcubed at openjdk.org  Fri Apr 28 15:39:23 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 28 Apr 2023 15:39:23 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v2]
In-Reply-To: <uwDmlKbnovbFGsg4OZT_oRLyPSZoyn4taGQ6cqFL9j4=.27760720-9ced-444a-8df4-ac8475451cb9@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <uwDmlKbnovbFGsg4OZT_oRLyPSZoyn4taGQ6cqFL9j4=.27760720-9ced-444a-8df4-ac8475451cb9@github.com>
Message-ID: <g1rR8IFh2sIWGVLWrcqog2e7tInWasm4uAR_jnuMooo=.ff45ddd4-c4d6-4038-b7f9-5d172bed6aa0@github.com>

On Fri, 14 Apr 2023 19:03:16 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:
> 
>   updated copyright

Try this: "/issue JDK-8294985"
(I don't know if only the PR owner can do that one...)

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

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


From djelinski at openjdk.org  Fri Apr 28 15:39:53 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 28 Apr 2023 15:39:53 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v2]
In-Reply-To: <uwDmlKbnovbFGsg4OZT_oRLyPSZoyn4taGQ6cqFL9j4=.27760720-9ced-444a-8df4-ac8475451cb9@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <uwDmlKbnovbFGsg4OZT_oRLyPSZoyn4taGQ6cqFL9j4=.27760720-9ced-444a-8df4-ac8475451cb9@github.com>
Message-ID: <0XOBNY3-KQFh5KuOXORsDfit_UqMfBSJor4yRqmV0Gw=.dbea99a1-4be4-43c9-b623-745e10b78365@github.com>

On Fri, 14 Apr 2023 19:03:16 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:
> 
>   updated copyright

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 284:

> 282:                 shc.peerSupportedAuthorities = spec.getAuthorities();
> 283:             } catch (IllegalArgumentException iae) {
> 284:                 throw new SSLException(iae);

Suggestion:

                throw shc.conContext.fatal(Alert.ILLEGAL_PARAMETER,
                        "Certificate authority distinguished name is not valid");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1180543939


From rhalade at openjdk.org  Fri Apr 28 16:33:30 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 28 Apr 2023 16:33:30 GMT
Subject: Integrated: 8305975: Add TWCA Global Root CA
In-Reply-To: <BSp38OXZ4OkmXZR46CKmHhpD30wnJpGM06Kt5oKJmb8=.59326fab-aa7b-48f0-b591-ae83b6b27533@github.com>
References: <BSp38OXZ4OkmXZR46CKmHhpD30wnJpGM06Kt5oKJmb8=.59326fab-aa7b-48f0-b591-ae83b6b27533@github.com>
Message-ID: <vbvsWw8Es6h-QxLn4RfqGxpWEH6N7_ghGLCQlsMG1Tg=.57e8e563-9c40-41dd-8b89-211eb4f431fc@github.com>

On Thu, 27 Apr 2023 18:38:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add new root certificate from TWCA root. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.

This pull request has now been integrated.

Changeset: 82ccfe3a
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82ccfe3a21f6f9933d96c52286ecb4d6b432abb2
Stats:     249 lines in 3 files changed: 247 ins; 0 del; 2 mod

8305975: Add TWCA Global Root CA

Reviewed-by: mullan

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

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


From weijun at openjdk.org  Fri Apr 28 16:36:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 16:36:23 GMT
Subject: Integrated: 8307077: Convert CRLF to LF in java.xml.crypto
In-Reply-To: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
References: <TJWRhnpYTTdcfjHdT966gCwcrW4qbqTd7Sk-Xv79JcA=.db276184-ea59-400d-be6d-971e953fe031@github.com>
Message-ID: <frA9sfDa0z8d2r8iAsDpSWwCn7Ui1nhkHy0Pm6ythQs=.c1311eb9-c1fa-4dc2-9f1f-432bb5f49b6f@github.com>

On Thu, 27 Apr 2023 19:01:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Convert CRLF to LF in these files so it's consistent with other source files.

This pull request has now been integrated.

Changeset: 9ff55508
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ff555083a1ba367ea157b8e1de28e62c1ce2f19
Stats:     1153 lines in 4 files changed: 0 ins; 0 del; 1153 mod

8307077: Convert CRLF to LF in java.xml.crypto

Reviewed-by: mullan

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

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


From ascarpino at openjdk.org  Fri Apr 28 17:33:23 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 28 Apr 2023 17:33:23 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <DWXGJi9okSXtipwWm41ewoQJ9OGfmdslR55D4uXk76M=.04264fbc-c408-4788-bd26-b00ab5c51f92@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
 <JaV5AuzKVOpbHbzrwOn67x2d2AZNhX4b0QTBqoci3fc=.07a87ff9-8d1a-40bb-8c18-2e348113cb22@github.com>
 <DWXGJi9okSXtipwWm41ewoQJ9OGfmdslR55D4uXk76M=.04264fbc-c408-4788-bd26-b00ab5c51f92@github.com>
Message-ID: <Heyb_-zRCQOktfWj4rTsezYAhpemv5ym6tWEhAoHokU=.e7bcf3e6-e749-4903-850c-4849858e55c4@github.com>

On Fri, 28 Apr 2023 00:47:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> My feeling is that modern APIs use `from` and `to` instead of `from` and `length`. For example, `Arrays.copyOfRange`, `Arrays.equals` and `Arrays.compare` vs `new String(daata, from, length)`.

I don't see this as a modern vs old API style, it's consistency.  `Arrays.copyOfRange()` is from 1.6.  I think it's being consistent with other JCA classes, like Cipher, Signature, MessageDigest, and Mac.  I'm not aware of any JCA that uses (from, to).

Also `Arrays` methods use length of any size.  KEM does not.  In fact it is very obvious what the length is as it must be the key size when looking at `DHKEM.decapsulate(...)`:

    Objects.checkFromToIndex(from, to, params.Nsecret);

One could argue that `to` isn't necessary given the length is fixed by the `params`.

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

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


From mpowers at openjdk.org  Fri Apr 28 18:06:54 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 28 Apr 2023 18:06:54 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
Message-ID: <QQQlL4bdGZ3f74wNHrAb6HBJEXzKSqXVxQ-qI_RbQQA=.21e612b0-adac-4a31-99b6-3d9e876d4f2a@github.com>

On Fri, 28 Apr 2023 11:36:53 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:
> 
>   review comments addressed

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?

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

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


From kdriver at openjdk.org  Fri Apr 28 19:15:59 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Apr 2023 19:15:59 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v3]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@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:

  Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/d4a73407..968a2882

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

  Stats: 2 lines in 1 file changed: 1 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  Fri Apr 28 19:23:27 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Apr 2023 19:23:27 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
In-Reply-To: <rjITB-PgTG3J0mRNKl_Z735VL8KJkCsLfSWrENaDl-k=.f09bbfee-bdf1-412f-9a3d-eea6b436c3e4@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <rjITB-PgTG3J0mRNKl_Z735VL8KJkCsLfSWrENaDl-k=.f09bbfee-bdf1-412f-9a3d-eea6b436c3e4@github.com>
Message-ID: <ATeEP03JDRRwIQhYTe9bY0M1r7yPDzocq-MRzdy2tMs=.5602587c-2512-4495-8821-68321e4ce488@github.com>

On Fri, 14 Apr 2023 05:00:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> @driverkt Is [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) in WJBS a closed bug?  If it is cannot be public, would you mind add more description about what problem this PR is addressing?

@XueleiFan now that the bug is no longer marked confidential, please feel free to review.

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

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


From rhalade at openjdk.org  Fri Apr 28 19:27:27 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 28 Apr 2023 19:27:27 GMT
Subject: RFR: 8304760: Add 2 Microsoft TLS roots
Message-ID: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com>

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.

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

Commit messages:
 - Update checksun after TWCA integration
 - Merge branch 'master' into 8303393-microsofttls
 - Merge branch 'master' into 8303393-microsofttls
 - update ca certs data file
 - 8303393: Evaluate the inclusion of Microsoft 2 public TLS roots

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

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


From kdriver at openjdk.org  Fri Apr 28 19:52:57 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Apr 2023 19:52:57 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
Message-ID: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>

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

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294983
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 weijun at openjdk.org  Fri Apr 28 20:13:22 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 20:13:22 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <QQQlL4bdGZ3f74wNHrAb6HBJEXzKSqXVxQ-qI_RbQQA=.21e612b0-adac-4a31-99b6-3d9e876d4f2a@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>
Message-ID: <Ts8qdGtIJzCsJjC2C3TsDSPCBcdnikLeDRwlmLWOF_g=.edb9ebd7-c606-48dd-88d5-4b3873e0dd62@github.com>

On Fri, 28 Apr 2023 17:46:40 GMT, Mark Powers <mpowers 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 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.

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

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


From kdriver at openjdk.org  Fri Apr 28 20:49:30 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Apr 2023 20:49:30 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v2]
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: <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - updated copyright
 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294983
 - set consumer to null if we're not in client mode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13727/files
  - new: https://git.openjdk.org/jdk/pull/13727/files/ca4e3ee1..a249a9bb

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

  Stats: 4160 lines in 34 files changed: 2947 ins; 22 del; 1191 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  Fri Apr 28 21:15:56 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Apr 2023 21:15:56 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty
Message-ID: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>

Fix type-o and update returns message.

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

Commit messages:
 - JDK-8305963 fix type-o and update returns message

Changes: https://git.openjdk.org/jdk/pull/13729/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305963
  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 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 coffeys at openjdk.org  Fri Apr 28 21:35:54 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 28 Apr 2023 21:35: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: <lW6Vl9_9RFWJZfflWrhZhO2WbmdRoNO6s40t46OInME=.47ba1b3d-a7f3-43f7-8aff-c5565b2e7a12@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.

Looks good

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

Marked as reviewed by coffeys (Reviewer).

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


From weijun at openjdk.org  Fri Apr 28 22:01:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Apr 2023 22:01:54 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: <KPz4rgOR6lBBec_XwBo_AFT6fmH0LrKZHPlJrzYpKkE=.831a1f6a-de92-4bb9-b8e8-d4b48cdc4b61@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

Maybe 1.6 is already modern enough. ;-)

`to` is useful if `secretSize` is 48 but you want an AES-256 key, then you would call `encapsulate(0, 32, "AES")` or `encapsulate(16, 48, "AES")`, depending on how your protocol demands.

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

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


From mpowers at openjdk.org  Fri Apr 28 22:11:52 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 28 Apr 2023 22:11:52 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v2]
In-Reply-To: <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
 <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com>
Message-ID: <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com>

On Fri, 28 Apr 2023 20:49: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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - updated copyright
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294983
>  - set consumer to null if we're not in client mode

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.

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?

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

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


From wetmore at openjdk.org  Sat Apr 29 02:23:24 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 29 Apr 2023 02:23:24 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
In-Reply-To: <rjITB-PgTG3J0mRNKl_Z735VL8KJkCsLfSWrENaDl-k=.f09bbfee-bdf1-412f-9a3d-eea6b436c3e4@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <rjITB-PgTG3J0mRNKl_Z735VL8KJkCsLfSWrENaDl-k=.f09bbfee-bdf1-412f-9a3d-eea6b436c3e4@github.com>
Message-ID: <wTJ_ug9YHVi74JAZyYlDN1urH8NeMNIeeVMqjKNFbGg=.9e943755-6114-4fb2-98b4-7a4c2fd5ad87@github.com>

On Fri, 14 Apr 2023 05:00:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> @driverkt Is [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) in WJBS a closed bug?  If it is cannot be public, would you mind add more description about what problem this PR is addressing?

Since this has already been marked `/integrate`, I can sponsor next week, in case @XueleiFan has any last minute comments.

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

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


From weijun at openjdk.org  Sun Apr 30 13:20:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 30 Apr 2023 13:20:54 GMT
Subject: RFR: 8307143: CredentialsCache.cacheName should not be static
Message-ID: <4ErtNxM1gNx8rPGo4X0O3QJMjoVTGHALHDpztmdqC48=.b01795e2-531a-48cb-8225-129e3c1924f9@github.com>

The CC can be loaded with any file and its name is not static.

`MemoryCredentialsCache` is removed since it's not used anywhere. We've already supported native ccache reading directly with JNI method `Credentials::acquireDefaultNativeCreds`.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13737/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307143
  Stats: 173 lines in 5 files changed: 56 ins; 82 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/13737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13737/head:pull/13737

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


From koo.taejin at gmail.com  Sat Apr 29 05:29:05 2023
From: koo.taejin at gmail.com (=?UTF-8?B?6rWs7YOc7KeE?=)
Date: Sat, 29 Apr 2023 05:29:05 -0000
Subject: There is unnecessary resource consumption in
 `SecureRandom.getInstance()`.
In-Reply-To: <5b97ea90-c5ec-bf8e-5e8b-1e7aafc5dedb@oracle.com>
References: <CACzBzePNaPDm_JQhAdT9sRKeRKE8WuRi9yLSbfxcyi=HMjacYA@mail.gmail.com>
 <7BB18D5E-8F27-4545-8C70-621CF2D8FC47@hxcore.ol>
 <5b97ea90-c5ec-bf8e-5e8b-1e7aafc5dedb@oracle.com>
Message-ID: <CACzBzeM4H0nfEPiESM4CbsGjg3NiV88Z6t=LyoSafh=MjXkfmw@mail.gmail.com>

I understood what you said.
And thank you for forwarding this mail to security-dev.
If it is decided to fix this issue and this issue is not as much work as I
thought.
If you give me the opportunity to change the code via PR, it will be a
great honor for a lifetime as a Java developer.

Thanks :)

2023? 4? 29? (?) ?? 2:04, Sean Mullan <sean.mullan at oracle.com>?? ??:

> [This should be discussed on the security alias so I am copying
> security-dev and -bcc-ing core-libs-dev]
>
> As Bernd noted, use of SHA1PRNG should ideally be replaced with a
> stronger secure random algorithm, so the impact of this issue is
> probably not that significant. That said, I think this is still worthy
> of fixing.
>
> On 4/28/23 7:40 AM, Bernd wrote:
> > There are two solutions I think.
> >
> > 1. Create a constructor for SecureRandom.
>
> #1 seems easy enough. We can add a SecureRandom(SecureRandomParameters)
> to sun.security.provider.SecureRandom. (The ctor can ignore the
> parameter and just call SecureRandom()).
>
> I can file an issue on your behalf.
>
> > 2. Compare using getConstructors instead of getConstrctor.
>
> --Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230429/c82f0938/attachment.htm>