From djelinski at openjdk.org  Mon Oct  2 08:33:32 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Oct 2023 08:33:32 GMT
Subject: RFR: 8317332: Prepare security for permissive-
In-Reply-To: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
Message-ID: <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>

On Sat, 30 Sep 2023 06:26:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Prepares java.security.jgss for the permissive- compiler switch by
> 
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static

Changes requested by djelinski (Reviewer).

src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 39:

> 37: 
> 38: #include <windows.h>
> 39: #include <cstdlib>

This seems unrelated; my MSVC doesn't complain about these headers.
The C form is still preferred, even in our CPP code. Can we leave this change out?

src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 372:

> 370:     SEC_WCHAR* value = new SEC_WCHAR[len + 1];
> 371: 
> 372:     {

This is ugly. I'm not a fan of braces appearing in the middle of the code for no apparent reason.

[This SO question](https://stackoverflow.com/questions/31513798/error-jump-to-label-foo-crosses-initialization-of-bar) states that we can fix the compilation errors by splitting inline initialization into definition + assignment. I think I'd prefer that approach.

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

PR Review: https://git.openjdk.org/jdk/pull/15996#pullrequestreview-1652256933
PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1342380436
PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1342375351

From jwaters at openjdk.org  Mon Oct  2 08:33:32 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 2 Oct 2023 08:33:32 GMT
Subject: RFR: 8317332: Prepare security for permissive-
In-Reply-To: <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>
Message-ID: <NODu7JqA3zkj2FLmQyT9RsQSS1vViDXjEaq1NvSnFjM=.52daec77-58fc-4b36-b8e4-9e72289246f9@github.com>

On Mon, 2 Oct 2023 07:57:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 39:
> 
>> 37: 
>> 38: #include <windows.h>
>> 39: #include <cstdlib>
> 
> This seems unrelated; my MSVC doesn't complain about these headers.
> The C form is still preferred, even in our CPP code. Can we leave this change out?

This was just a stylistic change, I'll leave it out

> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 372:
> 
>> 370:     SEC_WCHAR* value = new SEC_WCHAR[len + 1];
>> 371: 
>> 372:     {
> 
> This is ugly. I'm not a fan of braces appearing in the middle of the code for no apparent reason.
> 
> [This SO question](https://stackoverflow.com/questions/31513798/error-jump-to-label-foo-crosses-initialization-of-bar) states that we can fix the compilation errors by splitting inline initialization into definition + assignment. I think I'd prefer that approach.

I agree that it's ugly, but at the time I couldn't think of another way to solve the issue. By any chance, why does splitting it out into separate declaration assignment work? Last I remember, it still jumps over the local even when split up like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1342399094
PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1342401153

From duke at openjdk.org  Mon Oct  2 09:45:58 2023
From: duke at openjdk.org (Michal Sobierski)
Date: Mon, 2 Oct 2023 09:45:58 GMT
Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java
 subtests [v3]
In-Reply-To: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
Message-ID: <bXD3SyEeGdMDeDTJTK8ZHmESFo5TLVm2CFHAig-0uS8=.d1af278b-4525-41ca-8485-9386abacab2b@github.com>

> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it.
> 
> Comparison of before and after parallelization:
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1"
> before:   270.72s user 4.88s system 108% cpu 4:14.43 total
> after:   410.76s user 7.50s system 555% cpu 1:15.23 total
> after second commit:   375.46s user 4.59s system 539% cpu 1:10.41 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC"
> before:   63.67s user 4.67s system 161% cpu 42.424 total
> after:   130.36s user 7.47s system 585% cpu 23.526 total
> after second commit:   67.31s user 4.48s system 417% cpu 17.183 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1"
> before:   281.99s user 5.54s system 108% cpu 4:24.09 total
> after:   386.98s user 8.62s system 496% cpu 1:19.73 total
> after second commit:   413.51s user 5.08s system 613% cpu 1:08.25 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
> before:   65.86s user 5.05s system 156% cpu 45.215 total
> after:   135.90s user 7.66s system 585% cpu 24.502 total
> after second commit:   83.25s user 4.82s system 469% cpu 18.741 total

Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/sun/security/rsa/SignedObjectChain.java
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15860/files
  - new: https://git.openjdk.org/jdk/pull/15860/files/0040ba31..e39c326d

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

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

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

From duke at openjdk.org  Mon Oct  2 10:02:04 2023
From: duke at openjdk.org (Michal Sobierski)
Date: Mon, 2 Oct 2023 10:02:04 GMT
Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java
 subtests [v4]
In-Reply-To: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
Message-ID: <lybpwD66X_esJN1KCODN-6FNf9mCTUy6EKOfw0ItwHg=.2399da24-1218-4980-b747-1abf60091024@github.com>

> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it.
> 
> Comparison of before and after parallelization:
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1"
> before:   270.72s user 4.88s system 108% cpu 4:14.43 total
> after:   410.76s user 7.50s system 555% cpu 1:15.23 total
> after second commit:   375.46s user 4.59s system 539% cpu 1:10.41 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC"
> before:   63.67s user 4.67s system 161% cpu 42.424 total
> after:   130.36s user 7.47s system 585% cpu 23.526 total
> after second commit:   67.31s user 4.48s system 417% cpu 17.183 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1"
> before:   281.99s user 5.54s system 108% cpu 4:24.09 total
> after:   386.98s user 8.62s system 496% cpu 1:19.73 total
> after second commit:   413.51s user 5.08s system 613% cpu 1:08.25 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
> before:   65.86s user 5.05s system 156% cpu 45.215 total
> after:   135.90s user 7.66s system 585% cpu 24.502 total
> after second commit:   83.25s user 4.82s system 469% cpu 18.741 total

Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision:

  Remove additional line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15860/files
  - new: https://git.openjdk.org/jdk/pull/15860/files/e39c326d..b3c885ff

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

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

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

From duke at openjdk.org  Mon Oct  2 10:02:05 2023
From: duke at openjdk.org (Michal Sobierski)
Date: Mon, 2 Oct 2023 10:02:05 GMT
Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java
 subtests [v4]
In-Reply-To: <lybpwD66X_esJN1KCODN-6FNf9mCTUy6EKOfw0ItwHg=.2399da24-1218-4980-b747-1abf60091024@github.com>
References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
 <lybpwD66X_esJN1KCODN-6FNf9mCTUy6EKOfw0ItwHg=.2399da24-1218-4980-b747-1abf60091024@github.com>
Message-ID: <scCsyXwfDaaPJcJP-kQPKNUsipmdK2imDfWCJhePAwU=.87a54758-923c-4a56-b440-b593a5b3fc35@github.com>

On Mon, 2 Oct 2023 09:56:26 GMT, Michal Sobierski <duke at openjdk.org> wrote:

>> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it.
>> 
>> Comparison of before and after parallelization:
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1"
>> before:   270.72s user 4.88s system 108% cpu 4:14.43 total
>> after:   410.76s user 7.50s system 555% cpu 1:15.23 total
>> after second commit:   375.46s user 4.59s system 539% cpu 1:10.41 total
>> 
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC"
>> before:   63.67s user 4.67s system 161% cpu 42.424 total
>> after:   130.36s user 7.47s system 585% cpu 23.526 total
>> after second commit:   67.31s user 4.48s system 417% cpu 17.183 total
>> 
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1"
>> before:   281.99s user 5.54s system 108% cpu 4:24.09 total
>> after:   386.98s user 8.62s system 496% cpu 1:19.73 total
>> after second commit:   413.51s user 5.08s system 613% cpu 1:08.25 total
>> 
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
>> before:   65.86s user 5.05s system 156% cpu 45.215 total
>> after:   135.90s user 7.66s system 585% cpu 24.502 total
>> after second commit:   83.25s user 4.82s system 469% cpu 18.741 total
>
> Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove additional line

Removing unnecessary line

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

PR Review: https://git.openjdk.org/jdk/pull/15860#pullrequestreview-1652431994

From shade at openjdk.org  Mon Oct  2 10:02:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Oct 2023 10:02:07 GMT
Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java
 subtests [v4]
In-Reply-To: <lybpwD66X_esJN1KCODN-6FNf9mCTUy6EKOfw0ItwHg=.2399da24-1218-4980-b747-1abf60091024@github.com>
References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
 <lybpwD66X_esJN1KCODN-6FNf9mCTUy6EKOfw0ItwHg=.2399da24-1218-4980-b747-1abf60091024@github.com>
Message-ID: <ZoDD7rrpJDGA1JcHEVlN8I7_a52D9fLacqC-a-TdQPU=.5e56db74-3930-4db9-bf89-233227b31508@github.com>

On Mon, 2 Oct 2023 09:56:26 GMT, Michal Sobierski <duke at openjdk.org> wrote:

>> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it.
>> 
>> Comparison of before and after parallelization:
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1"
>> before:   270.72s user 4.88s system 108% cpu 4:14.43 total
>> after:   410.76s user 7.50s system 555% cpu 1:15.23 total
>> after second commit:   375.46s user 4.59s system 539% cpu 1:10.41 total
>> 
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC"
>> before:   63.67s user 4.67s system 161% cpu 42.424 total
>> after:   130.36s user 7.47s system 585% cpu 23.526 total
>> after second commit:   67.31s user 4.48s system 417% cpu 17.183 total
>> 
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1"
>> before:   281.99s user 5.54s system 108% cpu 4:24.09 total
>> after:   386.98s user 8.62s system 496% cpu 1:19.73 total
>> after second commit:   413.51s user 5.08s system 613% cpu 1:08.25 total
>> 
>> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
>> before:   65.86s user 5.05s system 156% cpu 45.215 total
>> after:   135.90s user 7.66s system 585% cpu 24.502 total
>> after second commit:   83.25s user 4.82s system 469% cpu 18.741 total
>
> Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove additional line

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15860#pullrequestreview-1652432287

From duke at openjdk.org  Mon Oct  2 10:02:09 2023
From: duke at openjdk.org (Michal Sobierski)
Date: Mon, 2 Oct 2023 10:02:09 GMT
Subject: Integrated: 8316415: Parallelize
 sun/security/rsa/SignedObjectChain.java subtests
In-Reply-To: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com>
Message-ID: <KAJB1KdUAYnRURKLykojYI7cg5T47vzmn76IdSDkvSk=.644acd40-a038-4eba-b126-100783018abc@github.com>

On Thu, 21 Sep 2023 12:44:36 GMT, Michal Sobierski <duke at openjdk.org> wrote:

> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it.
> 
> Comparison of before and after parallelization:
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1"
> before:   270.72s user 4.88s system 108% cpu 4:14.43 total
> after:   410.76s user 7.50s system 555% cpu 1:15.23 total
> after second commit:   375.46s user 4.59s system 539% cpu 1:10.41 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC"
> before:   63.67s user 4.67s system 161% cpu 42.424 total
> after:   130.36s user 7.47s system 585% cpu 23.526 total
> after second commit:   67.31s user 4.48s system 417% cpu 17.183 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1"
> before:   281.99s user 5.54s system 108% cpu 4:24.09 total
> after:   386.98s user 8.62s system 496% cpu 1:19.73 total
> after second commit:   413.51s user 5.08s system 613% cpu 1:08.25 total
> 
> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
> before:   65.86s user 5.05s system 156% cpu 45.215 total
> after:   135.90s user 7.66s system 585% cpu 24.502 total
> after second commit:   83.25s user 4.82s system 469% cpu 18.741 total

This pull request has now been integrated.

Changeset: 59847926
Author:    Michal Sobierski <145339032+msobiers at users.noreply.github.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59847926b63860704bcf2967660628eaede8ee36
Stats:     7 lines in 1 file changed: 2 ins; 2 del; 3 mod

8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests

Reviewed-by: shade, rhalade, valeriep

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

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

From djelinski at openjdk.org  Mon Oct  2 12:30:12 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Oct 2023 12:30:12 GMT
Subject: RFR: 8317332: Prepare security for permissive-
In-Reply-To: <NODu7JqA3zkj2FLmQyT9RsQSS1vViDXjEaq1NvSnFjM=.52daec77-58fc-4b36-b8e4-9e72289246f9@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>
 <NODu7JqA3zkj2FLmQyT9RsQSS1vViDXjEaq1NvSnFjM=.52daec77-58fc-4b36-b8e4-9e72289246f9@github.com>
Message-ID: <f7Vx1tZyNMS_lw8jdIGanWugf7z5jn4q71SOSQSNRTk=.d1159a6e-61ba-49f1-a085-443e3be91add@github.com>

On Mon, 2 Oct 2023 08:19:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 372:
>> 
>>> 370:     SEC_WCHAR* value = new SEC_WCHAR[len + 1];
>>> 371: 
>>> 372:     {
>> 
>> This is ugly. I'm not a fan of braces appearing in the middle of the code for no apparent reason.
>> 
>> [This SO question](https://stackoverflow.com/questions/31513798/error-jump-to-label-foo-crosses-initialization-of-bar) states that we can fix the compilation errors by splitting inline initialization into definition + assignment. I think I'd prefer that approach.
>
> I agree that it's ugly, but at the time I couldn't think of another way to solve the issue. By any chance, why does splitting it out into separate declaration assignment work? Last I remember, it still jumps over the local even when split up like this.

Well, SO offers a speculative answer:
https://stackoverflow.com/a/14274292
the modified form is not more safe, but the standard does not forbid it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1342622719

From mpowers at openjdk.org  Mon Oct  2 15:06:12 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 15:06:12 GMT
Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts [v3]
In-Reply-To: <J4amjnvj2TEsg3W9aW753MPETVn9NOxFxasUObgduQ4=.0b7ff3c3-2454-4dcb-824f-ddfa26b54781@github.com>
References: <T-iHQNDgK_0ABHwc5A25-yUUHxO3OXy85FWkR6SEvsQ=.f053eadd-6b7a-4afd-a1d5-8cdf425d743a@github.com>
 <aChCoc_123squGQulb14VcOOQZK7Wpojq5AHauFxq6E=.eb0aa5f4-0671-47e5-9499-341894eb8fe6@github.com>
 <J4amjnvj2TEsg3W9aW753MPETVn9NOxFxasUObgduQ4=.0b7ff3c3-2454-4dcb-824f-ddfa26b54781@github.com>
Message-ID: <GdET8evRLrX-JYf02PVVHGn3cTW3bsFlB98MQRkCNz4=.22065c98-e521-4e10-af0d-6b48444c778d@github.com>

On Thu, 28 Sep 2023 20:22:40 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more sqlite conversion needed
>
> Thanks, changes look good to me.

@valeriepeng Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1743189286

From mpowers at openjdk.org  Mon Oct  2 17:00:11 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 17:00:11 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3]
In-Reply-To: <oKanr6o0KH9PyZTTrHc1-pn0WeUS2ZYZHShctZVm_rI=.7ccc828a-c20f-41c6-a23c-27d420916d7d@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <d9_iXOZPRvx3W98fuZN9ihluik_BaXupSR0iehUZzKk=.e6966e2f-4f4d-4369-9951-4e4c2bac05d3@github.com>
 <oKanr6o0KH9PyZTTrHc1-pn0WeUS2ZYZHShctZVm_rI=.7ccc828a-c20f-41c6-a23c-27d420916d7d@github.com>
Message-ID: <kAxnCJrMocddMN90qU8aDf0HAbHTXq69BkKcIwExrf8=.2f6fa6a6-975b-4fac-9f3f-db0bb7b86517@github.com>

On Mon, 25 Sep 2023 15:29:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment from Weijun
>
> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 76:
> 
>> 74: 
>> 75:         System.out.println("CRLException has not been thrown");
>> 76:         return false;
> 
> I think only `generateCRLs` is enough here since neither bug is about X.509 encoding.

I don't understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1342939114

From weijun at openjdk.org  Mon Oct  2 18:07:13 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 18:07:13 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3]
In-Reply-To: <kAxnCJrMocddMN90qU8aDf0HAbHTXq69BkKcIwExrf8=.2f6fa6a6-975b-4fac-9f3f-db0bb7b86517@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <d9_iXOZPRvx3W98fuZN9ihluik_BaXupSR0iehUZzKk=.e6966e2f-4f4d-4369-9951-4e4c2bac05d3@github.com>
 <oKanr6o0KH9PyZTTrHc1-pn0WeUS2ZYZHShctZVm_rI=.7ccc828a-c20f-41c6-a23c-27d420916d7d@github.com>
 <kAxnCJrMocddMN90qU8aDf0HAbHTXq69BkKcIwExrf8=.2f6fa6a6-975b-4fac-9f3f-db0bb7b86517@github.com>
Message-ID: <jGpDY_7HlkE2QtQMLtFPuwAnxZq8BL2nlDDNRz-_bes=.63aae6f9-553c-47d1-96e6-17687907c9a3@github.com>

On Mon, 2 Oct 2023 16:57:47 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 76:
>> 
>>> 74: 
>>> 75:         System.out.println("CRLException has not been thrown");
>>> 76:         return false;
>> 
>> I think only `generateCRLs` is enough here since neither bug is about X.509 encoding.
>
> I don't understand.

I mean there is no need to call both `generateCRL` and `generateCRLs`. The original test cases are about basic SEQUENCE encoding, the new test case is about PKCS7 encoding. These can be tested with a single `generateCRLs` call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1342997097

From weijun at openjdk.org  Mon Oct  2 18:15:37 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 18:15:37 GMT
Subject: Integrated: 8309356: Read files in includedir in alphanumeric order
In-Reply-To: <BWm0Xwq5KVKYH33iuwdUMB5PBfADIg-9NZ0WJ2AARfE=.6959d8a4-49d0-42a2-9dcc-77860312a302@github.com>
References: <BWm0Xwq5KVKYH33iuwdUMB5PBfADIg-9NZ0WJ2AARfE=.6959d8a4-49d0-42a2-9dcc-77860312a302@github.com>
Message-ID: <HFgnlLQT6U6MXhVFHwPS6j2HKMVVSWFal3kH_seQBTE=.530bb903-1a79-4bd7-b065-0e2350f76299@github.com>

On Fri, 22 Sep 2023 14:00:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Read files in `includedir` in alphanumerical order.

This pull request has now been integrated.

Changeset: f9850061
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f985006142c87d563f7e69d63b206c15e7e6f135
Stats:     77 lines in 2 files changed: 73 ins; 2 del; 2 mod

8309356: Read files in includedir in alphanumeric order

Reviewed-by: mullan

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

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

From mullan at openjdk.org  Mon Oct  2 18:46:51 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 2 Oct 2023 18:46:51 GMT
Subject: RFR: 8316771: Krb5.java has not defined messages for all error
 codes
In-Reply-To: <bs8hInqylaWMFKtXQS3DXMJ8f5P4aq-dDiBSSQH2-8E=.ffb1c652-b71d-4dfa-adf0-487f26d40f5e@github.com>
References: <bs8hInqylaWMFKtXQS3DXMJ8f5P4aq-dDiBSSQH2-8E=.ffb1c652-b71d-4dfa-adf0-487f26d40f5e@github.com>
Message-ID: <17CVM5b0E1Wt6W1_NIEjNimOxEYJDt4Ii3SzFSt0yxw=.30748f52-c3cd-47f8-b5dd-4bd153413b6d@github.com>

On Fri, 22 Sep 2023 20:05:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Added 4 missing error codes and removed 2 wrong ones.
> 
> KRB_AP_ERR_NOREALM claims itself to be "used in setDefaultCreds() in sun.security.krb5.Credentials" but it's no more.
> 
> KRB_AP_ERR_GEN_CRED is used in one place but it's a local error and not meant to be embedded in a message. Therefore safe to be removed.

Marked as reviewed by mullan (Reviewer).

src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java line 282:

> 280:     public static final int KRB_ERR_WRONG_REALM          = 68;   //Wrong realm
> 281: 
> 282:     public static final int KRB_CRYPTO_NOT_SUPPORT      = 100;   //Client does not support this crypto type

Just wondering, and not a specific review comment, but do you know if this error code is necessary? It isn't defined in RFC 4120 and not used in the JDK AFAICT.

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

PR Review: https://git.openjdk.org/jdk/pull/15892#pullrequestreview-1653293733
PR Review Comment: https://git.openjdk.org/jdk/pull/15892#discussion_r1343030560

From weijun at openjdk.org  Mon Oct  2 19:55:06 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 19:55:06 GMT
Subject: RFR: 8316771: Krb5.java has not defined messages for all error
 codes
In-Reply-To: <17CVM5b0E1Wt6W1_NIEjNimOxEYJDt4Ii3SzFSt0yxw=.30748f52-c3cd-47f8-b5dd-4bd153413b6d@github.com>
References: <bs8hInqylaWMFKtXQS3DXMJ8f5P4aq-dDiBSSQH2-8E=.ffb1c652-b71d-4dfa-adf0-487f26d40f5e@github.com>
 <17CVM5b0E1Wt6W1_NIEjNimOxEYJDt4Ii3SzFSt0yxw=.30748f52-c3cd-47f8-b5dd-4bd153413b6d@github.com>
Message-ID: <otUv7446WavO8c9QZ7sp4xTZ4YyST88pVlDSAGWJ9LI=.b0398a6e-70d8-4ac6-845e-2e77b8706f0c@github.com>

On Mon, 2 Oct 2023 18:42:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Added 4 missing error codes and removed 2 wrong ones.
>> 
>> KRB_AP_ERR_NOREALM claims itself to be "used in setDefaultCreds() in sun.security.krb5.Credentials" but it's no more.
>> 
>> KRB_AP_ERR_GEN_CRED is used in one place but it's a local error and not meant to be embedded in a message. Therefore safe to be removed.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java line 282:
> 
>> 280:     public static final int KRB_ERR_WRONG_REALM          = 68;   //Wrong realm
>> 281: 
>> 282:     public static final int KRB_CRYPTO_NOT_SUPPORT      = 100;   //Client does not support this crypto type
> 
> Just wondering, and not a specific review comment, but do you know if this error code is necessary? It isn't defined in RFC 4120 and not used in the JDK AFAICT.

Then it's useless. There are several other error codes that are also used nowhere (Ex: `BITSTRING_SIZE_INVALID`). Maybe they were used long time ago, or maybe the original contributor used them in some other places and they had not cleaned up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15892#discussion_r1343092001

From mpowers at openjdk.org  Mon Oct  2 20:15:47 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 20:15:47 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3]
In-Reply-To: <d9_iXOZPRvx3W98fuZN9ihluik_BaXupSR0iehUZzKk=.e6966e2f-4f4d-4369-9951-4e4c2bac05d3@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <d9_iXOZPRvx3W98fuZN9ihluik_BaXupSR0iehUZzKk=.e6966e2f-4f4d-4369-9951-4e4c2bac05d3@github.com>
Message-ID: <AdjURQuw38Xs5jSIiyiOWWCns0lFWwrMBzfm9ZDmY-w=.202cc46a-1dfe-4805-9354-77a42426d631@github.com>

On Mon, 25 Sep 2023 03:40:47 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8315042
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Weijun

@wangweij Thanks for the review - many good comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/15844#issuecomment-1743680267

From mpowers at openjdk.org  Mon Oct  2 20:15:48 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 20:15:48 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3]
In-Reply-To: <oKanr6o0KH9PyZTTrHc1-pn0WeUS2ZYZHShctZVm_rI=.7ccc828a-c20f-41c6-a23c-27d420916d7d@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <d9_iXOZPRvx3W98fuZN9ihluik_BaXupSR0iehUZzKk=.e6966e2f-4f4d-4369-9951-4e4c2bac05d3@github.com>
 <oKanr6o0KH9PyZTTrHc1-pn0WeUS2ZYZHShctZVm_rI=.7ccc828a-c20f-41c6-a23c-27d420916d7d@github.com>
Message-ID: <3GgNXLmzh9rTnNmd3eEE-I9Wh0j6jYgt6Ysar17ohv0=.82842b6f-8918-49ae-9e21-f8f68a2eda93@github.com>

On Mon, 25 Sep 2023 15:29:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment from Weijun
>
> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 27:
> 
>> 25:  * @test
>> 26:  * @library /test/lib
>> 27:  * @bug 5052433 8315042
> 
> Usually we put `@bug` before `@library`.

Fixed.

> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 41:
> 
>> 39:     private static final String in = "MAsGCSqGSMP7TQEHAjI1Bgn///////8wCwUyAQ==";
>> 40: 
>> 41:     public UnexpectedNPE() {}
> 
> Useless constructor.

Removed.

> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 47:
> 
>> 45:         byte[] encoded_2 = { 0x30, 0x01, 0x00, 0x00 };
>> 46:         byte[] encoded_3 = { 0x30, 0x01, 0x00 };
>> 47:         byte[] decodedBytes = Base64.getDecoder().decode(in);
> 
> Maybe rename to `encoded_4`?

Done.

> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 49:
> 
>> 47:         byte[] decodedBytes = Base64.getDecoder().decode(in);
>> 48: 
>> 49:         UnexpectedNPE unpe = new UnexpectedNPE() ;
> 
> Just modify `run` to static. No class instance needed.

Good suggestion.

> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 60:
> 
>> 58:         if (cf == null) {
>> 59:             try {
>> 60:                 cf = CertificateFactory.getInstance("X.509", "SUN");
> 
> Make `cf` static and move the line above to `main`. Or, make it a local variable in `main` and pass it to all `run` calls.

Doing the former.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343103788
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343102818
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343102946
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343102629
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343103415

From mpowers at openjdk.org  Mon Oct  2 20:15:49 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 20:15:49 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3]
In-Reply-To: <jGpDY_7HlkE2QtQMLtFPuwAnxZq8BL2nlDDNRz-_bes=.63aae6f9-553c-47d1-96e6-17687907c9a3@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <d9_iXOZPRvx3W98fuZN9ihluik_BaXupSR0iehUZzKk=.e6966e2f-4f4d-4369-9951-4e4c2bac05d3@github.com>
 <oKanr6o0KH9PyZTTrHc1-pn0WeUS2ZYZHShctZVm_rI=.7ccc828a-c20f-41c6-a23c-27d420916d7d@github.com>
 <kAxnCJrMocddMN90qU8aDf0HAbHTXq69BkKcIwExrf8=.2f6fa6a6-975b-4fac-9f3f-db0bb7b86517@github.com>
 <jGpDY_7HlkE2QtQMLtFPuwAnxZq8BL2nlDDNRz-_bes=.63aae6f9-553c-47d1-96e6-17687907c9a3@github.com>
Message-ID: <KHQwBWsxjqtOtaT5p42bV2uuAHhFsS0X5WqIBJmftRs=.ca820dee-6542-46ef-b059-90ef4a1fd3cc@github.com>

On Mon, 2 Oct 2023 18:04:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't understand.
>
> I mean there is no need to call both `generateCRL` and `generateCRLs`. The original test cases are about basic SEQUENCE encoding, the new test case is about PKCS7 encoding. These can be tested with a single `generateCRLs` call.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343103661

From mullan at openjdk.org  Mon Oct  2 20:42:00 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 2 Oct 2023 20:42:00 GMT
Subject: RFR: 8309667: TLS handshake fails because of
 ConcurrentModificationException in PKCS12KeyStore.engineGetEntry
In-Reply-To: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
Message-ID: <IvYCYyOEMEm9utrh9r6YkR7hVeawRcD9oweTRXN0QZM=.4e66985f-5656-4f3a-8eaa-3626dd48411a@github.com>

On Mon, 25 Sep 2023 18:12:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A different fix after https://github.com/openjdk/jdk/pull/14506 was closed.
> 
> Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later.
> 
> I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate).

Looks good, just one method description improvement suggestion.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1435:

> 1433: 
> 1434:     /*
> 1435:      * Assemble the entry attributes

Perhaps be a bit more specific here - "Populate the entry with additional attributes used by the implementation."

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15909#pullrequestreview-1653405219
PR Review Comment: https://git.openjdk.org/jdk/pull/15909#discussion_r1343099662

From weijun at openjdk.org  Mon Oct  2 20:56:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 20:56:54 GMT
Subject: Integrated: 8316771: Krb5.java has not defined messages for all error
 codes
In-Reply-To: <bs8hInqylaWMFKtXQS3DXMJ8f5P4aq-dDiBSSQH2-8E=.ffb1c652-b71d-4dfa-adf0-487f26d40f5e@github.com>
References: <bs8hInqylaWMFKtXQS3DXMJ8f5P4aq-dDiBSSQH2-8E=.ffb1c652-b71d-4dfa-adf0-487f26d40f5e@github.com>
Message-ID: <_B0rQnKuSQsrQkG4eiSj08K252bPVI0LjUFDVpN1tmw=.7302f720-fd86-4a36-9799-09039a3f7b02@github.com>

On Fri, 22 Sep 2023 20:05:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Added 4 missing error codes and removed 2 wrong ones.
> 
> KRB_AP_ERR_NOREALM claims itself to be "used in setDefaultCreds() in sun.security.krb5.Credentials" but it's no more.
> 
> KRB_AP_ERR_GEN_CRED is used in one place but it's a local error and not meant to be embedded in a message. Therefore safe to be removed.

This pull request has now been integrated.

Changeset: d7d1d42b
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7d1d42b67bcc8e6fe98e936b10e43edfd4989a2
Stats:     79 lines in 3 files changed: 72 ins; 3 del; 4 mod

8316771: Krb5.java has not defined messages for all error codes

Reviewed-by: mullan

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

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

From mpowers at openjdk.org  Mon Oct  2 21:06:58 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 21:06:58 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v4]
In-Reply-To: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
Message-ID: <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>

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

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  more comments from Weijun

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15844/files
  - new: https://git.openjdk.org/jdk/pull/15844/files/b481ec44..369c3356

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

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

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

From weijun at openjdk.org  Mon Oct  2 21:09:27 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 21:09:27 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v4]
In-Reply-To: <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>
Message-ID: <qMTJTItm0_PYcrEm-kM-z3mbhtRAh2UacOq1rVUXl38=.1db00787-f425-4fc8-a3f6-490fcca59731@github.com>

On Mon, 2 Oct 2023 21:06:58 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8315042
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments from Weijun

test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 27:

> 25:  * @test
> 26:  * @bug 5052433 8315042
> 27:  * @summary NullPointerException for generateCRL and generateCRLs methods.

I didn't notice the `@summary` mention both methods. Now I'm not sure which one is better. You can either update this summary to only mention one or revert the code to check both.

test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 47:

> 45:                 "MAsGCSqGSMP7TQEHAjI1Bgn///////8wCwUyAQ==");
> 46: 
> 47:         if (cf == null) {

No need to check `if (cf == null)` or catch any exception. Just leave it uncaught.

test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 67:

> 65:                 () -> cf.generateCRLs(new ByteArrayInputStream(buf)),
> 66:                 CRLException.class);
> 67:         System.out.println("NPE checking passed");

No need to print any message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343158615
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343157583
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343159365

From weijun at openjdk.org  Mon Oct  2 21:18:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 21:18:38 GMT
Subject: RFR: 8309667: TLS handshake fails because of
 ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v2]
In-Reply-To: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
Message-ID: <AwIq8AgzNotDgz54iHftc3YlD2c4R885Rc1AHTP5y0g=.d45f3f01-b111-4f1f-aa8a-7fa3981745ed@github.com>

> A different fix after https://github.com/openjdk/jdk/pull/14506 was closed.
> 
> Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later.
> 
> I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate).

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

  rewrite method comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15909/files
  - new: https://git.openjdk.org/jdk/pull/15909/files/24be313b..71a960b4

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

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

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

From weijun at openjdk.org  Mon Oct  2 21:18:41 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 21:18:41 GMT
Subject: RFR: 8309667: TLS handshake fails because of
 ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v2]
In-Reply-To: <IvYCYyOEMEm9utrh9r6YkR7hVeawRcD9oweTRXN0QZM=.4e66985f-5656-4f3a-8eaa-3626dd48411a@github.com>
References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
 <IvYCYyOEMEm9utrh9r6YkR7hVeawRcD9oweTRXN0QZM=.4e66985f-5656-4f3a-8eaa-3626dd48411a@github.com>
Message-ID: <4YCqoy855XxQQpFUR58nf0deQcIPLURh9ezH9RNoIhs=.b099fcb4-a198-4e11-89b1-beddd6635f32@github.com>

On Mon, 2 Oct 2023 20:00: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:
>> 
>>   rewrite method comment
>
> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1435:
> 
>> 1433: 
>> 1434:     /*
>> 1435:      * Assemble the entry attributes
> 
> Perhaps be a bit more specific here - "Populate the entry with additional attributes used by the implementation."

Will add. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15909#discussion_r1343160611

From weijun at openjdk.org  Mon Oct  2 21:56:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 2 Oct 2023 21:56:11 GMT
Subject: Integrated: 8309667: TLS handshake fails because of
 ConcurrentModificationException in PKCS12KeyStore.engineGetEntry
In-Reply-To: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com>
Message-ID: <KIO6Cnu9ZLBmrfjgDeqearLS8aFJvIq6UhC0ilisKEQ=.5df80acb-755a-43f7-9412-19b0094dff02@github.com>

On Mon, 25 Sep 2023 18:12:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A different fix after https://github.com/openjdk/jdk/pull/14506 was closed.
> 
> Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later.
> 
> I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate).

This pull request has now been integrated.

Changeset: d2e2c4ce
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2e2c4cef1f15a3fc7f1f619470d23ae6bb37725
Stats:     259 lines in 3 files changed: 250 ins; 2 del; 7 mod

8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry

Reviewed-by: djelinski, mullan

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

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

From mpowers at openjdk.org  Mon Oct  2 22:15:15 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 22:15:15 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v5]
In-Reply-To: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
Message-ID: <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>

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

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  a few more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15844/files
  - new: https://git.openjdk.org/jdk/pull/15844/files/369c3356..2fe7e47c

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

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

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

From mpowers at openjdk.org  Mon Oct  2 22:15:19 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 22:15:19 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v4]
In-Reply-To: <qMTJTItm0_PYcrEm-kM-z3mbhtRAh2UacOq1rVUXl38=.1db00787-f425-4fc8-a3f6-490fcca59731@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>
 <qMTJTItm0_PYcrEm-kM-z3mbhtRAh2UacOq1rVUXl38=.1db00787-f425-4fc8-a3f6-490fcca59731@github.com>
Message-ID: <67p3owtlPVvWnrTNtYUDCqNR_SWE6oSxpbawu6AeqjU=.6cfd8f56-11ce-4c3f-ad1c-f1b17cd810a2@github.com>

On Mon, 2 Oct 2023 20:58:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more comments from Weijun
>
> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 5052433 8315042
>> 27:  * @summary NullPointerException for generateCRL and generateCRLs methods.
> 
> I didn't notice the `@summary` mention both methods. Now I'm not sure which one is better. You can either update this summary to only mention one or revert the code to check both.

I'll revert the code to check both.

> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 47:
> 
>> 45:                 "MAsGCSqGSMP7TQEHAjI1Bgn///////8wCwUyAQ==");
>> 46: 
>> 47:         if (cf == null) {
> 
> No need to check `if (cf == null)` or catch any exception. Just leave it uncaught.

Fixed.

> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 67:
> 
>> 65:                 () -> cf.generateCRLs(new ByteArrayInputStream(buf)),
>> 66:                 CRLException.class);
>> 67:         System.out.println("NPE checking passed");
> 
> No need to print any message.

Less is better in my opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343211943
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343211667
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343212046

From valeriep at openjdk.org  Mon Oct  2 22:30:24 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 2 Oct 2023 22:30:24 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v4]
In-Reply-To: <67p3owtlPVvWnrTNtYUDCqNR_SWE6oSxpbawu6AeqjU=.6cfd8f56-11ce-4c3f-ad1c-f1b17cd810a2@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>
 <qMTJTItm0_PYcrEm-kM-z3mbhtRAh2UacOq1rVUXl38=.1db00787-f425-4fc8-a3f6-490fcca59731@github.com>
 <67p3owtlPVvWnrTNtYUDCqNR_SWE6oSxpbawu6AeqjU=.6cfd8f56-11ce-4c3f-ad1c-f1b17cd810a2@github.com>
Message-ID: <tLg5CPxrGrbbKtOWP6t1fA3LznNFJd8evopklnEw-6Q=.95e094a2-fffb-4c2d-9b93-95f8c3993aad@github.com>

On Mon, 2 Oct 2023 22:08:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 5052433 8315042
>>> 27:  * @summary NullPointerException for generateCRL and generateCRLs methods.
>> 
>> I didn't notice the `@summary` mention both methods. Now I'm not sure which one is better. You can either update this summary to only mention one or revert the code to check both.
>
> I'll revert the code to check both.

If we are fixing the summary, can we also elaborate a little more so it's clear that the test is checking for CRLException?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343223009

From valeriep at openjdk.org  Mon Oct  2 22:42:46 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 2 Oct 2023 22:42:46 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v5]
In-Reply-To: <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>
Message-ID: <iiM4zgl2k84zDniYdRTcUujHBdI7l8wwPY4wD-RWiGE=.1ef79ed2-21c0-4b42-a896-ad69ef3868ea@github.com>

On Mon, 2 Oct 2023 22:15:15 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8315042
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a few more comments

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15844#pullrequestreview-1653617622

From mpowers at openjdk.org  Mon Oct  2 22:47:12 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 22:47:12 GMT
Subject: Integrated: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts
In-Reply-To: <T-iHQNDgK_0ABHwc5A25-yUUHxO3OXy85FWkR6SEvsQ=.f053eadd-6b7a-4afd-a1d5-8cdf425d743a@github.com>
References: <T-iHQNDgK_0ABHwc5A25-yUUHxO3OXy85FWkR6SEvsQ=.f053eadd-6b7a-4afd-a1d5-8cdf425d743a@github.com>
Message-ID: <PH-qRgZQTAsRgYOo1jTRxKr_OEYgMHppIme9Ud3V1z4=.cd25d6db-0144-49b0-86dc-8dc3ce4d53c9@github.com>

On Fri, 8 Sep 2023 19:41:47 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 6e1aacdf
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e1aacdfba5a32f7b071eea8039888d275827e83
Stats:     43 lines in 11 files changed: 28 ins; 2 del; 13 mod

8296631: NSS tests failing on OL9 linux-aarch64 hosts

Reviewed-by: valeriep

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

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

From duke at openjdk.org  Mon Oct  2 23:03:47 2023
From: duke at openjdk.org (Ben Perez)
Date: Mon, 2 Oct 2023 23:03:47 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v2]
In-Reply-To: <qejb1KzTVFLuL7GmraLfzXQqaOuFbX1cD10RQgvDVG4=.98cb4730-737c-4e1a-9f97-1368ff0879fc@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <0VHfX_zAjpEHPCWuF3vV6-PaEpSFvU4tmeGo-n3bN9A=.59e15728-a118-4d9b-90b1-060f75fef5c4@github.com>
 <qejb1KzTVFLuL7GmraLfzXQqaOuFbX1cD10RQgvDVG4=.98cb4730-737c-4e1a-9f97-1368ff0879fc@github.com>
Message-ID: <grvbT_6qEiSDLZ0RsSOG5fdWEeTjJfhXZo0z7K2-1rc=.dc11c06c-cd0d-45aa-80e2-0490e1da23e5@github.com>

On Mon, 25 Sep 2023 23:48:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> * Cipher.updateAAD(...) methods also calls checkCipherState(), so its javadoc should be updated as well?

The current documentation for Cipher.updateAAD(...) is:

"@throws IllegalStateException if this {@code Cipher} object is in a wrong state (e.g., has not been initialized), does not accept AAD, or if operating in either GCM or CCM mode and one of the {@code update} methods has already been called for the active encryption/decryption operation"

This seems fairly explicit, but I could change the wording to 

"@throws IllegalStateException if this {@code Cipher} object is in a wrong state (e.g., has not been initialized, or is not in ENCRYPT_MODE or DECRYPT_MODE)"

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

PR Comment: https://git.openjdk.org/jdk/pull/15727#issuecomment-1743888605

From mpowers at openjdk.org  Mon Oct  2 23:14:41 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 2 Oct 2023 23:14:41 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v4]
In-Reply-To: <tLg5CPxrGrbbKtOWP6t1fA3LznNFJd8evopklnEw-6Q=.95e094a2-fffb-4c2d-9b93-95f8c3993aad@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>
 <qMTJTItm0_PYcrEm-kM-z3mbhtRAh2UacOq1rVUXl38=.1db00787-f425-4fc8-a3f6-490fcca59731@github.com>
 <67p3owtlPVvWnrTNtYUDCqNR_SWE6oSxpbawu6AeqjU=.6cfd8f56-11ce-4c3f-ad1c-f1b17cd810a2@github.com>
 <tLg5CPxrGrbbKtOWP6t1fA3LznNFJd8evopklnEw-6Q=.95e094a2-fffb-4c2d-9b93-95f8c3993aad@github.com>
Message-ID: <ry737V-aJhb0t6wY3vIUGfrxNVWsO38kks3-kjYljmM=.fdd9ad18-0dbb-4405-bee1-ca67b03b4db2@github.com>

On Mon, 2 Oct 2023 22:27:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I'll revert the code to check both.
>
> If we are fixing the summary, can we also elaborate a little more so it's clear that the test is checking for CRLException or no NPE is thrown?

What about:
"Verify that generateCRL and generateCRLs methods do not throw a NullPointerException. They should throw a CRLException instead."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1343246734

From valeriep at openjdk.org  Tue Oct  3 00:02:39 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 3 Oct 2023 00:02:39 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v2]
In-Reply-To: <grvbT_6qEiSDLZ0RsSOG5fdWEeTjJfhXZo0z7K2-1rc=.dc11c06c-cd0d-45aa-80e2-0490e1da23e5@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <0VHfX_zAjpEHPCWuF3vV6-PaEpSFvU4tmeGo-n3bN9A=.59e15728-a118-4d9b-90b1-060f75fef5c4@github.com>
 <qejb1KzTVFLuL7GmraLfzXQqaOuFbX1cD10RQgvDVG4=.98cb4730-737c-4e1a-9f97-1368ff0879fc@github.com>
 <grvbT_6qEiSDLZ0RsSOG5fdWEeTjJfhXZo0z7K2-1rc=.dc11c06c-cd0d-45aa-80e2-0490e1da23e5@github.com>
Message-ID: <OtCuOQYwujKMEbe58EA9G8SXwaPj57dn7zwVOq0tU_c=.21153b52-4d56-41d0-89ff-438a82637633@github.com>

On Mon, 2 Oct 2023 23:01:13 GMT, Ben Perez <duke at openjdk.org> wrote:

> > * Cipher.updateAAD(...) methods also calls checkCipherState(), so its javadoc should be updated as well?
> 
> The current documentation for Cipher.updateAAD(...) is:
> 
> "@throws IllegalStateException if this {@code Cipher} object is in a wrong state (e.g., has not been initialized), does not accept AAD, or if operating in either GCM or CCM mode and one of the {@code update} methods has already been called for the active encryption/decryption operation"
> 
> This seems fairly explicit, but I could change the wording to
> 
> "@throws IllegalStateException if this {@code Cipher} object is in a wrong state (e.g., has not been initialized, or is not in ENCRYPT_MODE or DECRYPT_MODE)"

We still need the part of "does not accept AAD, or if operating in either GCM or CCM mode and one of the {@code update} methods has already been called for the active encryption/decryption operation".

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

PR Comment: https://git.openjdk.org/jdk/pull/15727#issuecomment-1743939902

From jwaters at openjdk.org  Tue Oct  3 02:29:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 3 Oct 2023 02:29:28 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v2]
In-Reply-To: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
Message-ID: <mgvNzgvL53NG1nxTLP8rNGLDyU4WywsWXsSaXjC2q1Q=.72ae9368-569a-4631-b705-cede3369d8f0@github.com>

> Prepares java.security.jgss for the permissive- compiler switch by
> 
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Leave out c prefix in sspi.cpp for now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15996/files
  - new: https://git.openjdk.org/jdk/pull/15996/files/58ef97c9..f38d27a0

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

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

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

From jwaters at openjdk.org  Tue Oct  3 02:55:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 3 Oct 2023 02:55:09 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
Message-ID: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>

> Prepares java.security.jgss for the permissive- compiler switch by
> 
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Use split declaration and assignment in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15996/files
  - new: https://git.openjdk.org/jdk/pull/15996/files/f38d27a0..53800fc6

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

  Stats: 225 lines in 1 file changed: 67 ins; 72 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/15996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15996/head:pull/15996

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

From jwaters at openjdk.org  Tue Oct  3 02:55:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 3 Oct 2023 02:55:10 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <f7Vx1tZyNMS_lw8jdIGanWugf7z5jn4q71SOSQSNRTk=.d1159a6e-61ba-49f1-a085-443e3be91add@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>
 <NODu7JqA3zkj2FLmQyT9RsQSS1vViDXjEaq1NvSnFjM=.52daec77-58fc-4b36-b8e4-9e72289246f9@github.com>
 <f7Vx1tZyNMS_lw8jdIGanWugf7z5jn4q71SOSQSNRTk=.d1159a6e-61ba-49f1-a085-443e3be91add@github.com>
Message-ID: <hqYr-H9y8ZVL-6KoL0DNTShD1sZYwUXe9UFWJ7yH7Bw=.2263d582-dee0-40f5-8843-355459d7b62a@github.com>

On Mon, 2 Oct 2023 12:27:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I agree that it's ugly, but at the time I couldn't think of another way to solve the issue. By any chance, why does splitting it out into separate declaration assignment work? Last I remember, it still jumps over the local even when split up like this.
>
> Well, SO offers a speculative answer:
> https://stackoverflow.com/a/14274292
> the modified form is not more safe, but the standard does not forbid it.

I tested the new approach on gcc, it worked, so I'll commit it here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1343396615

From jwaters at openjdk.org  Tue Oct  3 02:55:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 3 Oct 2023 02:55:39 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v2]
In-Reply-To: <mgvNzgvL53NG1nxTLP8rNGLDyU4WywsWXsSaXjC2q1Q=.72ae9368-569a-4631-b705-cede3369d8f0@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <mgvNzgvL53NG1nxTLP8rNGLDyU4WywsWXsSaXjC2q1Q=.72ae9368-569a-4631-b705-cede3369d8f0@github.com>
Message-ID: <qYZSY7Ym3SgTOuM0zto1ADDA1onENOyaIyXKvpU0Yhk=.ddc9ba0d-2fa3-411b-813c-8744b401e011@github.com>

On Tue, 3 Oct 2023 02:29:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leave out c prefix in sspi.cpp for now

@valeriepeng what's your opinion on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/15996#issuecomment-1744080646

From weijun at openjdk.org  Tue Oct  3 14:15:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Oct 2023 14:15:40 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
Message-ID: <l6udE9N-oIc_AkcKBRkyEPek0AWAImJX-UheR9RUKUc=.138d34c0-d4e9-44e8-86da-0451c0cc55a8@github.com>

On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use split declaration and assignment in sspi.cpp

I'm OK with the fix. So separating the declaration and the assignment effectively place all the declarations at the beginning of the block and give them default values?

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

PR Comment: https://git.openjdk.org/jdk/pull/15996#issuecomment-1745066266

From ecaspole at openjdk.org  Tue Oct  3 14:17:37 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 3 Oct 2023 14:17:37 GMT
Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests
 having shared state
In-Reply-To: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
References: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
Message-ID: <etffc4L7rsRX476W6KGi1QDwZFj1qs1KP1CudSsFQhQ=.5c8bd4fc-2801-4b49-a690-1cc04b486434@github.com>

On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma <duke at openjdk.org> wrote:

> In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.
> 
> org/openjdk/bench/java/io/DataInputStreamTest.java
> org/openjdk/bench/java/lang/ArrayClone.java
> org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
> org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
> org/openjdk/bench/java/lang/StringComparisons.java
> org/openjdk/bench/java/lang/StringEquals.java
> org/openjdk/bench/java/lang/StringFormat.java
> org/openjdk/bench/java/lang/StringReplace.java
> org/openjdk/bench/java/lang/StringSubstring.java
> org/openjdk/bench/java/lang/StringTemplateFMT.java
> org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
> org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
> org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
> org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
> org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
> org/openjdk/bench/java/security/CipherSuiteBench.java
> org/openjdk/bench/java/time/GetYearBench.java
> org/openjdk/bench/java/time/InstantBench.java
> org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
> org/openjdk/bench/java/util/ListArgs.java
> org/openjdk/bench/java/util/LocaleDefaults.java
> org/openjdk/bench/java/util/TestAdler32.java
> org/openjdk/bench/java/util/TestCRC32.java
> org/openjdk/bench/java/util/TestCRC32C.java
> org/openjdk/bench/java/util/regex/Exponential.java
> org/openjdk/bench/java/util/regex/Primality.java
> org/openjdk/bench/java/util/regex/Trim.java
> org/openjdk/bench/javax/crypto/AESReinit.java
> org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
> org/openjdk/bench/vm/compiler/Rotation.java
> org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
> org/openjdk/bench/vm/compiler/x86/BasicRules.java
> 
> Please review and provide your feedback.
> 
> Thanks,
> Swati

Looks good, thanks for finding this problem!

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

Marked as reviewed by ecaspole (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15230#pullrequestreview-1655325889

From mdonovan at openjdk.org  Tue Oct  3 14:50:28 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Oct 2023 14:50:28 GMT
Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms
In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
Message-ID: <K5eK7yToHIYLzgbeduxCAV2eQwid8e_D6kX0WP2Emtw=.bf187832-8834-4e66-b6fa-b0458ecc001a@github.com>

On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates the version of NSS to 3.91 and includes aarch64 platforms.
> 
> There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one.

I updated this PR with changes from https://github.com/openjdk/jdk/pull/15644.

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

PR Comment: https://git.openjdk.org/jdk/pull/15429#issuecomment-1745129626

From mdonovan at openjdk.org  Tue Oct  3 14:50:26 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Oct 2023 14:50:26 GMT
Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms [v2]
In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
Message-ID: <NmJtHgT_9jjW38OTdrUt7HuzWzA7YaG8vPvwSlw3VP8=.8e5c9af9-a691-4f15-980d-cb01bb9ba5a3@github.com>

> This PR updates the version of NSS to 3.91 and includes aarch64 platforms.
> 
> There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one.

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

 - Merge branch 'master' into pkcs11-nss-upgrade
 - 8314283: Support for NSS tests on aarch64 platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15429/files
  - new: https://git.openjdk.org/jdk/pull/15429/files/c462b7e7..021b23e4

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

  Stats: 121145 lines in 3305 files changed: 55777 ins; 25113 del; 40255 mod
  Patch: https://git.openjdk.org/jdk/pull/15429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15429/head:pull/15429

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

From duke at openjdk.org  Tue Oct  3 16:04:04 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 3 Oct 2023 16:04:04 GMT
Subject: Integrated: 8314085: Fixing scope from benchmark to thread for JMH
 tests having shared state
In-Reply-To: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
References: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
Message-ID: <eMhHKaJbmpETQcIS_c_huj3W-YkALzNmCfOefcvyEX8=.e2d738b9-3dea-46c4-b657-3a7dc06594c8@github.com>

On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma <duke at openjdk.org> wrote:

> In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.
> 
> org/openjdk/bench/java/io/DataInputStreamTest.java
> org/openjdk/bench/java/lang/ArrayClone.java
> org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
> org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
> org/openjdk/bench/java/lang/StringComparisons.java
> org/openjdk/bench/java/lang/StringEquals.java
> org/openjdk/bench/java/lang/StringFormat.java
> org/openjdk/bench/java/lang/StringReplace.java
> org/openjdk/bench/java/lang/StringSubstring.java
> org/openjdk/bench/java/lang/StringTemplateFMT.java
> org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
> org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
> org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
> org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
> org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
> org/openjdk/bench/java/security/CipherSuiteBench.java
> org/openjdk/bench/java/time/GetYearBench.java
> org/openjdk/bench/java/time/InstantBench.java
> org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
> org/openjdk/bench/java/util/ListArgs.java
> org/openjdk/bench/java/util/LocaleDefaults.java
> org/openjdk/bench/java/util/TestAdler32.java
> org/openjdk/bench/java/util/TestCRC32.java
> org/openjdk/bench/java/util/TestCRC32C.java
> org/openjdk/bench/java/util/regex/Exponential.java
> org/openjdk/bench/java/util/regex/Primality.java
> org/openjdk/bench/java/util/regex/Trim.java
> org/openjdk/bench/javax/crypto/AESReinit.java
> org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
> org/openjdk/bench/vm/compiler/Rotation.java
> org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
> org/openjdk/bench/vm/compiler/x86/BasicRules.java
> 
> Please review and provide your feedback.
> 
> Thanks,
> Swati

This pull request has now been integrated.

Changeset: b438cffd
Author:    Swati Sharma <swati.sharma at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b438cffdb9821fce86d215e452b41810b08b3e71
Stats:     46 lines in 38 files changed: 0 ins; 0 del; 46 mod

8314085: Fixing scope from benchmark to thread for JMH tests having shared state

Co-authored-by: Vladimir Ivanov <vaivanov at openjdk.org>
Reviewed-by: sviswanathan, ecaspole

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

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

From duke at openjdk.org  Tue Oct  3 16:31:57 2023
From: duke at openjdk.org (Ben Perez)
Date: Tue, 3 Oct 2023 16:31:57 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v3]
In-Reply-To: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
Message-ID: <YMPxQT-UerklBSGAzmpAR1B3AoZwgLQW275vdt0o_SY=.19abca86-c9db-4dd0-a4d6-da508ae8cecd@github.com>

> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  Updated doc for updateAAD, fixed copywrite

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15727/files
  - new: https://git.openjdk.org/jdk/pull/15727/files/ce5b77ff..49c729fc

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

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

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

From duke at openjdk.org  Tue Oct  3 16:32:49 2023
From: duke at openjdk.org (Ben Perez)
Date: Tue, 3 Oct 2023 16:32:49 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v2]
In-Reply-To: <qejb1KzTVFLuL7GmraLfzXQqaOuFbX1cD10RQgvDVG4=.98cb4730-737c-4e1a-9f97-1368ff0879fc@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <0VHfX_zAjpEHPCWuF3vV6-PaEpSFvU4tmeGo-n3bN9A=.59e15728-a118-4d9b-90b1-060f75fef5c4@github.com>
 <qejb1KzTVFLuL7GmraLfzXQqaOuFbX1cD10RQgvDVG4=.98cb4730-737c-4e1a-9f97-1368ff0879fc@github.com>
Message-ID: <9o8lDz0euvQg77ZefHF0nq-I3xYrWNLwHznw52vrKc8=.777c8c62-c3c3-4978-bcfc-0c8c259afaa2@github.com>

On Mon, 25 Sep 2023 23:48:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> * Given the current checkCipherState() impl does not check for states for NullCipher objects, do we want to also update the javax.crypto.NullCipher class javadoc to mention that IllegalStateException is not thrown by various methods?

Current documentation is:

"The {@code NullCipher} class is a class that provides an "identity cipher" -- one that does not transform the plain text.  As a consequence, the ciphertext is identical to the plaintext.  All initialization methods do nothing, while the blocksize is set to 1 byte."

Would it be sufficient for me to add "Unlike other ciphers, the {@code NullCipher} will not throw an {@code IllegalStateException} when in an incorrect state."

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

PR Comment: https://git.openjdk.org/jdk/pull/15727#issuecomment-1745321824

From mpowers at openjdk.org  Tue Oct  3 20:26:39 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 3 Oct 2023 20:26:39 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v6]
In-Reply-To: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
Message-ID: <OVLgtbEhTHHBKAy8eSK8usO5JxT1XjUjS7ea32qsuw4=.f39b7e8c-7b6c-4ab8-88f7-5fb83686fdb6@github.com>

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

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  improved @summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15844/files
  - new: https://git.openjdk.org/jdk/pull/15844/files/2fe7e47c..5def33dc

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

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

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

From weijun at openjdk.org  Tue Oct  3 20:26:39 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Oct 2023 20:26:39 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v6]
In-Reply-To: <OVLgtbEhTHHBKAy8eSK8usO5JxT1XjUjS7ea32qsuw4=.f39b7e8c-7b6c-4ab8-88f7-5fb83686fdb6@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <OVLgtbEhTHHBKAy8eSK8usO5JxT1XjUjS7ea32qsuw4=.f39b7e8c-7b6c-4ab8-88f7-5fb83686fdb6@github.com>
Message-ID: <kt0zBV92I_w_TgnuPDnW4YXtITTq0swZds59Beogvo8=.a88b012c-a843-4811-8b40-77635dbcac33@github.com>

On Tue, 3 Oct 2023 19:53:35 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8315042
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved @summary

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15844#pullrequestreview-1655998793

From weijun at openjdk.org  Tue Oct  3 20:26:41 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Oct 2023 20:26:41 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v5]
In-Reply-To: <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>
Message-ID: <bpoM6xzGD9ARYWNyR7iytdMumndh5CLEWShiRbzL-Jc=.4e754b33-0dc8-4f9b-b410-71d1fe19121b@github.com>

On Mon, 2 Oct 2023 22:15:15 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8315042
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a few more comments

No more comment from me. Thanks for the patience.

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

PR Comment: https://git.openjdk.org/jdk/pull/15844#issuecomment-1745616799

From mpowers at openjdk.org  Tue Oct  3 20:26:42 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 3 Oct 2023 20:26:42 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v5]
In-Reply-To: <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <iFaCyXDnB7qsAPpEQ6iyAANoi13HyL6nDHM7UPyT13Y=.89664ee0-e936-43ac-9c3d-c1efeaeb6e9c@github.com>
Message-ID: <TFvwo1rqo96vsu36sNvXO6aQHuIO2izrYNHkceZLckk=.0047e55c-c24c-4c41-994b-d54ade0bf9e8@github.com>

On Mon, 2 Oct 2023 22:15:15 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8315042
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a few more comments

I changed the summary to be more clear. Can everyone approve again? This will be my last change for sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/15844#issuecomment-1745622382

From mpowers at openjdk.org  Tue Oct  3 20:26:45 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 3 Oct 2023 20:26:45 GMT
Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v4]
In-Reply-To: <tLg5CPxrGrbbKtOWP6t1fA3LznNFJd8evopklnEw-6Q=.95e094a2-fffb-4c2d-9b93-95f8c3993aad@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
 <cDn1Pfda0Ii0_XhD7cuFgNqsXFMKXl_Vix0Kbh4yMZU=.35231779-560f-4157-8142-9b31ade75a5b@github.com>
 <qMTJTItm0_PYcrEm-kM-z3mbhtRAh2UacOq1rVUXl38=.1db00787-f425-4fc8-a3f6-490fcca59731@github.com>
 <67p3owtlPVvWnrTNtYUDCqNR_SWE6oSxpbawu6AeqjU=.6cfd8f56-11ce-4c3f-ad1c-f1b17cd810a2@github.com>
 <tLg5CPxrGrbbKtOWP6t1fA3LznNFJd8evopklnEw-6Q=.95e094a2-fffb-4c2d-9b93-95f8c3993aad@github.com>
Message-ID: <YQae448z2umKtdH5-bh80k3fAfU_HXSKnE3xJCQIzbE=.03f7ad6d-fd7d-4b14-ab85-7e82e55bae9e@github.com>

On Mon, 2 Oct 2023 22:27:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I'll revert the code to check both.
>
> If we are fixing the summary, can we also elaborate a little more so it's clear that the test is checking for CRLException or no NPE is thrown?

@valeriepeng I improved the summary a bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1344644487

From duke at openjdk.org  Tue Oct  3 21:13:53 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 3 Oct 2023 21:13:53 GMT
Subject: RFR: 8316964: Security tools should not call System.exit
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <XWLqddqDEpbfqHTBxvcieNwHhyvNyrK-_T1YpKb42Pc=.665d51af-8dd8-4732-98a1-daa6b4ac0a80@github.com>

On Wed, 27 Sep 2023 20:33:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 433:

> 431:             }
> 432:         } catch (ExitException ee) {
> 433:             throw ee;

`ExitException` is?a?private inner?class, so?external?users won?t?be?able to?distinguish?it from?a?regular `Exception` to?extract the?`errorCode`.

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java line 97:

> 95:     }
> 96: 
> 97:     public void run(String[] args) throws ExitException {

Again, leaking?a?`private` `ExitException` from a?`public` method.

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 92:

> 90:     }
> 91: 
> 92:     public void run(String[] args) throws ExitException {

Another `ExitException` leak.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 319:

> 317:                 return;
> 318:             } else {
> 319:                 throw ee;

And?another `ExitException` leak.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1344741198
PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1344742062
PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1344743018
PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1344744211

From weijun at openjdk.org  Tue Oct  3 22:29:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Oct 2023 22:29:48 GMT
Subject: RFR: 8316964: Security tools should not call System.exit
In-Reply-To: <XWLqddqDEpbfqHTBxvcieNwHhyvNyrK-_T1YpKb42Pc=.665d51af-8dd8-4732-98a1-daa6b4ac0a80@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <XWLqddqDEpbfqHTBxvcieNwHhyvNyrK-_T1YpKb42Pc=.665d51af-8dd8-4732-98a1-daa6b4ac0a80@github.com>
Message-ID: <tXyuonzuIw-I0I6C47uePV9Qkzx9HYaTMJGJwA5flD8=.fad0bc49-6bae-4483-98f2-2e31fcab72fd@github.com>

On Tue, 3 Oct 2023 21:06:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 433:
> 
>> 431:             }
>> 432:         } catch (ExitException ee) {
>> 433:             throw ee;
> 
> `ExitException` is?a?private inner?class, so?external?users won?t?be?able to?distinguish?it from?a?regular `Exception` to?extract the?`errorCode`.

Yes, you are right. I should modify `run` to return an integer and make `ExitException` completely internal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1344806434

From mpowers at openjdk.org  Wed Oct  4 00:27:15 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 4 Oct 2023 00:27:15 GMT
Subject: Integrated: JDK-8315042 NPE in PKCS7.parseOldSignedData
In-Reply-To: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
References: <JQGnfSVKMYTG4Ti8BnD7O-rVuSLmGmik0MAIlSvdQYQ=.3275d887-4d1a-46c0-b021-46efa2b17607@github.com>
Message-ID: <KEZerQF_dBFkkrzpz3wdmppwaUZa85TtwCa0JM8DH7M=.88931b57-d031-491a-9c1b-515126937d87@github.com>

On Wed, 20 Sep 2023 15:00:28 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 8c0d026d
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c0d026d0f508e0c896fd28d725915c52d1b689d
Stats:     49 lines in 2 files changed: 11 ins; 20 del; 18 mod

8315042: NPE in PKCS7.parseOldSignedData

Reviewed-by: valeriep, weijun

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

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

From jwaters at openjdk.org  Wed Oct  4 04:10:25 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Oct 2023 04:10:25 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <l6udE9N-oIc_AkcKBRkyEPek0AWAImJX-UheR9RUKUc=.138d34c0-d4e9-44e8-86da-0451c0cc55a8@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
 <l6udE9N-oIc_AkcKBRkyEPek0AWAImJX-UheR9RUKUc=.138d34c0-d4e9-44e8-86da-0451c0cc55a8@github.com>
Message-ID: <-9eTgtvs06ZL1VtfNz0ULcfy-K2zVO12l1T_MbF10fg=.2c97221f-8ce3-4e29-8f2d-ed3b394f4eac@github.com>

On Tue, 3 Oct 2023 14:13:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I'm OK with the fix. So separating the declaration and the assignment effectively place all the declarations at the beginning of the block and give them default values?

It doesn't place them at the start of the block, the difference is goto is allowed to jump over uninitialized locals (declaration without assignment) but not over explicitly initialized ones

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

PR Comment: https://git.openjdk.org/jdk/pull/15996#issuecomment-1746100931

From jwaters at openjdk.org  Wed Oct  4 04:10:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Oct 2023 04:10:26 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <hqYr-H9y8ZVL-6KoL0DNTShD1sZYwUXe9UFWJ7yH7Bw=.2263d582-dee0-40f5-8843-355459d7b62a@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>
 <NODu7JqA3zkj2FLmQyT9RsQSS1vViDXjEaq1NvSnFjM=.52daec77-58fc-4b36-b8e4-9e72289246f9@github.com>
 <f7Vx1tZyNMS_lw8jdIGanWugf7z5jn4q71SOSQSNRTk=.d1159a6e-61ba-49f1-a085-443e3be91add@github.com>
 <hqYr-H9y8ZVL-6KoL0DNTShD1sZYwUXe9UFWJ7yH7Bw=.2263d582-dee0-40f5-8843-355459d7b62a@github.com>
Message-ID: <ZaESFyRhDKycLpetN05SDhWSRVu9WQU4JlZLCO1-2Ds=.3d9e7b05-9889-4356-8e73-dfec715eecc8@github.com>

On Tue, 3 Oct 2023 02:47:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Well, SO offers a speculative answer:
>> https://stackoverflow.com/a/14274292
>> the modified form is not more safe, but the standard does not forbid it.
>
> I tested the new approach on gcc, it worked, so I'll commit it here

I've changed it to use the split approach, but this feels like a hack to me. I wonder if there's a better way of doing this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1345165527

From djelinski at openjdk.org  Wed Oct  4 07:15:45 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 4 Oct 2023 07:15:45 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
Message-ID: <YZuNMfcSA3ocQzlD2Qac7Q-NePBD2z8QS1So1qpLXLI=.634e3cb4-430e-416b-a99f-6df4b1a08795@github.com>

On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use split declaration and assignment in sspi.cpp

LGTM

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15996#pullrequestreview-1656811422

From djelinski at openjdk.org  Wed Oct  4 07:15:46 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 4 Oct 2023 07:15:46 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <ZaESFyRhDKycLpetN05SDhWSRVu9WQU4JlZLCO1-2Ds=.3d9e7b05-9889-4356-8e73-dfec715eecc8@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <ptODptLTTZtzRsJ16nj2pu2jRbpTZ54_TdDhFvEc5BY=.384c9366-b008-4eb2-854e-ee875783c282@github.com>
 <NODu7JqA3zkj2FLmQyT9RsQSS1vViDXjEaq1NvSnFjM=.52daec77-58fc-4b36-b8e4-9e72289246f9@github.com>
 <f7Vx1tZyNMS_lw8jdIGanWugf7z5jn4q71SOSQSNRTk=.d1159a6e-61ba-49f1-a085-443e3be91add@github.com>
 <hqYr-H9y8ZVL-6KoL0DNTShD1sZYwUXe9UFWJ7yH7Bw=.2263d582-dee0-40f5-8843-355459d7b62a@github.com>
 <ZaESFyRhDKycLpetN05SDhWSRVu9WQU4JlZLCO1-2Ds=.3d9e7b05-9889-4356-8e73-dfec715eecc8@github.com>
Message-ID: <kjrAHyRTgfbKMK6hEQN-bDwu3Wjg6oFwQe8cLjgJyeA=.28e6929b-ead7-438d-a701-a5a9d33deb6f@github.com>

On Wed, 4 Oct 2023 04:08:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I tested the new approach on gcc, it worked, so I'll commit it here
>
> I've changed it to use the split approach, but this feels like a hack to me. I wonder if there's a better way of doing this?

well goto was always a hack; less hacky solution would involve splitting the giant function into smaller parts, so that replacing goto with an else block doesn't increase indentation too much. But if it ain't broke...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15996#discussion_r1345304742

From karl.scheibelhofer at gmx.net  Wed Oct  4 08:21:43 2023
From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer)
Date: Wed, 4 Oct 2023 10:21:43 +0200
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
Message-ID: <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>

Hi All,

I would like to contribute my PEM KeyStore implementation to the
OpenJDK, including integration in the OpenJDK source and creating a
pull request.
What is the recommended way to do this?
Who can create a suitable ticket in OpenJDK to document the
enhancement and to track the progress?

What are the requirements for a pull request to get merged?

Best regards

Karl

Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
<karl.scheibelhofer at gmx.net>:
>
> Hi  Tony!
>
> When the PEM API implementation becomes available it would make sense
> to use it inside the PEM Keystore implementation. It will reduce the
> code (the internal classes PemReader und PemWriter may become
> obsolete), but it does not affect the functionality of the PEM
> keystore. Users of the PEM Keystore won't experience a difference.
>
> Let me know when there is something for the PEM API and I will see if
> I can assist.
>
> I would suggest starting with PEM Keystore now and not wait for the
> PEM API, because the time schedule for it seems vague. I would try to
> refactor my current PEM Keystore implementation to integrate in the
> OpenJDK sun.security.provider package. I do not expect any API changes
> or other compatibility issues with existing code. Then consult this
> group for feedback before creating a pull request.
>
> When the PEM API becomes available, rework the PEM Keystore
> implementation to use it internally.
>
> What do you think?
>
> Best regards
>
>   Karl Scheibelhofer
>
> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
> <anthony.scarpino at oracle.com>:
> >
> > There are no doc links yet.
> >
> > Tony
> >
> > On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
> > > Hi Tony,
> > >
> > > The motivation was mostly about reading PEM keys and certificates
> > > generated somewhere else. This is common practice in enterprise
> > > environments I work in. Because corporate key material is subject to
> > > centralized key management, including generation, backup and rollover.
> > > PEM is the format most software products can handle. For Java
> > > applications, having a PEM KeyStore would reduce the often required
> > > additional step of converting PEM key and certificate in a Java
> > > Keystore/PKCS#12.
> > > Even truststores handling is easier with individual PEM certificates
> > > instead of a single PKCS#12 Truststore. Adding or deleting a single
> > > file instead of replacing the complete PKCS#12 store is less error
> > > prone and cleaner to track in version control. The additional benefit
> > > of a MAC in PKCS#12 adds little to no security in most cases.
> > > And being text based, PEM is more version control friendly than binary PKCS#12.
> > >
> > > But to enable sound support of PEM, I also implemented writing PEM
> > > keys and certificates. This way, one can use the JDK keytool to
> > > generate key and certificate signing requests in PEM format. Getting
> > > the certificate from the CA in PEM, one can use PEM throughout the
> > > process.
> > >
> > > Do you have any links or documentation on the PEM API JEP that you mentioned?
> > >
> > > Thank you for your feedback and best regards
> > >
> > >    Karl
> > >
> > > Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
> > > <anthony.scarpino at oracle.com>:
> > >>
> > >> Hi Karl
> > >>
> > >> The keystore is interesting and may have some value.  Was your use case
> > >> mostly reading PEM keys and certificates generated elsewhere for use
> > >> with a particular application, maybe webservers?  Did you see value in
> > >> writing to this keystore from Java?
> > >>
> > >> On the topic of PEM, I hope before the end of the year to have a PEM API
> > >> JEP.  I would be interested in your API feedback from your keystore
> > >> experiences.  I think if this keystore contribution was accepted, it
> > >> should wait so it can use that API.
> > >>
> > >> thanks
> > >>
> > >> Tony
> > >>
> > >>
> > >> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
> > >>> Hi,
> > >>>
> > >>> Working with Java and the JCA KeyStore for decades, I came across
> > >>> many situations where I thought it would be convenient to be
> > >>> able to load private keys and certificates in PEM format directly
> > >>> using the KeyStore API. Without the need to convert them to PKCS#12/JKS.
> > >>>
> > >>> You can find my implementation of a PEM KeyStore in
> > >>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ .
> > >>>
> > >>> I wondered if it would make sense to integrate such an implementation
> > >>> in one of the standard providers of OpenJDK - like the SUN provider.
> > >>> What do you think?
> > >>>
> > >>> Best regards
> > >>>
> > >>>     Karl

From sean.mullan at oracle.com  Wed Oct  4 11:58:39 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 4 Oct 2023 11:58:39 +0000
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
Message-ID: <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>

Hi Karl,

The OpenJDK Developer?s Guide includes a helpful section on Contributing to an OpenJDK Project [1]. I suggest you read through that if you have not already. In particular, have you signed the OCA? I don?t want to review your code/contribution until that is done.

For this particular contribution, I don?t think there has been enough discussion and evaluation from members of the Security project. This would be a fairly major contribution. Keep in mind that a contribution doesn?t mean the work ends there.  There would need to be documentation, tests, and ongoing support for the foreseeable future. We need to think about these aspects every time we add a new feature, so there needs to be a strong motivation for doing it.

Thanks,
Sean

[1] https://openjdk.org/guide/#contributing-to-an-openjdk-project

> On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer <karl.scheibelhofer at gmx.net> wrote:
> 
> Hi All,
> 
> I would like to contribute my PEM KeyStore implementation to the
> OpenJDK, including integration in the OpenJDK source and creating a
> pull request.
> What is the recommended way to do this?
> Who can create a suitable ticket in OpenJDK to document the
> enhancement and to track the progress?
> 
> What are the requirements for a pull request to get merged?
> 
> Best regards
> 
> Karl
> 
> Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
> <karl.scheibelhofer at gmx.net>:
>> 
>> Hi  Tony!
>> 
>> When the PEM API implementation becomes available it would make sense
>> to use it inside the PEM Keystore implementation. It will reduce the
>> code (the internal classes PemReader und PemWriter may become
>> obsolete), but it does not affect the functionality of the PEM
>> keystore. Users of the PEM Keystore won't experience a difference.
>> 
>> Let me know when there is something for the PEM API and I will see if
>> I can assist.
>> 
>> I would suggest starting with PEM Keystore now and not wait for the
>> PEM API, because the time schedule for it seems vague. I would try to
>> refactor my current PEM Keystore implementation to integrate in the
>> OpenJDK sun.security.provider package. I do not expect any API changes
>> or other compatibility issues with existing code. Then consult this
>> group for feedback before creating a pull request.
>> 
>> When the PEM API becomes available, rework the PEM Keystore
>> implementation to use it internally.
>> 
>> What do you think?
>> 
>> Best regards
>> 
>>  Karl Scheibelhofer
>> 
>> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
>> <anthony.scarpino at oracle.com>:
>>> 
>>> There are no doc links yet.
>>> 
>>> Tony
>>> 
>>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
>>>> Hi Tony,
>>>> 
>>>> The motivation was mostly about reading PEM keys and certificates
>>>> generated somewhere else. This is common practice in enterprise
>>>> environments I work in. Because corporate key material is subject to
>>>> centralized key management, including generation, backup and rollover.
>>>> PEM is the format most software products can handle. For Java
>>>> applications, having a PEM KeyStore would reduce the often required
>>>> additional step of converting PEM key and certificate in a Java
>>>> Keystore/PKCS#12.
>>>> Even truststores handling is easier with individual PEM certificates
>>>> instead of a single PKCS#12 Truststore. Adding or deleting a single
>>>> file instead of replacing the complete PKCS#12 store is less error
>>>> prone and cleaner to track in version control. The additional benefit
>>>> of a MAC in PKCS#12 adds little to no security in most cases.
>>>> And being text based, PEM is more version control friendly than binary PKCS#12.
>>>> 
>>>> But to enable sound support of PEM, I also implemented writing PEM
>>>> keys and certificates. This way, one can use the JDK keytool to
>>>> generate key and certificate signing requests in PEM format. Getting
>>>> the certificate from the CA in PEM, one can use PEM throughout the
>>>> process.
>>>> 
>>>> Do you have any links or documentation on the PEM API JEP that you mentioned?
>>>> 
>>>> Thank you for your feedback and best regards
>>>> 
>>>>   Karl
>>>> 
>>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
>>>> <anthony.scarpino at oracle.com>:
>>>>> 
>>>>> Hi Karl
>>>>> 
>>>>> The keystore is interesting and may have some value.  Was your use case
>>>>> mostly reading PEM keys and certificates generated elsewhere for use
>>>>> with a particular application, maybe webservers?  Did you see value in
>>>>> writing to this keystore from Java?
>>>>> 
>>>>> On the topic of PEM, I hope before the end of the year to have a PEM API
>>>>> JEP.  I would be interested in your API feedback from your keystore
>>>>> experiences.  I think if this keystore contribution was accepted, it
>>>>> should wait so it can use that API.
>>>>> 
>>>>> thanks
>>>>> 
>>>>> Tony
>>>>> 
>>>>> 
>>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Working with Java and the JCA KeyStore for decades, I came across
>>>>>> many situations where I thought it would be convenient to be
>>>>>> able to load private keys and certificates in PEM format directly
>>>>>> using the KeyStore API. Without the need to convert them to PKCS#12/JKS.
>>>>>> 
>>>>>> You can find my implementation of a PEM KeyStore in
>>>>>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ .
>>>>>> 
>>>>>> I wondered if it would make sense to integrate such an implementation
>>>>>> in one of the standard providers of OpenJDK - like the SUN provider.
>>>>>> What do you think?
>>>>>> 
>>>>>> Best regards
>>>>>> 
>>>>>>    Karl


From weijun at openjdk.org  Wed Oct  4 13:38:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 4 Oct 2023 13:38:34 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
Message-ID: <1dBHeY8aTscyzalE9AD7DNCCPMd7oaEUckBcdNZuV4M=.1d8e3ce4-5406-41b4-afb7-af95b414da19@github.com>

On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use split declaration and assignment in sspi.cpp

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15996#pullrequestreview-1657555820

From valeriep at openjdk.org  Wed Oct  4 17:33:33 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Oct 2023 17:33:33 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v2]
In-Reply-To: <qYZSY7Ym3SgTOuM0zto1ADDA1onENOyaIyXKvpU0Yhk=.ddc9ba0d-2fa3-411b-813c-8744b401e011@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <mgvNzgvL53NG1nxTLP8rNGLDyU4WywsWXsSaXjC2q1Q=.72ae9368-569a-4631-b705-cede3369d8f0@github.com>
 <qYZSY7Ym3SgTOuM0zto1ADDA1onENOyaIyXKvpU0Yhk=.ddc9ba0d-2fa3-411b-813c-8744b401e011@github.com>
Message-ID: <s9poIBqL26iDBd6sp-ehb1u37IQuYEE7fU3fIPSVJxE=.3db65b45-731e-4e5f-96e6-02c2e9f1ea6f@github.com>

On Tue, 3 Oct 2023 02:50:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> @valeriepeng what's your opinion on this?

Changes look fine to me. Although I wonder if we should add a comment to prevent future modification which re-introduces the old code...

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

PR Comment: https://git.openjdk.org/jdk/pull/15996#issuecomment-1747346566

From duke at openjdk.org  Wed Oct  4 20:45:37 2023
From: duke at openjdk.org (duke)
Date: Wed, 4 Oct 2023 20:45:37 GMT
Subject: Withdrawn: 8311596: Add separate system properties for TLS server and
 client for maximum chain length
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <0oARJpdrCY3Yr23FgUX4MwGmyRQS_fJbp1elEVDy8vs=.0c5cc6c5-7ed4-43cb-8ec6-8fca796c14da@github.com>

On Fri, 4 Aug 2023 17:30:06 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

This pull request has been closed without being integrated.

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

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

From valeriep at openjdk.org  Wed Oct  4 20:47:12 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Oct 2023 20:47:12 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
Message-ID: <Ju-AFQsdqfwiJm3nKLZZP32W4BqWUNkQ544GUBUpFto=.f5688682-2cfa-469c-b29b-3605608410da@github.com>

On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use split declaration and assignment in sspi.cpp

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15996#pullrequestreview-1658453869

From duke at openjdk.org  Wed Oct  4 22:36:57 2023
From: duke at openjdk.org (Ben Perez)
Date: Wed, 4 Oct 2023 22:36:57 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v4]
In-Reply-To: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
Message-ID: <2LdQp-8RYoGcfVTS1BLYfUIhJUAcnH1cmoklGwmdeYI=.ea837d58-34cd-4759-8b6d-22d9a4cebfb2@github.com>

> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  Updated docs for NullCipher to indicate it will not throw and IllegalStateException when calling Cipher methods in bad state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15727/files
  - new: https://git.openjdk.org/jdk/pull/15727/files/49c729fc..8955ffe5

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

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

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

From svkamath at openjdk.org  Thu Oct  5 05:13:19 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 5 Oct 2023 05:13:19 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v3]
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <k2AwuYrOvdE21bPjASiA7-MWMAQyTY2ry7btuUYM9lQ=.fb6fa582-55c3-422f-8568-bc4c424f37c2@github.com>

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Reorganized code as per comments, added new instruction addb

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15410/files
  - new: https://git.openjdk.org/jdk/pull/15410/files/2727c199..c92f98ab

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

  Stats: 663 lines in 5 files changed: 32 ins; 507 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/15410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15410/head:pull/15410

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

From karl.scheibelhofer at gmx.net  Thu Oct  5 06:48:37 2023
From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer)
Date: Thu, 5 Oct 2023 08:48:37 +0200
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
 <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
Message-ID: <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>

Hi Sean,

Yes, I had a look at the Contributing docs at the OpenJDK site before. I
also signed the OCA.

Honestly, I thought there would be some more reaction on the suggested PEM
KeyStore. It would really be good to discuss the topic with others. Is
there anything we can do to get others in sharing their thoughts on this?

There is already a fair amount of documentation und unit tests. See
https://github.com/KarlScheibelhofer/java-crypto-tools/ .

Best regards,
Karl

On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mullan at oracle.com> wrote:

> Hi Karl,
>
> The OpenJDK Developer?s Guide includes a helpful section on Contributing
> to an OpenJDK Project [1]. I suggest you read through that if you have not
> already. In particular, have you signed the OCA? I don?t want to review
> your code/contribution until that is done.
>
> For this particular contribution, I don?t think there has been enough
> discussion and evaluation from members of the Security project. This would
> be a fairly major contribution. Keep in mind that a contribution doesn?t
> mean the work ends there.  There would need to be documentation, tests, and
> ongoing support for the foreseeable future. We need to think about these
> aspects every time we add a new feature, so there needs to be a strong
> motivation for doing it.
>
> Thanks,
> Sean
>
> [1] https://openjdk.org/guide/#contributing-to-an-openjdk-project
>
> > On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer <
> karl.scheibelhofer at gmx.net> wrote:
> >
> > Hi All,
> >
> > I would like to contribute my PEM KeyStore implementation to the
> > OpenJDK, including integration in the OpenJDK source and creating a
> > pull request.
> > What is the recommended way to do this?
> > Who can create a suitable ticket in OpenJDK to document the
> > enhancement and to track the progress?
> >
> > What are the requirements for a pull request to get merged?
> >
> > Best regards
> >
> > Karl
> >
> > Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
> > <karl.scheibelhofer at gmx.net>:
> >>
> >> Hi  Tony!
> >>
> >> When the PEM API implementation becomes available it would make sense
> >> to use it inside the PEM Keystore implementation. It will reduce the
> >> code (the internal classes PemReader und PemWriter may become
> >> obsolete), but it does not affect the functionality of the PEM
> >> keystore. Users of the PEM Keystore won't experience a difference.
> >>
> >> Let me know when there is something for the PEM API and I will see if
> >> I can assist.
> >>
> >> I would suggest starting with PEM Keystore now and not wait for the
> >> PEM API, because the time schedule for it seems vague. I would try to
> >> refactor my current PEM Keystore implementation to integrate in the
> >> OpenJDK sun.security.provider package. I do not expect any API changes
> >> or other compatibility issues with existing code. Then consult this
> >> group for feedback before creating a pull request.
> >>
> >> When the PEM API becomes available, rework the PEM Keystore
> >> implementation to use it internally.
> >>
> >> What do you think?
> >>
> >> Best regards
> >>
> >>  Karl Scheibelhofer
> >>
> >> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
> >> <anthony.scarpino at oracle.com>:
> >>>
> >>> There are no doc links yet.
> >>>
> >>> Tony
> >>>
> >>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
> >>>> Hi Tony,
> >>>>
> >>>> The motivation was mostly about reading PEM keys and certificates
> >>>> generated somewhere else. This is common practice in enterprise
> >>>> environments I work in. Because corporate key material is subject to
> >>>> centralized key management, including generation, backup and rollover.
> >>>> PEM is the format most software products can handle. For Java
> >>>> applications, having a PEM KeyStore would reduce the often required
> >>>> additional step of converting PEM key and certificate in a Java
> >>>> Keystore/PKCS#12.
> >>>> Even truststores handling is easier with individual PEM certificates
> >>>> instead of a single PKCS#12 Truststore. Adding or deleting a single
> >>>> file instead of replacing the complete PKCS#12 store is less error
> >>>> prone and cleaner to track in version control. The additional benefit
> >>>> of a MAC in PKCS#12 adds little to no security in most cases.
> >>>> And being text based, PEM is more version control friendly than
> binary PKCS#12.
> >>>>
> >>>> But to enable sound support of PEM, I also implemented writing PEM
> >>>> keys and certificates. This way, one can use the JDK keytool to
> >>>> generate key and certificate signing requests in PEM format. Getting
> >>>> the certificate from the CA in PEM, one can use PEM throughout the
> >>>> process.
> >>>>
> >>>> Do you have any links or documentation on the PEM API JEP that you
> mentioned?
> >>>>
> >>>> Thank you for your feedback and best regards
> >>>>
> >>>>   Karl
> >>>>
> >>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
> >>>> <anthony.scarpino at oracle.com>:
> >>>>>
> >>>>> Hi Karl
> >>>>>
> >>>>> The keystore is interesting and may have some value.  Was your use
> case
> >>>>> mostly reading PEM keys and certificates generated elsewhere for use
> >>>>> with a particular application, maybe webservers?  Did you see value
> in
> >>>>> writing to this keystore from Java?
> >>>>>
> >>>>> On the topic of PEM, I hope before the end of the year to have a PEM
> API
> >>>>> JEP.  I would be interested in your API feedback from your keystore
> >>>>> experiences.  I think if this keystore contribution was accepted, it
> >>>>> should wait so it can use that API.
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>> Tony
> >>>>>
> >>>>>
> >>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Working with Java and the JCA KeyStore for decades, I came across
> >>>>>> many situations where I thought it would be convenient to be
> >>>>>> able to load private keys and certificates in PEM format directly
> >>>>>> using the KeyStore API. Without the need to convert them to
> PKCS#12/JKS.
> >>>>>>
> >>>>>> You can find my implementation of a PEM KeyStore in
> >>>>>>
> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$
> .
> >>>>>>
> >>>>>> I wondered if it would make sense to integrate such an
> implementation
> >>>>>> in one of the standard providers of OpenJDK - like the SUN provider.
> >>>>>> What do you think?
> >>>>>>
> >>>>>> Best regards
> >>>>>>
> >>>>>>    Karl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231005/82fa1ce3/attachment.htm>

From djelinski at openjdk.org  Thu Oct  5 07:15:16 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 5 Oct 2023 07:15:16 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v3]
In-Reply-To: <k2AwuYrOvdE21bPjASiA7-MWMAQyTY2ry7btuUYM9lQ=.fb6fa582-55c3-422f-8568-bc4c424f37c2@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <k2AwuYrOvdE21bPjASiA7-MWMAQyTY2ry7btuUYM9lQ=.fb6fa582-55c3-422f-8568-bc4c424f37c2@github.com>
Message-ID: <Yw7jdZTuaSGyl3rh7FDcE-978UNczOL4_uBoBnqT2Zo=.53a6481e-bc3a-4a0e-8b2f-ce36b621fe8b@github.com>

On Thu, 5 Oct 2023 05:13:19 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganized code as per comments, added new instruction addb

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 353:

> 351: 
> 352:   // Save rbp and rsp
> 353:   __ push(rbp);

Why do you push rbp here? `__ enter` above is an alias for `push rbp; mov rbp, rsp`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1346906924

From sean.mullan at oracle.com  Thu Oct  5 13:41:53 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 5 Oct 2023 13:41:53 +0000
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
 <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
 <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>
Message-ID: <A6282C7A-270C-48B5-BA36-87A54D6FF2A0@oracle.com>



On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer <karl.scheibelhofer at gmx.net<mailto:karl.scheibelhofer at gmx.net>> wrote:

Hi Sean,

Yes, I had a look at the Contributing docs at the OpenJDK site before. I also signed the OCA.

Great, thanks.


Honestly, I thought there would be some more reaction on the suggested PEM KeyStore. It would really be good to discuss the topic with others. Is there anything we can do to get others in sharing their thoughts on this?

I think there is a fair amount of interest in it, but reviewing something significant like this takes a bit of time, as I mentioned in my prior email. Also, if we do decide to accept the contribution, we want to make sure it works well with the PEM API that we are working on - we hope to have a draft of a JEP for that out in the next few weeks. So I think we probably need a few weeks to review your contribution.


There is already a fair amount of documentation und unit tests. See https://github.com/KarlScheibelhofer/java-crypto-tools/ .

Ok.

?Sean


Best regards,
Karl

On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mullan at oracle.com<mailto:sean.mullan at oracle.com>> wrote:
Hi Karl,

The OpenJDK Developer?s Guide includes a helpful section on Contributing to an OpenJDK Project [1]. I suggest you read through that if you have not already. In particular, have you signed the OCA? I don?t want to review your code/contribution until that is done.

For this particular contribution, I don?t think there has been enough discussion and evaluation from members of the Security project. This would be a fairly major contribution. Keep in mind that a contribution doesn?t mean the work ends there.  There would need to be documentation, tests, and ongoing support for the foreseeable future. We need to think about these aspects every time we add a new feature, so there needs to be a strong motivation for doing it.

Thanks,
Sean

[1] https://openjdk.org/guide/#contributing-to-an-openjdk-project

> On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer <karl.scheibelhofer at gmx.net<mailto:karl.scheibelhofer at gmx.net>> wrote:
>
> Hi All,
>
> I would like to contribute my PEM KeyStore implementation to the
> OpenJDK, including integration in the OpenJDK source and creating a
> pull request.
> What is the recommended way to do this?
> Who can create a suitable ticket in OpenJDK to document the
> enhancement and to track the progress?
>
> What are the requirements for a pull request to get merged?
>
> Best regards
>
> Karl
>
> Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
> <karl.scheibelhofer at gmx.net<mailto:karl.scheibelhofer at gmx.net>>:
>>
>> Hi  Tony!
>>
>> When the PEM API implementation becomes available it would make sense
>> to use it inside the PEM Keystore implementation. It will reduce the
>> code (the internal classes PemReader und PemWriter may become
>> obsolete), but it does not affect the functionality of the PEM
>> keystore. Users of the PEM Keystore won't experience a difference.
>>
>> Let me know when there is something for the PEM API and I will see if
>> I can assist.
>>
>> I would suggest starting with PEM Keystore now and not wait for the
>> PEM API, because the time schedule for it seems vague. I would try to
>> refactor my current PEM Keystore implementation to integrate in the
>> OpenJDK sun.security.provider package. I do not expect any API changes
>> or other compatibility issues with existing code. Then consult this
>> group for feedback before creating a pull request.
>>
>> When the PEM API becomes available, rework the PEM Keystore
>> implementation to use it internally.
>>
>> What do you think?
>>
>> Best regards
>>
>>  Karl Scheibelhofer
>>
>> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
>> <anthony.scarpino at oracle.com<mailto:anthony.scarpino at oracle.com>>:
>>>
>>> There are no doc links yet.
>>>
>>> Tony
>>>
>>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
>>>> Hi Tony,
>>>>
>>>> The motivation was mostly about reading PEM keys and certificates
>>>> generated somewhere else. This is common practice in enterprise
>>>> environments I work in. Because corporate key material is subject to
>>>> centralized key management, including generation, backup and rollover.
>>>> PEM is the format most software products can handle. For Java
>>>> applications, having a PEM KeyStore would reduce the often required
>>>> additional step of converting PEM key and certificate in a Java
>>>> Keystore/PKCS#12.
>>>> Even truststores handling is easier with individual PEM certificates
>>>> instead of a single PKCS#12 Truststore. Adding or deleting a single
>>>> file instead of replacing the complete PKCS#12 store is less error
>>>> prone and cleaner to track in version control. The additional benefit
>>>> of a MAC in PKCS#12 adds little to no security in most cases.
>>>> And being text based, PEM is more version control friendly than binary PKCS#12.
>>>>
>>>> But to enable sound support of PEM, I also implemented writing PEM
>>>> keys and certificates. This way, one can use the JDK keytool to
>>>> generate key and certificate signing requests in PEM format. Getting
>>>> the certificate from the CA in PEM, one can use PEM throughout the
>>>> process.
>>>>
>>>> Do you have any links or documentation on the PEM API JEP that you mentioned?
>>>>
>>>> Thank you for your feedback and best regards
>>>>
>>>>   Karl
>>>>
>>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
>>>> <anthony.scarpino at oracle.com<mailto:anthony.scarpino at oracle.com>>:
>>>>>
>>>>> Hi Karl
>>>>>
>>>>> The keystore is interesting and may have some value.  Was your use case
>>>>> mostly reading PEM keys and certificates generated elsewhere for use
>>>>> with a particular application, maybe webservers?  Did you see value in
>>>>> writing to this keystore from Java?
>>>>>
>>>>> On the topic of PEM, I hope before the end of the year to have a PEM API
>>>>> JEP.  I would be interested in your API feedback from your keystore
>>>>> experiences.  I think if this keystore contribution was accepted, it
>>>>> should wait so it can use that API.
>>>>>
>>>>> thanks
>>>>>
>>>>> Tony
>>>>>
>>>>>
>>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Working with Java and the JCA KeyStore for decades, I came across
>>>>>> many situations where I thought it would be convenient to be
>>>>>> able to load private keys and certificates in PEM format directly
>>>>>> using the KeyStore API. Without the need to convert them to PKCS#12/JKS.
>>>>>>
>>>>>> You can find my implementation of a PEM KeyStore in
>>>>>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ .
>>>>>>
>>>>>> I wondered if it would make sense to integrate such an implementation
>>>>>> in one of the standard providers of OpenJDK - like the SUN provider.
>>>>>> What do you think?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>>    Karl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231005/eb095db2/attachment-0001.htm>

From mullan at openjdk.org  Thu Oct  5 14:55:30 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Oct 2023 14:55:30 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v4]
In-Reply-To: <2LdQp-8RYoGcfVTS1BLYfUIhJUAcnH1cmoklGwmdeYI=.ea837d58-34cd-4759-8b6d-22d9a4cebfb2@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <2LdQp-8RYoGcfVTS1BLYfUIhJUAcnH1cmoklGwmdeYI=.ea837d58-34cd-4759-8b6d-22d9a4cebfb2@github.com>
Message-ID: <PuZq4YqVHbB57Vo7yG898rPOayE9uTOd8xd8onT2fN8=.9e28c87e-d88d-40cd-bd57-b283de13e320@github.com>

On Wed, 4 Oct 2023 22:36:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated docs for NullCipher to indicate it will not throw and IllegalStateException when calling Cipher methods in bad state

Changes requested by mullan (Reviewer).

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

> 1853:      * @throws IllegalStateException if this {@code Cipher} object is in a
> 1854:      * wrong state (e.g., has not been initialized, or is not
> 1855:      * in ENCRYPT_MODE or DECRYPT_MODE)

Use code format when referencing the modes, ex: change this line to:

`* in {@code ENCRYPT_MODE} or {@code DECRYPT_MODE})`

Same comment applies to all other applicable lines below.

src/java.base/share/classes/javax/crypto/NullCipher.java line 35:

> 33:  * byte.  Unlike other ciphers, the {@code NullCipher} will not throw an
> 34:  * {@code IllegalStateException} when calling {@code Cipher} methods
> 35:  * in an incorrect state.

Suggest rewording last part as "... when {@code Cipher} methods are called in an incorrect state." I also think we should say a NullCipher has no state. So how about:

"Unlike other ciphers, the {@code NullCipher} has no state, and will not throw an {@code IllegalStateException} when {@code Cipher} methods are called in an incorrect state."

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

PR Review: https://git.openjdk.org/jdk/pull/15727#pullrequestreview-1660017070
PR Review Comment: https://git.openjdk.org/jdk/pull/15727#discussion_r1347514833
PR Review Comment: https://git.openjdk.org/jdk/pull/15727#discussion_r1347520301

From duke at openjdk.org  Thu Oct  5 15:20:26 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 5 Oct 2023 15:20:26 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v4]
In-Reply-To: <PuZq4YqVHbB57Vo7yG898rPOayE9uTOd8xd8onT2fN8=.9e28c87e-d88d-40cd-bd57-b283de13e320@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <2LdQp-8RYoGcfVTS1BLYfUIhJUAcnH1cmoklGwmdeYI=.ea837d58-34cd-4759-8b6d-22d9a4cebfb2@github.com>
 <PuZq4YqVHbB57Vo7yG898rPOayE9uTOd8xd8onT2fN8=.9e28c87e-d88d-40cd-bd57-b283de13e320@github.com>
Message-ID: <EwW6S6uCu195HFfdz9NZWhpavaf5a6f6bh7CXvTjc9Y=.b87152c8-c9ec-4106-a639-bf71841a4e0a@github.com>

On Thu, 5 Oct 2023 14:29:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated docs for NullCipher to indicate it will not throw and IllegalStateException when calling Cipher methods in bad state
>
> src/java.base/share/classes/javax/crypto/NullCipher.java line 35:
> 
>> 33:  * byte.  Unlike other ciphers, the {@code NullCipher} will not throw an
>> 34:  * {@code IllegalStateException} when calling {@code Cipher} methods
>> 35:  * in an incorrect state.
> 
> Suggest rewording last part as "... when {@code Cipher} methods are called in an incorrect state." I also think we should say a NullCipher has no state. So how about:
> 
> "Unlike other ciphers, the {@code NullCipher} has no state, and will not throw an {@code IllegalStateException} when {@code Cipher} methods are called in an incorrect state."

Well, if it has no state it cannot be in an incorrect state so the " in an incorrect state" part can be omitted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15727#discussion_r1347596323

From mullan at openjdk.org  Thu Oct  5 17:04:22 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Oct 2023 17:04:22 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v4]
In-Reply-To: <EwW6S6uCu195HFfdz9NZWhpavaf5a6f6bh7CXvTjc9Y=.b87152c8-c9ec-4106-a639-bf71841a4e0a@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <2LdQp-8RYoGcfVTS1BLYfUIhJUAcnH1cmoklGwmdeYI=.ea837d58-34cd-4759-8b6d-22d9a4cebfb2@github.com>
 <PuZq4YqVHbB57Vo7yG898rPOayE9uTOd8xd8onT2fN8=.9e28c87e-d88d-40cd-bd57-b283de13e320@github.com>
 <EwW6S6uCu195HFfdz9NZWhpavaf5a6f6bh7CXvTjc9Y=.b87152c8-c9ec-4106-a639-bf71841a4e0a@github.com>
Message-ID: <UrjqWnoIZjq3rGyVQpm2g6RzfNGeyAZu82hDUMNeZCg=.b2fee66c-9113-4c8f-9110-b7aec82f1999@github.com>

On Thu, 5 Oct 2023 15:17:51 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/NullCipher.java line 35:
>> 
>>> 33:  * byte.  Unlike other ciphers, the {@code NullCipher} will not throw an
>>> 34:  * {@code IllegalStateException} when calling {@code Cipher} methods
>>> 35:  * in an incorrect state.
>> 
>> Suggest rewording last part as "... when {@code Cipher} methods are called in an incorrect state." I also think we should say a NullCipher has no state. So how about:
>> 
>> "Unlike other ciphers, the {@code NullCipher} has no state, and will not throw an {@code IllegalStateException} when {@code Cipher} methods are called in an incorrect state."
>
> Well, if it has no state it cannot be in an incorrect state so the " in an incorrect state" part can be omitted.

Good point!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15727#discussion_r1347732731

From duke at openjdk.org  Thu Oct  5 17:28:46 2023
From: duke at openjdk.org (Ben Perez)
Date: Thu, 5 Oct 2023 17:28:46 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v5]
In-Reply-To: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
Message-ID: <Hxn-MXKNF6UoqCJBI6bBt1LgApq2_cs8pcaZ5uxqmDs=.ed9601ca-7403-42d2-8b43-76719be23ac4@github.com>

> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  Wording change for NullCipher doc, added @code tags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15727/files
  - new: https://git.openjdk.org/jdk/pull/15727/files/8955ffe5..201275d0

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

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

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

From mullan at openjdk.org  Thu Oct  5 18:09:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Oct 2023 18:09:36 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v5]
In-Reply-To: <Hxn-MXKNF6UoqCJBI6bBt1LgApq2_cs8pcaZ5uxqmDs=.ed9601ca-7403-42d2-8b43-76719be23ac4@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <Hxn-MXKNF6UoqCJBI6bBt1LgApq2_cs8pcaZ5uxqmDs=.ed9601ca-7403-42d2-8b43-76719be23ac4@github.com>
Message-ID: <Yx5xY_Jk5drMyPN3UNwXJp1xR9pkJ3p7rzF4D7nN64I=.09b728c0-2b47-4ff3-aafe-11a4d3ab236e@github.com>

On Thu, 5 Oct 2023 17:28:46 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording change for NullCipher doc, added @code tags

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15727#pullrequestreview-1660441831

From valeriep at openjdk.org  Thu Oct  5 19:43:01 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 5 Oct 2023 19:43:01 GMT
Subject: RFR: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal [v5]
In-Reply-To: <Hxn-MXKNF6UoqCJBI6bBt1LgApq2_cs8pcaZ5uxqmDs=.ed9601ca-7403-42d2-8b43-76719be23ac4@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
 <Hxn-MXKNF6UoqCJBI6bBt1LgApq2_cs8pcaZ5uxqmDs=.ed9601ca-7403-42d2-8b43-76719be23ac4@github.com>
Message-ID: <J3gQ4FWMmtNfKduTqX-jVKU6pEK_VKXHKk6DTCo_lkM=.429d0c40-c794-43bd-b19c-dd7628190f85@github.com>

On Thu, 5 Oct 2023 17:28:46 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording change for NullCipher doc, added @code tags

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15727#pullrequestreview-1660586676

From duke at openjdk.org  Fri Oct  6 03:10:16 2023
From: duke at openjdk.org (Ben Perez)
Date: Fri, 6 Oct 2023 03:10:16 GMT
Subject: Integrated: 4964430: (spec) missing IllegalStateException exception
 requirement for javax.crypto.Cipher.doFinal
In-Reply-To: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com>
Message-ID: <W1bEY7fOl8qZTS4ibVRRF-XjenZncJJUw-KEYkQhGd8=.a3dfe3f2-7d00-4add-b999-45de396a86c4@github.com>

On Wed, 13 Sep 2023 18:08:35 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap`

This pull request has now been integrated.

Changeset: 991ce84e
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/991ce84e0984414386e2f4dcefecf8da14cc1db3
Stats:     49 lines in 2 files changed: 17 ins; 0 del; 32 mod

4964430: (spec) missing IllegalStateException exception requirement for javax.crypto.Cipher.doFinal

Reviewed-by: mullan, valeriep

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

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

From djelinski at openjdk.org  Fri Oct  6 07:59:18 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 6 Oct 2023 07:59:18 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v3]
In-Reply-To: <k2AwuYrOvdE21bPjASiA7-MWMAQyTY2ry7btuUYM9lQ=.fb6fa582-55c3-422f-8568-bc4c424f37c2@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <k2AwuYrOvdE21bPjASiA7-MWMAQyTY2ry7btuUYM9lQ=.fb6fa582-55c3-422f-8568-bc4c424f37c2@github.com>
Message-ID: <AQQSHEf3S-WutS4761cobtgC-71Q76MgaGq1DlLmhdY=.6f316ff4-0879-429a-8dbf-f82af168819a@github.com>

On Thu, 5 Oct 2023 05:13:19 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganized code as per comments, added new instruction addb

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 354:

> 352:   // Save rbp and rsp
> 353:   __ push(rbp);
> 354:   __ movq(rbp, rsp);

This line breaks stack walking code, at least on Linux; rbp is supposed to be the frame pointer throughout the stub.

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 362:

> 360:   __ vzeroupper();
> 361:   __ movq(rsp, rbp);
> 362:   __ pop(rbp);

If you remove `movq(rbp, rsp)` above, you can replace this with:
Suggestion:

  __ lea(rsp, Address (rbp, WINDOWS_ONLY(-7) NOT_WINDOWS(-5) * wordSize));

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3342:

> 3340:   __ movdqu(xmm1, xmm2);
> 3341:   __ vpslldq(xmm2, xmm2, 8, Assembler::AVX_128bit);
> 3342:   __ vpsrldq(xmm1, xmm1, 8, Assembler::AVX_128bit);

You could save a few bytes here:
Suggestion:

  __ vpsrlq(xmm1, xmm6, 63, Assembler::AVX_128bit);
  __ vpsllq(xmm6, xmm6, 1, Assembler::AVX_128bit);
  __ vpslldq(xmm2, xmm1, 8, Assembler::AVX_128bit);
  __ vpsrldq(xmm1, xmm1, 8, Assembler::AVX_128bit);

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3710:

> 3708: 
> 3709:   // Generate 8 constants for htbl
> 3710:   __ call(generate_htbl_8_blks, relocInfo::none);

why didn't you inline `generateHtbl_8_block_avx2` here? This method is only used here as far as I can tell.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1348346370
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1348347451
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1348372462
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1348349329

From mbalao at redhat.com  Fri Oct  6 16:55:53 2023
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 6 Oct 2023 12:55:53 -0400
Subject: [External] : Re: RFD: Services lockdown for security providers
In-Reply-To: <dc1c22ab-b130-364f-d7d2-880d899a5184@oracle.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
 <4b159d35-ee2e-952d-8e22-c035e5ed17ea@oracle.com>
 <1a0ad927-2da8-c881-a80f-b4928341375f@redhat.com>
 <d7a607e0-7acc-1929-7464-a70ceb6d7c91@oracle.com>
 <7c07a7b1-6c68-9534-59e1-1813439d7f47@redhat.com>
 <85e89abd-eac3-87df-9e4b-1fa2c36a6286@oracle.com>
 <CAKZz+geGA3Hs4jV8AFTKPrehiquXWbiA9BvPVFPSaWzLVsn6Rw@mail.gmail.com>
 <dc1c22ab-b130-364f-d7d2-880d899a5184@oracle.com>
Message-ID: <9c212429-6045-5b0a-c6b0-6370488039b1@redhat.com>

Hi Tony,

Thanks for having a look at our proposal.

The main motivation for this enhancement is related to cryptographic 
policy enforcement and, in particular, the following capabilities: 1) 
enforcing that cryptographic services are provided by chosen security 
providers only, and 2) allowing or disallowing selected algorithms or 
service types across all Java Security APIs.

None of this is entirely new. In regards to capability #1, users can 
install or uninstall security providers already, or rely on priorities 
and algorithms shadowing. However, we deem this insufficient for the 
purposes of policy enforcement, lacking in flexibility, and at risk of 
introducing dependencies on implementation details. Some more details 
are provided under the section "What is the current limitation?" of the 
8315487 ticket [1]. As for capability #2, there is partial support 
currently: algorithms can be blocked from TLS or certificate paths 
validation uses but not across all JCA APIs. Thus, we share some of the 
motivations that led to existing features but intend to have a more 
powerful, comprehensive and flexible solution. As documented in our 
proposal, both solutions were combined in a multi-layer model.

The FIPS case is interesting because it requires a combination of 
capabilities #1 and #2. However, there are other cases that could 
benefit from different policies. I have described some of them below, 
providing a summary rationale for why a user might want to adopt the 
given policy, a filter conforming to the proposal that would achieve the 
desired outcome, and a comparison with how the same outcome might be met 
(or potentially be hard/impossible to meet) with the status quo. See 
Appendix #1.

As with most security properties, a specific configuration may render an 
application completely or partially unusable, and require a 
sysadmin/developer/security-expert to perform an assessment. This effect 
may be a desired outcome and trigger a remediation action. Other 
applications may react in a more resilient way and smoothly adapt to the 
policy enforced: use cryptography from an allowed security provider, 
skip the use of algorithms that are not allowed, ask the user to take 
action, etc. Our concern is that the lack of strong policy enforcement 
capabilities may lead to non-compliance issues going unnoticed.

Existing security capabilities such as the one to install or uninstall 
security providers, or even the one that allows to select preference per 
algorithm, require the knowledge of what these security providers 
implement and what applications require to use. Our proposal allows 
better granularity but is not different in terms of relying on public 
documentation or sysadmin/developer/security-expert knowledge.

While we don't necessarily share the view of the syntax as hard to use 
or error-prone, we concede that it leans more towards the expert UI side 
of all security properties. We designed the syntax with the ideas of 
consistency, similarity to the serialization filter ?to the extent 
possible?, simplicity for trivial cases and powerfulness for complex 
ones. We want to make sure that it's not only tailored to our needs 
today but generic enough for other current or future uses. We tried to 
explain the use cases and desirable properties underneath the proposed 
design, but at the same time we would like to know if there is any 
aspect in particular that is of your concern and if you have any 
improvements to suggest so it's more accessible to less experienced 
users. We are open to considering specification, implementation and/or 
documentation changes.

Thanks,
Martin.-

--

Appendix #1

1) A policy that only authorizes the storage of certificates and keys in 
PKCS #11 devices, or in a specific instance managed by the 
CentralKeysProvider security provider:

*.KeyStore.PKCS11; !*.KeyStore; *

or

CentralKeysProvider.KeyStore; !*.KeyStore; *

In this scenario, a system administrator is concerned about how 
applications store sensitive cryptographic keys and intends to enforce a 
centralized or more restricted management. This policy aims to mitigate 
security risks and drawbacks associated with local file-based key 
storage. In the event of a key update, if centralized management is 
applied, applications have access to the latest key without any key 
population hassle. While this policy imposes restrictions on key 
storage, any security provider (including OpenJDK default ones) can use 
these keys after retrieval. This latter observation is relevant when, 
for example, PKCS #11 token devices with limited performance or 
algorithms availability are used.

We deem this type of policy useful for scenarios where centralized key 
management is feasible and desirable, or scenarios where keys are stored 
in hardware devices.

Enforcing this policy without the Security Provider Filter would be 
hard. While changing the default key store type by means of the 
keystore.type security property is possible, that configuration does not 
make other key store types unavailable. In addition, this security 
property lets users choose a key store algorithm but not its provider. 
Uninstalling security providers that offer unwanted KeyStore service 
types is not always an option because other service types they offer 
might be legitimately required. In other words, this option lacks 
granularity. The only way to enforce a policy such as the one described 
in this case is to audit the application and library sources, 
configurations or logs and check how keys are managed. This approach 
would require manual actions and rechecks after each application or 
library change.

The Security Provider Filter makes the enforcement of this policy easy, 
even under the circumstances of an application or library update, or 
after the deployment of a new application. The policy can also be 
updated to include other key store algorithms, security providers or 
combinations of both.

2) A policy that enforces the use of PKCS #12 key stores only:

*.KeyStore.PKCS12; !*.KeyStore; *

In this scenario, a system administrator is concerned about applications 
using key stores with non-standard formats such as JKS, JCEKS, BKS 
(Bouncy Castle) or BCFKS (Bouncy Castle) among others. These key store 
algorithms may introduce interoperability issues and require unwanted 
file conversions at some point. Thus, the system administrator enforces 
a policy that only authorizes the PKCS #12 standard for key storage.

As in case #1, the security property for controlling the default key 
store type is not enough to prevent applications from using other 
formats; uninstalling security providers is not always an option; and 
auditing application or libraries source code, configurations or logs to 
check how key storage is done could be inconvenient or unfeasible.

The Security Provider Filter provides flexibility to change the approved 
key store type or authorize more than one. Third-party security 
providers may refer to the PKCS #12 standard by different algorithm 
names but that should not be a problem either. For example, the filter 
may authorize algorithm name variations such as PKCS12, BCPKCS12 (Bouncy 
Castle) and PKCS12-3DES-3DES (Bouncy Castle): "*.KeyStore.PKCS12; 
*.KeyStore.BCPKCS12; *.KeyStore.PKCS12-3DES-3DES; ...", or more simply 
"*.KeyStore.*PKCS12*; ...".

3) A policy that does not allow algorithms considered insecure:

!*.*.MD5; !*.*.MD2; !*.*.SHA-1; *

Security concerns are the motivation behind this type of policy. A 
system administrator may enforce it with a deny-list ?as done in the 
example? or even with a more strict allow-list one. This type of policy 
can be applied with algorithms considered secure today or algorithms 
that will be required in the future. The latter serves for the purpose 
of identifying potential compatibility issues and providing applications 
advanced notice to adapt.

While the Security Provider Filter is platform-independent, Linux 
crypto-policies is one of the motivations related to this case. Many 
Linux distributions, such as RHEL [2], have system-wide crypto-policies 
enabled by default. Different crypto-policies profiles (LEGACY, DEFAULT, 
FIPS, FUTURE, etc.) define sets of algorithms authorized for different 
software packages, including OpenJDK. Our intention is that 
crypto-policies for OpenJDK define, according to each profile, the set 
of algorithms allowed for all security APIs.

Before the Security Provider Filter, algorithms can be restricted for 
some uses with a deny-list type of configuration. However, not all uses 
are under scope and applications may use unauthorized algorithms by 
calling, for example, Signature.getInstance("<unauthorized-algorithm>") 
and using the service directly. Other approaches such as auditing 
application and libraries source code, configurations or logs to check 
which algorithms are used may not be practical, as pointed out in case #1.

The Security Provider Filter allows a system administrator to keep sets 
of authorized algorithms updated and apply its policy widely to all JCA 
service types.

4) A policy in which some uses of MD5 are acceptable (e.g. 
MessageDigest) but others are not:

!*.Signature.MD5*; !*.Mac.*MD5; !*.Cipher.*MD5*; *

or

*.MessageDigest.MD5; !*.*.*MD5*; *

Some algorithms may be secure for some uses but not for others. In this 
case, a system administrator authorizes MD5 for UUIDs, redundancy-check 
codes or other hashes, but prohibits its use for signatures, message 
authentication, and for deriving encryption keys (PBE).

This type of policy enforcement is possible because the Security 
Provider Filter lets users specify the service type, in addition to the 
algorithm. A system administrator can easily adjust the algorithms and 
service types that are allowed or disallowed.

For the same reasons explained in case #3, implementing this policy 
without the Security Provider Filter would not be possible or practical.

5) A policy in which only algorithms implemented by the FastProvider 
security provider are authorized for encryption:

FastProvider.Cipher; !*.Cipher; *

In this case, a system administrator is concerned about performance and 
wants applications to only do cipher operations in FastProvider.

While it is possible to insert FastProvider in the first place of the 
security providers list, or even use the preferred algorithms security 
property, an application that is using an algorithm not available in 
FastProvider will silently slide to a slower implementation. As 
described for other cases, removing slower security providers may not be 
an option, and auditing applications or libraries source code, 
configurations or logs may not be practical.

6) A policy that only allows a specific source of randomness, 
irrespective of the algorithm:

SunPKCS11-HSM.SecureRandom; !*.SecureRandom; *

A system administrator has security concerns about sources of randomness 
and decides to authorize only one of them, irrespective of the 
algorithm. In this case, the prioritized list of security providers is 
not enough to use SunPKCS11-HSM because applications may try to use 
algorithms not implemented there and silently slide into other security 
providers.

Enforcing this type of policy without the Security Provider Filter may 
require actions such as uninstalling security providers or auditing 
source code, configurations or logs that is not always possible or 
practical.

7) In CRIU scenarios, it could be beneficial to enforce a policy that 
does not allow the use of random values or key generation before a 
snapshot is taken. A snapshot can be taken, for example, running the JDK 
with the following filter value:

!*.SecureRandom; !*.KeyPairGenerator; !*.KeyGenerator; *

In some cases, a system administrator might want to enforce an even more 
strict policy using an allow-list approach:

*.MessageDigest.SHA-1; *.CertificateFactory; !*

When resuming a snapshot, no filter is set.

This example is based on a real case. To achieve the desired effect 
without the Security Providers Filter, a system administrator has to 
create a custom security provider that only implements authorized 
service types and algorithms. This security provider is the only one 
installed while taking the snapshot. When resuming snapshots, all 
security providers are enabled. This solution is hard to implement and 
not easily extensible to other service types and algorithms. With the 
Security Providers Filter it is easy to decide what is available while 
taking a snapshot, and what is available while resuming it.

This type of policy falls into the category of those that may benefit 
the security of a deployment. The reuse of random seeds or keys in 
different executions of the same snapshot may weaken or compromise the 
security of a system.

8) A policy that allows the use of a 3rd party security provider for a 
specific purpose but not for anything else:

3rdPartyProvider.AllowedService; !3rdPartyProvider; *

In this case, a system administrator has concerns of applications 
depending on a specific security provider for more service types or 
algorithms than what is authorized (AllowedService).

This type of policy is difficult to implement without the Security 
Provider Filter because there is no granularity when installing a 
security provider: it's an all or nothing decision. Thus, the only way 
around to enforce compliance is to check applications or libraries 
source code, configurations or logs and understand what they are 
depending on.

Examples Summary

Throughout the previous scenarios, we have discussed security, 
interoperability and performance concerns that may be addressed by the 
Security Providers Filter. What all these cases have in common is policy 
enforcement at provider, service type or algorithm level. We think that 
the existing providers or algorithms preference configurations miss the 
partial or total closure that the Filter offers. In addition, the lack 
of granularity makes the installation of a security provider an all or 
nothing decision. Thus, policy enforcement can only be applied by 
auditing applications or libraries source code, configuration or logs. 
This type of enforcement is not always possible or practical: a new 
deployment or update of an existing one requires a check. The existing 
functionality to block the use of algorithms does not extend to all 
security APIs and it's, thus, not enough from a policy enforcement and 
compliance perspective. While we have showcased fabricated system 
administration scenarios in some cases, others are of general interest, 
can be used more widely or represent real cases. On a final note, we 
have intentionally left the FIPS use-case out of this Appendix as it has 
been discussed in previous comments.

--
[1] - https://bugs.openjdk.org/browse/JDK-8315487
[2] - https://access.redhat.com/articles/3666211



On 9/19/23 16:42, Anthony Scarpino wrote:
> Hi Martin,
> 
> Thanks for the proposal. Your documents mostly describe the solution. 
> Can you provide more of the motivations and use-cases for the change? Do 
> you see non FIPS-140 applications using this feature?
> 
> The feature does provide a comprehensive filtering system for JCA. The 
> syntax, while powerful, seems like it would be somewhat error-prone and 
> hard to use. We are also concerned that using the filter requires the 
> sysadmin or developer to know about the service and algorithm details of 
> every provider and which is required and which is not, all of which is 
> not easily determined.
> 
> thanks
> 
> Tony


From mbalao at openjdk.org  Fri Oct  6 17:09:09 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 6 Oct 2023 17:09:09 GMT
Subject: RFR: 8315487: Security Providers Filter
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <MGWlCXFwtzVMDpiiyAjqfhf8iHKwuscNVRwmbVStYU8=.d551cd82-2887-42a7-93ec-af1fdd40e7e8@github.com>

On Fri, 1 Sep 2023 15:13:46 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

I wish we could keep this PR open. This is the latest comment in the ongoing discussion: https://mail.openjdk.org/pipermail/security-dev/2023-October/037479.html

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

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-1751120024

From svkamath at openjdk.org  Mon Oct  9 04:58:10 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 9 Oct 2023 04:58:10 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v4]
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <y7OrAPFWel7s-Cr0e9fWWEM-bHQCzFelCxLcO_p-vFo=.52d7e457-b287-48df-ac4c-6c3751a5dd24@github.com>

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated code as per review comments, added new comments for every method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15410/files
  - new: https://git.openjdk.org/jdk/pull/15410/files/c92f98ab..77fd61b9

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

  Stats: 132 lines in 2 files changed: 68 ins; 26 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/15410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15410/head:pull/15410

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

From svkamath at openjdk.org  Mon Oct  9 05:01:18 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 9 Oct 2023 05:01:18 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v4]
In-Reply-To: <y7OrAPFWel7s-Cr0e9fWWEM-bHQCzFelCxLcO_p-vFo=.52d7e457-b287-48df-ac4c-6c3751a5dd24@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <y7OrAPFWel7s-Cr0e9fWWEM-bHQCzFelCxLcO_p-vFo=.52d7e457-b287-48df-ac4c-6c3751a5dd24@github.com>
Message-ID: <FTwDY9j5W9QBkpp7UawIGY-L1IOps13xu10IPCgu0mo=.6af38912-5491-4288-ac22-a9d8e2bd9b95@github.com>

On Mon, 9 Oct 2023 04:58:10 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code as per review comments, added new comments for every method

@djelinski, @sviswa7, Thanks for your comments. I have addressed them in the latest commits. Kindly take a look and let me know your thoughts. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1752347949

From kdriver at openjdk.org  Mon Oct  9 16:43:29 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 9 Oct 2023 16:43:29 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not up-to-date
Message-ID: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>

fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number

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

Commit messages:
 - fixes JDK-8314199 by initializing the HashSet with a more accurate number

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

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

From jnimeh at openjdk.org  Mon Oct  9 17:03:58 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 9 Oct 2023 17:03:58 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date
In-Reply-To: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
Message-ID: <90nqGqpQxUgPT8akjabkO-gZSCEkHXVUj5J9EAh6Kus=.ef3edc75-7e8c-424c-82ca-5b8ba055e3aa@github.com>

On Mon, 9 Oct 2023 16:36:06 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number

src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line 59:

> 57: 
> 58:     static {
> 59:         validTypes = HashSet.newHashSet(21);

Rather than having to change the initial size and keep it synchronized with all the subsequent adds, could we just change the type of `validTypes` to `Set<String>` and initialize it using `Set.of(E...)`?  It seems like that would allow you to set all the values directly in the declaration up on line 49, would remove the need for the static block and I think you could even declare validTypes final, couldn't you?  And any new additions to the set could simply be added and not worry about setting an accurate count in the constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16103#discussion_r1350563277

From bpb at openjdk.org  Mon Oct  9 19:02:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 19:02:19 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v5]
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <SjSAmT4mBbzAW1fpiVQ63igcnLgD9VM-jyoFW9jL0BI=.43110b2d-2829-4ac2-8e9a-7256ac12b3a0@github.com>

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

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

 - Merge
 - 6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native
 - 6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy
 - 6478546: Decrease malloc limit to 1.5 MB
 - 6478546: Minor refactoring
 - 6478546: Prevent short read
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/cdb8455c..3a016a72

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

  Stats: 200415 lines in 4979 files changed: 96645 ins; 49069 del; 54701 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

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

From kdriver at openjdk.org  Mon Oct  9 19:03:01 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 9 Oct 2023 19:03:01 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date
In-Reply-To: <90nqGqpQxUgPT8akjabkO-gZSCEkHXVUj5J9EAh6Kus=.ef3edc75-7e8c-424c-82ca-5b8ba055e3aa@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
 <90nqGqpQxUgPT8akjabkO-gZSCEkHXVUj5J9EAh6Kus=.ef3edc75-7e8c-424c-82ca-5b8ba055e3aa@github.com>
Message-ID: <lKjmtqgl0gKrlAfXwF1yhq024-1ZrGcrMWT9PwjkrwI=.3dd99d39-23a7-4f97-8345-570d0ea58563@github.com>

On Mon, 9 Oct 2023 17:00:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number
>
> src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line 59:
> 
>> 57: 
>> 58:     static {
>> 59:         validTypes = HashSet.newHashSet(21);
> 
> Rather than having to change the initial size and keep it synchronized with all the subsequent adds, could we just change the type of `validTypes` to `Set<String>` and initialize it using `Set.of(E...)`?  It seems like that would allow you to set all the values directly in the declaration up on line 49, would remove the need for the static block and I think you could even declare validTypes final, couldn't you?  And any new additions to the set could simply be added and not worry about setting an accurate count in the constructor.

I wondered about an approach like this. I'll push another commit with these changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16103#discussion_r1350703267

From kdriver at openjdk.org  Mon Oct  9 19:22:56 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 9 Oct 2023 19:22:56 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date
In-Reply-To: <lKjmtqgl0gKrlAfXwF1yhq024-1ZrGcrMWT9PwjkrwI=.3dd99d39-23a7-4f97-8345-570d0ea58563@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
 <90nqGqpQxUgPT8akjabkO-gZSCEkHXVUj5J9EAh6Kus=.ef3edc75-7e8c-424c-82ca-5b8ba055e3aa@github.com>
 <lKjmtqgl0gKrlAfXwF1yhq024-1ZrGcrMWT9PwjkrwI=.3dd99d39-23a7-4f97-8345-570d0ea58563@github.com>
Message-ID: <UfSuin-OKxfHLieVS2b-IzoXJimODsYo6_PU7-mpVAs=.fa984dab-099c-494d-99e7-fca7ea71b08e@github.com>

On Mon, 9 Oct 2023 18:59:43 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line 59:
>> 
>>> 57: 
>>> 58:     static {
>>> 59:         validTypes = HashSet.newHashSet(21);
>> 
>> Rather than having to change the initial size and keep it synchronized with all the subsequent adds, could we just change the type of `validTypes` to `Set<String>` and initialize it using `Set.of(E...)`?  It seems like that would allow you to set all the values directly in the declaration up on line 49, would remove the need for the static block and I think you could even declare validTypes final, couldn't you?  And any new additions to the set could simply be added and not worry about setting an accurate count in the constructor.
>
> I wondered about an approach like this. I'll push another commit with these changes.

Do you think we'll lose performance in a meaningful way? One of the guarantees of HashSet is constant-time operations. 

There is no such guarantee for Set. The number of members is probably small enough, relatively speaking, to not affect things much at creation time (and we only do this once); however, lookup time (in `engineGetKeySpec` and `engineTranslateKey`) might take a small hit if these methods are called repeatedly. 

Let me know whether you think this is a valid concern. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16103#discussion_r1350717600

From jnimeh at openjdk.org  Mon Oct  9 20:16:57 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 9 Oct 2023 20:16:57 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date
In-Reply-To: <UfSuin-OKxfHLieVS2b-IzoXJimODsYo6_PU7-mpVAs=.fa984dab-099c-494d-99e7-fca7ea71b08e@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
 <90nqGqpQxUgPT8akjabkO-gZSCEkHXVUj5J9EAh6Kus=.ef3edc75-7e8c-424c-82ca-5b8ba055e3aa@github.com>
 <lKjmtqgl0gKrlAfXwF1yhq024-1ZrGcrMWT9PwjkrwI=.3dd99d39-23a7-4f97-8345-570d0ea58563@github.com>
 <UfSuin-OKxfHLieVS2b-IzoXJimODsYo6_PU7-mpVAs=.fa984dab-099c-494d-99e7-fca7ea71b08e@github.com>
Message-ID: <6en8Vy4pjj6jIGkfgPkaJnvlc6azQpBBdivXJDQW54Y=.a95f9a0c-dad9-4586-b361-5b0ccba18075@github.com>

On Mon, 9 Oct 2023 19:19:49 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> I wondered about an approach like this. I'll push another commit with these changes.
>
> Do you think we'll lose performance in a meaningful way? One of the guarantees of HashSet is constant-time operations. 
> 
> There is no such guarantee for Set. The number of members is probably small enough, relatively speaking, to not affect things much at creation time (and we only do this once); however, lookup time (in `engineGetKeySpec` and `engineTranslateKey`) might take a small hit if these methods are called repeatedly. 
> 
> Let me know whether you think this is a valid concern. Thanks!

I think there could be sight timing variations between `HashSet` and whatever Set implementation is returned by `Set.of()` but creation only happens once as you stated, and iterations over 20-ish elements just seems like the variance would be negligible in any real-world use cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16103#discussion_r1350752518

From valeriep at openjdk.org  Mon Oct  9 20:25:56 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 9 Oct 2023 20:25:56 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date
In-Reply-To: <6en8Vy4pjj6jIGkfgPkaJnvlc6azQpBBdivXJDQW54Y=.a95f9a0c-dad9-4586-b361-5b0ccba18075@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
 <90nqGqpQxUgPT8akjabkO-gZSCEkHXVUj5J9EAh6Kus=.ef3edc75-7e8c-424c-82ca-5b8ba055e3aa@github.com>
 <lKjmtqgl0gKrlAfXwF1yhq024-1ZrGcrMWT9PwjkrwI=.3dd99d39-23a7-4f97-8345-570d0ea58563@github.com>
 <UfSuin-OKxfHLieVS2b-IzoXJimODsYo6_PU7-mpVAs=.fa984dab-099c-494d-99e7-fca7ea71b08e@github.com>
 <6en8Vy4pjj6jIGkfgPkaJnvlc6azQpBBdivXJDQW54Y=.a95f9a0c-dad9-4586-b361-5b0ccba18075@github.com>
Message-ID: <QTZKHJydTFB6qMqK9WMm2tsCaAVLKMhX2SLPhYF1v9w=.d6f13544-ad8e-4ebd-a626-7c1bc626f4ca@github.com>

On Mon, 9 Oct 2023 20:13:48 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Do you think we'll lose performance in a meaningful way? One of the guarantees of HashSet is constant-time operations. 
>> 
>> There is no such guarantee for Set. The number of members is probably small enough, relatively speaking, to not affect things much at creation time (and we only do this once); however, lookup time (in `engineGetKeySpec` and `engineTranslateKey`) might take a small hit if these methods are called repeatedly. 
>> 
>> Let me know whether you think this is a valid concern. Thanks!
>
> I think there could be sight timing variations between `HashSet` and whatever Set implementation is returned by `Set.of()` but creation only happens once as you stated, and iterations over 20-ish elements just seems like the variance would be negligible in any real-world use cases.

How about changing to use the `HashSet(Collection<? extends E> c)` constructor? First construct a collection with the various algorithms and then construct `validType` w/ this collection. `validType` can be made unmodifiable also since it's read only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16103#discussion_r1350759168

From kdriver at openjdk.org  Mon Oct  9 20:42:39 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 9 Oct 2023 20:42:39 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date [v2]
In-Reply-To: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
Message-ID: <5YuDJ0aF-y7Z3Lj7GkRJdur6-rHtx-0EF9rwx6EGHIA=.7f2c02ca-12be-4a83-9d88-25248aca0c88@github.com>

> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number

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

  use a Set per code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16103/files
  - new: https://git.openjdk.org/jdk/pull/16103/files/96bdb279..a8521b6b

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

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

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

From kdriver at openjdk.org  Mon Oct  9 20:48:47 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 9 Oct 2023 20:48:47 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date [v3]
In-Reply-To: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
Message-ID: <g_y-S31FhiEVs4DLI4bJzrYXMC9F_TdH2BoWCwTdxRQ=.05342723-5a16-4b91-a4c2-e9e753511bb2@github.com>

> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number

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

  convert Set back to HashSet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16103/files
  - new: https://git.openjdk.org/jdk/pull/16103/files/a8521b6b..1f6d7281

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

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

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

From jnimeh at openjdk.org  Mon Oct  9 20:48:48 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 9 Oct 2023 20:48:48 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date [v3]
In-Reply-To: <g_y-S31FhiEVs4DLI4bJzrYXMC9F_TdH2BoWCwTdxRQ=.05342723-5a16-4b91-a4c2-e9e753511bb2@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
 <g_y-S31FhiEVs4DLI4bJzrYXMC9F_TdH2BoWCwTdxRQ=.05342723-5a16-4b91-a4c2-e9e753511bb2@github.com>
Message-ID: <WacZtt3Xo_m75UhIvoEKczsm9eRaOLgaQxS_pUfUi0Q=.35e86255-7b6a-4fca-a9a0-d994379f0928@github.com>

On Mon, 9 Oct 2023 20:44:50 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert Set back to HashSet

LGTM.

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16103#pullrequestreview-1665251892

From kdriver at openjdk.org  Mon Oct  9 21:03:07 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 9 Oct 2023 21:03:07 GMT
Subject: RFR: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date [v4]
In-Reply-To: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
Message-ID: <bBrUa8TlUe261tPv_qYCWBmzGnd3ghi75o6RXIOEVK8=.eb25a9f0-f443-40f7-839f-204e8a96e525@github.com>

> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number

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

  specify type for HashSet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16103/files
  - new: https://git.openjdk.org/jdk/pull/16103/files/1f6d7281..0656ff1b

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

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

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

From valeriep at openjdk.org  Mon Oct  9 21:09:57 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 9 Oct 2023 21:09:57 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <s6E92FenTg28Zg9eBDm_mxf7_wIVxPcfAXx8CIXYPzs=.2cf9d8ab-014b-4ec2-8af5-e0fb41a1b2ac@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

I'll take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/15412#issuecomment-1753872702

From valeriep at openjdk.org  Mon Oct  9 21:53:55 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 9 Oct 2023 21:53:55 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <aq93vdrwQTkXy7jnDHfs7EHbfKeCU9jXEySe60UXJM4=.8f63c5eb-5e34-4e79-95b3-0612af117ade@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 61:

> 59: 
> 60:     // the key bytes, without the algorithm information
> 61:     private final byte[] key;

I have an impending change which needs to re-assign key outside of constructor, thus can you leave this field as is and not marking it final?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1350813070

From valeriep at openjdk.org  Mon Oct  9 22:40:02 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 9 Oct 2023 22:40:02 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <fP6mNjdJXmayfBto3p_1y9duAB8yyU17j_Lak0LozCg=.ddb688a8-9ab1-4bdc-b1c5-6c9875c0e0cf@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 276:

> 274:     }
> 275: 
> 276:     private void parseKeyBits() throws InvalidKeyException {

This method is only called once inside the constructor, considering that this method is kind of trivial, maybe you can just move the impl to the constructor and remove this method.

src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java line 57:

> 55: 
> 56:     // the key bytes, without the algorithm information
> 57:     private final byte[] key;

Same comment about re-assignment, please don't add the final keyword to this field.

src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java line 268:

> 266:     }
> 267: 
> 268:     private void parseKeyBits() throws InvalidKeyException {

Same comment about moving this code block to constructor since it's only used once and the small size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1350892266
PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1350902339
PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1350909325

From jwaters at openjdk.org  Tue Oct 10 03:32:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Oct 2023 03:32:08 GMT
Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft
 Visual C compiler [v6]
In-Reply-To: <BXBfGPoamFRvgxI1ORAp9S3G-nNbio6O7GhSQhsZcWk=.9b86c41d-bded-4973-8144-c47f0f53e261@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BXBfGPoamFRvgxI1ORAp9S3G-nNbio6O7GhSQhsZcWk=.9b86c41d-bded-4973-8144-c47f0f53e261@github.com>
Message-ID: <l9VdprXtekW2pTnLXD29T1wg9uX5sv8_CKJyHtNiXh0=.c6df5fa7-8180-4bdb-a368-5204cada3a49@github.com>

On Thu, 28 Sep 2023 03:12:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'openjdk:master' into patch-10
>  - Merge branch 'master' into patch-10
>  - Document changes in awt_DnDDS.cpp
>  - Remove negation in os_windows.cpp
>  - Mismatched declaration in D3DGlyphCache.cpp
>  - Fields in awt_TextComponent.cpp
>  - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp
>  - Qualifiers in awt_PrintDialog.h should be removed
>  - Likewise for awt_DnDDT.cpp
>  - awt_ole.h include order issue in awt_DnDDS.cpp
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/84390dd0...1e2b39f9

Reopening - I will use this as the portion of the change for java.desktop and jdk.accessibility

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1754296794

From valeriep at openjdk.org  Tue Oct 10 04:20:58 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 10 Oct 2023 04:20:58 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <IkLJSObB2CtqZJY3w_Z_qfxtI4J83n1CFxGQ_LDahdo=.5fe13f32-de25-4039-ad57-0d2c5f7ef9c2@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

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

> 1: /*

Hmm, there is also sun/security/pkcs/EncryptedPrivateKeyInfo.java which seems to have the same API and provide the exact same functionality. Maybe we can remove this file and update the users of this class to use sun.security.pkcs.EncryptedPrivateKeyInfo instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1351371648

From svkamath at openjdk.org  Tue Oct 10 05:04:45 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 10 Oct 2023 05:04:45 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v5]
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <Xw-klDplnRW2mynsa8ptTuPStrcF0rgwUsQNEk5ruxE=.156e6c56-e376-43a8-8f73-c00ddb46ec43@github.com>

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated comments, generate_8_block_avx2 method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15410/files
  - new: https://git.openjdk.org/jdk/pull/15410/files/77fd61b9..7e1cf54d

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

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

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

From kdriver at openjdk.org  Tue Oct 10 05:47:29 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 10 Oct 2023 05:47:29 GMT
Subject: Integrated: 8314199: Initial size PBEKeyFactory#validTypes is not
 up-to-date
In-Reply-To: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
References: <eERO1JCAF-V1POzEoBX1-_36h5Kxt-qx3j5cCAcIP5Q=.85a428ef-39ba-4007-9a97-922080fa33a7@github.com>
Message-ID: <zdAcz3OJn0paxmSJ2Jb58oVxY5q3NXXkNYoVCMifvwo=.cd3cbbc1-4bd2-4a58-8996-e3f590da8223@github.com>

On Mon, 9 Oct 2023 16:36:06 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by initializing the HashSet with a more accurate number

This pull request has now been integrated.

Changeset: e882718a
Author:    Kevin Driver <kdriver at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e882718a6026d4d8dcc07da19ed1fa685ac49f17
Stats:     25 lines in 1 file changed: 1 ins; 0 del; 24 mod

8314199: Initial size PBEKeyFactory#validTypes is not up-to-date

Reviewed-by: jnimeh

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

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

From valeriep at openjdk.org  Tue Oct 10 06:00:38 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 10 Oct 2023 06:00:38 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <ormujh0wmYqc2nWsXk6MkY8OtPP9YN2NEMVU_anCKfw=.2dbf25ac-e04e-40a9-b259-e33af6eadd7f@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 109:

> 107:     int tagLenBytes = DEFAULT_TAG_LEN;
> 108:     // Key size if the value is passed, in bytes.
> 109:     private final int keySize;

Why not also mark the `blockCipher` as private final?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1351536561

From djelinski at openjdk.org  Tue Oct 10 06:42:59 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Oct 2023 06:42:59 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v4]
In-Reply-To: <y7OrAPFWel7s-Cr0e9fWWEM-bHQCzFelCxLcO_p-vFo=.52d7e457-b287-48df-ac4c-6c3751a5dd24@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <y7OrAPFWel7s-Cr0e9fWWEM-bHQCzFelCxLcO_p-vFo=.52d7e457-b287-48df-ac4c-6c3751a5dd24@github.com>
Message-ID: <37k6gxd6R7Ft0NWpy7SXv-m0ody0oPbRiT1IF4KMITc=.09321e5c-b0d0-478e-b6f0-ff22df861400@github.com>

On Mon, 9 Oct 2023 04:58:10 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code as per review comments, added new comments for every method

src/hotspot/cpu/x86/assembler_x86.cpp line 1335:

> 1333: 
> 1334: void Assembler::addb(Register dst, int imm8) {
> 1335:   prefix(dst);

This will miscompile code for rsi/rdi/rsp/rbp; the operation will use ah/bh/ch/dh instead of sil/dil/spl/bpl. I believe you need `prefix_and_encode(dst->encoding(), true);`. See: https://github.com/openjdk/jdk/blob/7e1cf54df79bc8010c40acd4f84c11dcba0d3dac/src/hotspot/cpu/x86/assembler_x86.cpp#L6257-L6258

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1350528886

From mdonovan at openjdk.org  Tue Oct 10 17:17:45 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 10 Oct 2023 17:17:45 GMT
Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms [v3]
In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
Message-ID: <dl-IeeiTRXdk-MDfCZhZOYhUASIUx9Px4uowyqaS0u8=.2f3f9300-4107-423c-98e9-6c3a07ece25f@github.com>

> This PR updates the version of NSS to 3.91 and includes aarch64 platforms.
> 
> There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one.

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

 - Merge branch 'master' into pkcs11-nss-upgrade
 - Merge branch 'master' into pkcs11-nss-upgrade
 - 8314283: Support for NSS tests on aarch64 platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15429/files
  - new: https://git.openjdk.org/jdk/pull/15429/files/021b23e4..7ff53094

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

  Stats: 11502 lines in 268 files changed: 6089 ins; 2172 del; 3241 mod
  Patch: https://git.openjdk.org/jdk/pull/15429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15429/head:pull/15429

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

From rhalade at openjdk.org  Tue Oct 10 18:14:12 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 10 Oct 2023 18:14:12 GMT
Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms [v3]
In-Reply-To: <dl-IeeiTRXdk-MDfCZhZOYhUASIUx9Px4uowyqaS0u8=.2f3f9300-4107-423c-98e9-6c3a07ece25f@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
 <dl-IeeiTRXdk-MDfCZhZOYhUASIUx9Px4uowyqaS0u8=.2f3f9300-4107-423c-98e9-6c3a07ece25f@github.com>
Message-ID: <oOk8MaI8SXiy2sQVH3vxJqAYXPyF0-7BE-pfVtabZNQ=.d5a46b09-00f7-448b-a3d9-792f79ee3271@github.com>

On Tue, 10 Oct 2023 17:17:45 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the version of NSS to 3.91 and includes aarch64 platforms.
>> 
>> There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into pkcs11-nss-upgrade
>  - Merge branch 'master' into pkcs11-nss-upgrade
>  - 8314283: Support for NSS tests on aarch64 platforms

Marked as reviewed by rhalade (Reviewer).

test/jdk/sun/security/pkcs11/PKCS11Test.java line 936:

> 934:             organization = "jpg.tests.jdk.nsslib",
> 935:             name = "nsslib-windows_x64",
> 936:             revision = "3.46-VS2017",

nsslib-windows_x86 support is not updated to 3.91. Is it possible to upgrade this (although we don't have it as a supported platform)

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

PR Review: https://git.openjdk.org/jdk/pull/15429#pullrequestreview-1668528361
PR Review Comment: https://git.openjdk.org/jdk/pull/15429#discussion_r1353081236

From valeriep at openjdk.org  Tue Oct 10 19:39:19 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 10 Oct 2023 19:39:19 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <CAjS-HnuHQVMUGhFn7e28Jh1XzmoQSBlKV4RFireFIg=.b45c1e77-cd2a-4d04-a257-004d8c6bf959@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 102:

> 100:      * Hash entries are keyed by alias names.
> 101:      */
> 102:     private final Hashtable<String, Object> entries = new Hashtable<String, Object>();

If the line is longer than 80 chars, the convention is to break it into 2 lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1353227207

From weijun at openjdk.org  Tue Oct 10 20:57:49 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 10 Oct 2023 20:57:49 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v2]
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <Z2FZmVZdfy1mdy_eGvbkDTJfdE0l0fRQLW8h-e_9Bjc=.17d6888f-758a-4c8f-a563-f98bf01faa31@github.com>

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.

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

  let run return int

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15951/files
  - new: https://git.openjdk.org/jdk/pull/15951/files/6e04fac3..ed6d72c7

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

  Stats: 128 lines in 7 files changed: 24 ins; 47 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/15951.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15951/head:pull/15951

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

From weijun at openjdk.org  Tue Oct 10 21:11:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 10 Oct 2023 21:11:21 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15951/files
  - new: https://git.openjdk.org/jdk/pull/15951/files/ed6d72c7..e22257a9

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

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

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

From valeriep at openjdk.org  Tue Oct 10 22:24:24 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 10 Oct 2023 22:24:24 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <QOWw_LgPK05-dOfc0c6kvb5LX0zZWheXl8QRkyGHZo4=.96404696-b438-4055-9adc-185befe194b0@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 127:

> 125:         // Use the cleaner to zero the key when no longer referenced
> 126:         final byte[] k = this.key = key;
> 127:         final char[] p = this.passwd;

Now that `this.key` and `this.passwd` is final, we can get rid of the local final variables `k` and `p`, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1353495078

From valeriep at openjdk.org  Tue Oct 10 22:31:00 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 10 Oct 2023 22:31:00 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <2kdAtzllcJLURevezedfZjFRjXa4EXDGmB6LTQlwRB4=.ba7ecac5-b17c-483e-981b-1dd8a626f4e0@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java line 165:

> 163:         private static final long serialVersionUID = 1019571680375368880L;
> 164: 
> 165:         private final byte[] key;

Again, I have an impending change which would require this field to be non-final.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1353498700

From svkamath at openjdk.org  Tue Oct 10 23:21:54 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 10 Oct 2023 23:21:54 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v6]
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <17PclKIK_ZA6BrMLGitrZhf8v41Jg3gc4q2jF55VX8I=.e5a1d8b5-c4d6-4a26-b821-00c2f5a4ec07@github.com>

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated addb instruction definition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15410/files
  - new: https://git.openjdk.org/jdk/pull/15410/files/7e1cf54d..7812f36d

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

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

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

From svkamath at openjdk.org  Tue Oct 10 23:49:18 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 10 Oct 2023 23:49:18 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v7]
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <EmMUvUPUorUkwXW3rx9Kkq-ZgOSTwXKadEeAT2C2sU8=.d20680cc-1a18-42b9-be3c-d47365abb7f1@github.com>

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated addb instruction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15410/files
  - new: https://git.openjdk.org/jdk/pull/15410/files/7812f36d..7ce8068f

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

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

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

From sviswanathan at openjdk.org  Wed Oct 11 00:21:11 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 00:21:11 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v7]
In-Reply-To: <EmMUvUPUorUkwXW3rx9Kkq-ZgOSTwXKadEeAT2C2sU8=.d20680cc-1a18-42b9-be3c-d47365abb7f1@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <EmMUvUPUorUkwXW3rx9Kkq-ZgOSTwXKadEeAT2C2sU8=.d20680cc-1a18-42b9-be3c-d47365abb7f1@github.com>
Message-ID: <ISTgZI-Wwc7Hml9UfJr4JbvxrIIIQHMHHcKAs7rH9r8=.98ce74a0-dae0-49d0-a91f-f895fa5b54f4@github.com>

On Tue, 10 Oct 2023 23:49:18 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated addb instruction

Thanks a lot for considering the review comments. The PR looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15410#pullrequestreview-1669414361

From aturbanov at openjdk.org  Wed Oct 11 08:11:13 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Oct 2023 08:11:13 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <IkLJSObB2CtqZJY3w_Z_qfxtI4J83n1CFxGQ_LDahdo=.5fe13f32-de25-4039-ad57-0d2c5f7ef9c2@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
 <IkLJSObB2CtqZJY3w_Z_qfxtI4J83n1CFxGQ_LDahdo=.5fe13f32-de25-4039-ad57-0d2c5f7ef9c2@github.com>
Message-ID: <CCkbBna0KGhctUu0_6WgzPGnGlSYlwKXfSZCPh3NSPw=.dc7bbb39-f75e-4584-82f2-4bcb2344deeb@github.com>

On Tue, 10 Oct 2023 04:17:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.
>
> src/java.base/share/classes/com/sun/crypto/provider/EncryptedPrivateKeyInfo.java line 1:
> 
>> 1: /*
> 
> Hmm, there is also sun/security/pkcs/EncryptedPrivateKeyInfo.java which seems to have the same API and provide the exact same functionality. Maybe we can remove this file and update the users of this class to use sun.security.pkcs.EncryptedPrivateKeyInfo instead.

Looks similar, yes. I think it's worth to create a separate improvement for it.

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 109:
> 
>> 107:     int tagLenBytes = DEFAULT_TAG_LEN;
>> 108:     // Key size if the value is passed, in bytes.
>> 109:     private final int keySize;
> 
> Why not also mark the `blockCipher` as private final?

Good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1354352969
PR Review Comment: https://git.openjdk.org/jdk/pull/15412#discussion_r1354354214

From aturbanov at openjdk.org  Wed Oct 11 08:16:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Oct 2023 08:16:00 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package [v2]
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <ToiLZtytXHYqM5I6igh2Ok-uFbeQoVXpis0_JwlEwvY=.828baeaa-5c66-43b4-a80b-bde6209076b5@github.com>

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

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

 - Merge remote-tracking branch 'origin/master' into final_fields_com.sun.crypto.provider
   
   # Conflicts:
   #	src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
 - 8315974: Make fields final in 'com.sun.crypto.provider' package
   
   apply review suggestions
 - [PATCH]: Make fields final in com.sun.crypto.provider package

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

Changes: https://git.openjdk.org/jdk/pull/15412/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15412&range=01
  Stats: 131 lines in 32 files changed: 11 ins; 26 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/15412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15412/head:pull/15412

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

From djelinski at openjdk.org  Wed Oct 11 11:00:04 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Oct 2023 11:00:04 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v7]
In-Reply-To: <EmMUvUPUorUkwXW3rx9Kkq-ZgOSTwXKadEeAT2C2sU8=.d20680cc-1a18-42b9-be3c-d47365abb7f1@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <EmMUvUPUorUkwXW3rx9Kkq-ZgOSTwXKadEeAT2C2sU8=.d20680cc-1a18-42b9-be3c-d47365abb7f1@github.com>
Message-ID: <dzmR6mQyvFQW1m3Sbca1sdcwhzQPLXNrnzSrSlMYpRw=.15b0559c-d723-4db8-afe8-5e5830c71c10@github.com>

On Tue, 10 Oct 2023 23:49:18 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated addb instruction

Could you update the comment on `implGCMCrypt0`?
https://github.com/openjdk/jdk/blob/731fb4eea21ab67d90970d7c6107fb0a4fbee9ec/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java#L625-L629

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3755:

> 3753:   const XMMRegister ctr_blockx = xmm9;
> 3754:   const XMMRegister aad_hashx = xmm8;
> 3755:   Label encrypt_done, encrypt_by_8_parallel, encrypt_by_8_new, encrypt_by_8, hash_last_8, generate_htbl_8_blks;

`encrypt_by_8_parallel` is never used in jumps; `hash_last_8` and `generate_htbl_8_blks` are never used. Can you remove them?

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

PR Review: https://git.openjdk.org/jdk/pull/15410#pullrequestreview-1670446151
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1354454458

From mdonovan at openjdk.org  Wed Oct 11 16:45:15 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 11 Oct 2023 16:45:15 GMT
Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms [v4]
In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
Message-ID: <lGD0p1elNQ_mScTL2o52n9CPGPZlk50jasU72vfvNpQ=.296aea3a-46d4-42a6-9693-d3c0de0032d2@github.com>

> This PR updates the version of NSS to 3.91 and includes aarch64 platforms.
> 
> There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one.

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

 - removed other reference to x86 windows
 - Merge branch 'master' into pkcs11-nss-upgrade
 - removed 32-bit windows entry
 - Merge branch 'master' into pkcs11-nss-upgrade
 - Merge branch 'master' into pkcs11-nss-upgrade
 - 8314283: Support for NSS tests on aarch64 platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15429/files
  - new: https://git.openjdk.org/jdk/pull/15429/files/7ff53094..a46f6ae9

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

  Stats: 3016 lines in 86 files changed: 1154 ins; 1331 del; 531 mod
  Patch: https://git.openjdk.org/jdk/pull/15429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15429/head:pull/15429

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

From mdonovan at openjdk.org  Wed Oct 11 16:48:12 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 11 Oct 2023 16:48:12 GMT
Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms [v4]
In-Reply-To: <oOk8MaI8SXiy2sQVH3vxJqAYXPyF0-7BE-pfVtabZNQ=.d5a46b09-00f7-448b-a3d9-792f79ee3271@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
 <dl-IeeiTRXdk-MDfCZhZOYhUASIUx9Px4uowyqaS0u8=.2f3f9300-4107-423c-98e9-6c3a07ece25f@github.com>
 <oOk8MaI8SXiy2sQVH3vxJqAYXPyF0-7BE-pfVtabZNQ=.d5a46b09-00f7-448b-a3d9-792f79ee3271@github.com>
Message-ID: <DP5OzcqCRxMqz4Rir8v72Rxq0f8c4M0gorlkg0Gbyuw=.237ef514-5d06-4e57-8f4e-b15db680b366@github.com>

On Tue, 10 Oct 2023 18:08:59 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - removed other reference to x86 windows
>>  - Merge branch 'master' into pkcs11-nss-upgrade
>>  - removed 32-bit windows entry
>>  - Merge branch 'master' into pkcs11-nss-upgrade
>>  - Merge branch 'master' into pkcs11-nss-upgrade
>>  - 8314283: Support for NSS tests on aarch64 platforms
>
> test/jdk/sun/security/pkcs11/PKCS11Test.java line 936:
> 
>> 934:             organization = "jpg.tests.jdk.nsslib",
>> 935:             name = "nsslib-windows_x64",
>> 936:             revision = "3.46-VS2017",
> 
> nsslib-windows_x86 support is not updated to 3.91. Is it possible to upgrade this (although we don't have it as a supported platform)

I spent a few hours trying to get this to compile but the build environment is corrupted somehow and didn't want to spend a lot of time on this since it's not supported. I can make a new bug to support if if we need it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15429#discussion_r1355361879

From mdonovan at openjdk.org  Wed Oct 11 16:48:13 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 11 Oct 2023 16:48:13 GMT
Subject: Integrated: 8314283: Support for NSS tests on aarch64 platforms
In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com>
Message-ID: <DKQ72pLgmI1C4xuadUeNPDtV4UG02J-u2esb2WJKehw=.3816e19f-df70-4bc8-a2fa-5cb246a55b3a@github.com>

On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates the version of NSS to 3.91 and includes aarch64 platforms.
> 
> There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one.

This pull request has now been integrated.

Changeset: 2a801609
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a8016096000de5836251f2ca9bc8ad6479e6942
Stats:     41 lines in 2 files changed: 24 ins; 3 del; 14 mod

8314283: Support for NSS tests on aarch64 platforms

Reviewed-by: rhalade

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

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

From rhalade at openjdk.org  Wed Oct 11 18:14:43 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 11 Oct 2023 18:14:43 GMT
Subject: RFR: 8317967: Enhance
 test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default
 cases
Message-ID: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>

Template is updated to handle default cases and will also throw an Error on not supported test protocols.

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

Commit messages:
 - 8317967: Enhance test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default cases

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

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

From mullan at openjdk.org  Wed Oct 11 19:02:51 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 11 Oct 2023 19:02:51 GMT
Subject: RFR: 8317967: Enhance
 test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default
 cases
In-Reply-To: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
References: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
Message-ID: <qeqit8893Nhdb3suO3Qwx1OQnzgYE6uOtIwYbtOmKts=.3684c6d2-dbfc-4424-b0eb-12b4bd07d71f@github.com>

On Wed, 11 Oct 2023 18:01:07 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Template is updated to handle default cases and will also throw an Error on not supported test protocols.

Changes requested by mullan (Reviewer).

test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java line 742:

> 740:                         break;
> 741:                     case "DTLS":
> 742:                     case "DTLSv1.1":

Should be "DTLSv1.2". There is no DTLSv1.1 protocol.

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

PR Review: https://git.openjdk.org/jdk/pull/16156#pullrequestreview-1672269354
PR Review Comment: https://git.openjdk.org/jdk/pull/16156#discussion_r1355599940

From rhalade at openjdk.org  Wed Oct 11 19:31:44 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 11 Oct 2023 19:31:44 GMT
Subject: RFR: 8317967: Enhance
 test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default
 cases [v2]
In-Reply-To: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
References: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
Message-ID: <lJ7XkcTjKzBq_MIbd1JbK11Wsho-vPooniaYJP4fZwg=.02431910-1592-4be1-9c9c-ce9320c8dd23@github.com>

> Template is updated to handle default cases and will also throw an Error on not supported test protocols.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  Update DTLSv1.1 to DTLSv1.2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16156/files
  - new: https://git.openjdk.org/jdk/pull/16156/files/6bda2bfa..05390fcb

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

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

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

From rhalade at openjdk.org  Wed Oct 11 21:23:01 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 11 Oct 2023 21:23:01 GMT
Subject: RFR: 8317967: Enhance
 test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default
 cases [v3]
In-Reply-To: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
References: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
Message-ID: <nSnLW1YUv8Y_nlnMDfqAfLUONh38Qoj9mKqkMfQg4L4=.78f0f216-46d1-4a8e-bb92-f2a2a61de500@github.com>

> Template is updated to handle default cases and will also throw an Error on not supported test protocols.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  No default for test.security.protocol property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16156/files
  - new: https://git.openjdk.org/jdk/pull/16156/files/05390fcb..3ba9979f

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

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

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

From kdriver at openjdk.org  Wed Oct 11 21:32:46 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 11 Oct 2023 21:32:46 GMT
Subject: RFR: 8308453: Convert JKS test keystores in test/jdk/javax/net/ssl/etc
 to PKCS12
Message-ID: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>

JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

Commit messages:
 - JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

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

From mpowers at openjdk.org  Wed Oct 11 21:42:12 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 11 Oct 2023 21:42:12 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <2H2jS8XHPD7kyT9ocmlVXi_70DZ54bez6eqhslzhNhM=.4db10a45-9423-49a1-b074-71b58c141f64@github.com>

On Wed, 11 Oct 2023 21:24:30 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

Looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/16159#pullrequestreview-1672643060

From svkamath at openjdk.org  Wed Oct 11 22:05:08 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 11 Oct 2023 22:05:08 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated comments, removed unused labels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15410/files
  - new: https://git.openjdk.org/jdk/pull/15410/files/7ce8068f..3551cefe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=06-07

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

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

From djelinski at openjdk.org  Thu Oct 12 06:24:23 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 12 Oct 2023 06:24:23 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
Message-ID: <bxGclqZykRnIDKz5lqNKTsCHmdak0enZQQZGJ4xXQSI=.1c9dbe03-fa97-4ff0-aec4-6f3b86fee8bf@github.com>

On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments, removed unused labels

Thanks for bearing with me. LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15410#pullrequestreview-1673128998

From mullan at openjdk.org  Thu Oct 12 13:53:56 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 12 Oct 2023 13:53:56 GMT
Subject: RFR: 8317967: Enhance
 test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default
 cases [v3]
In-Reply-To: <nSnLW1YUv8Y_nlnMDfqAfLUONh38Qoj9mKqkMfQg4L4=.78f0f216-46d1-4a8e-bb92-f2a2a61de500@github.com>
References: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
 <nSnLW1YUv8Y_nlnMDfqAfLUONh38Qoj9mKqkMfQg4L4=.78f0f216-46d1-4a8e-bb92-f2a2a61de500@github.com>
Message-ID: <iAB1EhLDF-1iytzzD9C66Wh5gh2zNSGdtTxYBY69bKU=.f87fad1e-84e3-49e2-bdc9-77207d5772cc@github.com>

On Wed, 11 Oct 2023 21:23:01 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Template is updated to handle default cases and will also throw an Error on not supported test protocols.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No default for test.security.protocol property

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16156#pullrequestreview-1674141252

From mullan at openjdk.org  Thu Oct 12 13:53:56 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 12 Oct 2023 13:53:56 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <n2nagvNU8KxujFmUiKC6UtDM_8Bd0ONW8lE8aU-BFaU=.f42dc7c0-f1df-4840-a7d9-763da25fbfdf@github.com>

On Wed, 11 Oct 2023 21:24:30 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

The ones you changed to PKCS12 is fine, but you should also convert the binary keystores in the `test/jdk/javax/net/ssl/etc` directory. You can use the `keytool -importkeystore` command to convert JKS to PKCS12, ex:

`keytool -importkeystore -srckeystore keystore -srcstoretype JKS -deststoretype PKCS12 -destkeystore keystore.p12`

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

PR Comment: https://git.openjdk.org/jdk/pull/16159#issuecomment-1759578395

From kdriver at openjdk.org  Thu Oct 12 15:21:16 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 12 Oct 2023 15:21:16 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v2]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <FVmBkBWljqpFVwGXAjXkiKsMhh0L05AHU1OyvwG-jIQ=.8be6d6de-2418-4b29-b6fe-305ce0c937f8@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/9ccd25b8..06a30c07

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

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

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

From kdriver at openjdk.org  Thu Oct 12 15:59:06 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 12 Oct 2023 15:59:06 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12
In-Reply-To: <n2nagvNU8KxujFmUiKC6UtDM_8Bd0ONW8lE8aU-BFaU=.f42dc7c0-f1df-4840-a7d9-763da25fbfdf@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <n2nagvNU8KxujFmUiKC6UtDM_8Bd0ONW8lE8aU-BFaU=.f42dc7c0-f1df-4840-a7d9-763da25fbfdf@github.com>
Message-ID: <OZ1wBD7U5kS6kW2ud2P8wxzie7wOQDPEoSn6rrSYERE=.22464282-d947-439c-b058-186bc0670ead@github.com>

On Thu, 12 Oct 2023 13:06:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The ones you changed to PKCS12 is fine, but you should also convert the binary keystores in the `test/jdk/javax/net/ssl/etc` directory. 

I have done so now. Please re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/16159#issuecomment-1759903112

From rhalade at openjdk.org  Thu Oct 12 17:08:18 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 12 Oct 2023 17:08:18 GMT
Subject: Integrated: 8317967: Enhance
 test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default
 cases
In-Reply-To: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
References: <kzsCU6YfY0xUYS9ZUz8IOQNM_FyvBWrxSbCZRgxxZGg=.3f9baaee-fb5d-4313-a327-5cee2f623eb7@github.com>
Message-ID: <F-zqxq2a3VqKWv-3K8DnQAu_IuxnuwzZItMBieUuQ-w=.10965548-0150-45a3-9b8c-882e5dc23d2c@github.com>

On Wed, 11 Oct 2023 18:01:07 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Template is updated to handle default cases and will also throw an Error on not supported test protocols.

This pull request has now been integrated.

Changeset: 9728e21d
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9728e21db1b35e487c562690de659aac386aa99d
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8317967: Enhance test/jdk/javax/net/ssl/TLSCommon/SSLEngineTestCase.java to handle default cases

Reviewed-by: mullan

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

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

From kdriver at openjdk.org  Thu Oct 12 17:36:49 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 12 Oct 2023 17:36:49 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v3]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <2cFYklJ0Yft3dNTG57Wi4WLGiC6j26y92E_aRzAo_1U=.0c781796-6f66-44c7-8baf-8d18148c1795@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/06a30c07..e118be60

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

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

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

From valeriep at openjdk.org  Thu Oct 12 18:20:11 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 12 Oct 2023 18:20:11 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package [v2]
In-Reply-To: <ToiLZtytXHYqM5I6igh2Ok-uFbeQoVXpis0_JwlEwvY=.828baeaa-5c66-43b4-a80b-bde6209076b5@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
 <ToiLZtytXHYqM5I6igh2Ok-uFbeQoVXpis0_JwlEwvY=.828baeaa-5c66-43b4-a80b-bde6209076b5@github.com>
Message-ID: <c_GLDE1caeH9PWWZrP0-UbeEgUWsOUVtHhgxZiq4-0k=.db411fc6-826c-46d0-bba0-39eee30f55bc@github.com>

On Wed, 11 Oct 2023 08:16:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/master' into final_fields_com.sun.crypto.provider
>    
>    # Conflicts:
>    #	src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
>  - 8315974: Make fields final in 'com.sun.crypto.provider' package
>    
>    apply review suggestions
>  - [PATCH]: Make fields final in com.sun.crypto.provider package

Changes look good to me.
Thanks!

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15412#pullrequestreview-1674858869

From weijun.wang at oracle.com  Thu Oct 12 18:38:04 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Thu, 12 Oct 2023 18:38:04 +0000
Subject: Proposing the getParams method in PublicKey and PrivateKey 
Message-ID: <E80EED88-BB28-4CFE-8043-0A6121618A03@oracle.com>

Hi All,

Currently, every algorithm-specific asymmetric key interface (Ex: ECKey) in JDK has a getParams() method. We are thinking about duplicating this method in PublicKey and PrivateKey (returning null by default) so the method is available for all asymmetric keys. Once we have this method, even if a new algorithm is introduced in a future release, there is no need to rewrite your applications to use any new algorithm-specific API (suppose the new algorithm does not invent any new AlgorithmParameterSpec type).

Since PublicKey/PrivateKey and, say, ECKey do not have the same parent interface, there will be an ambiguity in their child interfaces to decide which getParams() to choose. In order to fix this, we will add new default methods in all existing child interfaces (Ex: ECPublicKey and ECPrivateKey) that return the same type as their algorithm-specific parent (Ex: ECKey::getParams returns ECParameterSpec) with a value null.

Do you have any comment?

The risk is that if an existing algorithm-specific interface already has this method but does not return an AlgorithmParameterSpec object there will be a conflict. In fact, inside OpenJDK, DSAKey's getParams() returns a DSAParams object which is not an AlgorithmParameterSpec. We'll modify it to extend AlgorithmParameterSpec.

If there is something similar in your code, please let us know. And, do you think you can fix it the same way we do?

Thanks,
Weijun

----

Example:

java.security.PublicKey:

+    default AlgorithmParameterSpec getParams(){
+        return null;
+    }

java.security.interfaces.ECKey:

     ECParameterSpec getParams();

java.security.interfaces.ECPublicKey:

+    default ECParameterSpec getParams(){
+        return null;
+    }



From hchao at openjdk.org  Thu Oct 12 21:19:03 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 12 Oct 2023 21:19:03 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v3]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <hNzBiKzPnIIJrLTaukYb7pYINMmiz0mHxh6RsIZw8pI=.20806392-9012-470f-bb54-9886918a8eb2@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao 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:

 - Merge
 - Set to default if a negative value is set
 - 8311596: Add separate system properties for TLS server and client for maximum chain length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/2b91946f..e8174347

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

  Stats: 173160 lines in 4731 files changed: 83096 ins; 37227 del; 52837 mod
  Patch: https://git.openjdk.org/jdk/pull/15163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15163/head:pull/15163

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

From hchao at openjdk.org  Fri Oct 13 16:04:48 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 13 Oct 2023 16:04:48 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Change made to configure max allowed cert chain lengths based on updated CSR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/e8174347..53ae43bf

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

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

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

From mpowers at openjdk.org  Fri Oct 13 18:05:10 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 13 Oct 2023 18:05:10 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
Message-ID: <I_JFvcGaIjZIDvpi6j5DPWX5-RQyp_oU3ry3KwwCgaY=.02203024-8197-4d26-8ce6-6caf1dd923fa@github.com>

On Fri, 13 Oct 2023 16:04:48 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change made to configure max allowed cert chain lengths based on updated CSR

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 117:

> 115:     static final int maxClientCertificateChainLength;
> 116: 
> 117:     // Limit the maximum certificate chain length accepted from servers

I would drop "maximum" and just say "Limit the certificate chain length accepted from servers". It's not worth making this change unless you have to make another change to this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358639542

From svkamath at openjdk.org  Fri Oct 13 18:08:12 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 13 Oct 2023 18:08:12 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
Message-ID: <yfysW2fNNBQUWfaBM9q2Zh0CoQ1ozEEqx0ZGEruu9x4=.ec4e44ef-da47-445e-9706-968a57828af1@github.com>

On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments, removed unused labels

@vnkozlov, I have received two approvals for this PR. Could you kindly run this through your testing? Thanks for your time.

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1761961395

From weijun at openjdk.org  Fri Oct 13 19:02:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Oct 2023 19:02:11 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
Message-ID: <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>

On Fri, 13 Oct 2023 16:04:48 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change made to configure max allowed cert chain lengths based on updated CSR

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 173:

> 171:          */
> 172:         if (maxCertificateChainLength > 0) {
> 173:             if (clientLen == 8) {

If the user sets "jdk.tls.maxClientCertificateChainLength" precisely to 8 and you will ignore it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358706510

From rhalade at openjdk.org  Fri Oct 13 19:08:40 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 13 Oct 2023 19:08:40 GMT
Subject: RFR: 8268916: Tests for AffirmTrust roots
Message-ID: <zTwVF1rZtt2ObepMhlc2yY5PDAcD9DG74qrW-z4sBg0=.c7cdd3e9-99af-44e6-9909-1b22f849bf34@github.com>

Test is updated to include interoperability testing for 4 AffirmTrust root CAs.

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

Commit messages:
 - 8268916: Tests for AffirmTrust roots

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

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

From hchao at openjdk.org  Fri Oct 13 19:33:10 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 13 Oct 2023 19:33:10 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <I_JFvcGaIjZIDvpi6j5DPWX5-RQyp_oU3ry3KwwCgaY=.02203024-8197-4d26-8ce6-6caf1dd923fa@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <I_JFvcGaIjZIDvpi6j5DPWX5-RQyp_oU3ry3KwwCgaY=.02203024-8197-4d26-8ce6-6caf1dd923fa@github.com>
Message-ID: <m7e9XauzBnUZKdg2oD-U-xMgms7JcVz1dlyaqk0QquQ=.500e4ad9-32bf-4920-84b5-784e537e4e95@github.com>

On Fri, 13 Oct 2023 18:02:34 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change made to configure max allowed cert chain lengths based on updated CSR
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 117:
> 
>> 115:     static final int maxClientCertificateChainLength;
>> 116: 
>> 117:     // Limit the maximum certificate chain length accepted from servers
> 
> I would drop "maximum" and just say "Limit the certificate chain length accepted from servers". It's not worth making this change unless you have to make another change to this file.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358734306

From hchao at openjdk.org  Fri Oct 13 19:33:12 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 13 Oct 2023 19:33:12 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
Message-ID: <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>

On Fri, 13 Oct 2023 18:59:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change made to configure max allowed cert chain lengths based on updated CSR
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 173:
> 
>> 171:          */
>> 172:         if (maxCertificateChainLength > 0) {
>> 173:             if (clientLen == 8) {
> 
> If the user sets "jdk.tls.maxClientCertificateChainLength" precisely to 8 and you will ignore it?

Since 8 is the default for "jdk.tls.maxClientCertificateChainLength", it is going to be overridden when "jdk.tls.maxCertificateChainLength" is set. Setting "jdk.tls.maxClientCertificateChainLength" to 8 is treated as keeping the original default like no-op.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358734387

From valeriep at openjdk.org  Fri Oct 13 19:34:09 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 13 Oct 2023 19:34:09 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
Message-ID: <rRpvLzbqDEFpg_iFowU8XtQAJjIVOz2kZiehoOcGAes=.a7278586-d0bc-4bcc-aef9-48c323109257@github.com>

On Tue, 10 Oct 2023 21:11:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>> 
>> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java line 155:

> 153:             } else {
> 154:                 displayMessage("Credentials cache");
> 155:                 return -1;

Make displayMessage(String) return -1 and just use "return displayMessage();"? (Other displayXXX() also returns int)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1358736269

From weijun at openjdk.org  Fri Oct 13 21:47:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Oct 2023 21:47:11 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
 <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>
Message-ID: <VU1Lxn0ybjrx7Fvx3NsLMDq8DBYrDS3Fv57pF-xbbZs=.f83f6e66-c65c-44a3-a4e5-95624054a185@github.com>

On Fri, 13 Oct 2023 19:29:54 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 173:
>> 
>>> 171:          */
>>> 172:         if (maxCertificateChainLength > 0) {
>>> 173:             if (clientLen == 8) {
>> 
>> If the user sets "jdk.tls.maxClientCertificateChainLength" precisely to 8 and you will ignore it?
>
> Since 8 is the default for "jdk.tls.maxClientCertificateChainLength", it is going to be overridden when "jdk.tls.maxCertificateChainLength" is set. Setting "jdk.tls.maxClientCertificateChainLength" to 8 is treated as keeping the original default like no-op.

If I understand correctly, "jdk.tls.maxClientCertificateChainLength" is meant to override "jdk.tls.maxClientCertificateChainLength" if both are defined. Then what would happen if user has specified `-Djdk.tls.maxClientCertificateChainLength=8 -Djdk.tls.maxCertificateChainLength=4`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358873304

From weijun at openjdk.org  Fri Oct 13 21:57:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Oct 2023 21:57:21 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v4]
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <OnbCXyuStbwZFOt0V12Y3EiP3wfRwFVVbmDkEqpTBpU=.d3aee46f-0cfa-4c24-9348-255cd6447b37@github.com>

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
> 
> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.

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

  displayError

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15951/files
  - new: https://git.openjdk.org/jdk/pull/15951/files/e22257a9..ffb17d0b

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

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

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

From weijun at openjdk.org  Fri Oct 13 21:57:22 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Oct 2023 21:57:22 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <rRpvLzbqDEFpg_iFowU8XtQAJjIVOz2kZiehoOcGAes=.a7278586-d0bc-4bcc-aef9-48c323109257@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
 <rRpvLzbqDEFpg_iFowU8XtQAJjIVOz2kZiehoOcGAes=.a7278586-d0bc-4bcc-aef9-48c323109257@github.com>
Message-ID: <RkZDfMjwc7am7kioY5Z1vrbobXvg-w1amLs8hn7Cb7I=.12521150-cbd8-4fb7-8be6-7d8e5305be7e@github.com>

On Fri, 13 Oct 2023 19:31:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java line 155:
> 
>> 153:             } else {
>> 154:                 displayMessage("Credentials cache");
>> 155:                 return -1;
> 
> Make displayMessage(String) return -1 and just use "return displayMessage();"? (Other displayXXX() also returns int)

Sure, I've renamed to `displayError` to match the return code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1358892612

From hchao at openjdk.org  Fri Oct 13 23:00:27 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 13 Oct 2023 23:00:27 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <VU1Lxn0ybjrx7Fvx3NsLMDq8DBYrDS3Fv57pF-xbbZs=.f83f6e66-c65c-44a3-a4e5-95624054a185@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
 <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>
 <VU1Lxn0ybjrx7Fvx3NsLMDq8DBYrDS3Fv57pF-xbbZs=.f83f6e66-c65c-44a3-a4e5-95624054a185@github.com>
Message-ID: <JGKV7mcQ1swM0Gpi99gITwvOZfShGP0EEvKr2vavT0s=.e734bfc7-5764-42ff-aca2-91ae2ce3ca2e@github.com>

On Fri, 13 Oct 2023 21:43:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Since 8 is the default for "jdk.tls.maxClientCertificateChainLength", it is going to be overridden when "jdk.tls.maxCertificateChainLength" is set. Setting "jdk.tls.maxClientCertificateChainLength" to 8 is treated as keeping the original default like no-op.
>
> If I understand correctly, "jdk.tls.maxClientCertificateChainLength" is meant to override "jdk.tls.maxClientCertificateChainLength" if both are defined. Then what would happen if user has specified `-Djdk.tls.maxClientCertificateChainLength=8 -Djdk.tls.maxCertificateChainLength=4`?

`jdk.tls.maxCertificateChainLength` will only override `jdk.tls.maxClientCertificateChainLength` if `jdk.tls.maxCertificateChainLength` is set AND `jdk.tls.maxClientCertificateChainLength` is using the default. For the case your provided here, `jdk.tls.maxClientCertificateChainLength` will be overridden to be 4 which is set by `jdk.tls.maxCertificateChainLength`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358946093

From weijun at openjdk.org  Fri Oct 13 23:17:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Oct 2023 23:17:53 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <JGKV7mcQ1swM0Gpi99gITwvOZfShGP0EEvKr2vavT0s=.e734bfc7-5764-42ff-aca2-91ae2ce3ca2e@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
 <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>
 <VU1Lxn0ybjrx7Fvx3NsLMDq8DBYrDS3Fv57pF-xbbZs=.f83f6e66-c65c-44a3-a4e5-95624054a185@github.com>
 <JGKV7mcQ1swM0Gpi99gITwvOZfShGP0EEvKr2vavT0s=.e734bfc7-5764-42ff-aca2-91ae2ce3ca2e@github.com>
Message-ID: <qVN7ZIdI1R8C4XcflrmtmW_vcm5xa2DuobMAp0zIjZ0=.8b96dd26-090d-469d-8183-3ff41ff08867@github.com>

On Fri, 13 Oct 2023 22:57:25 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> If I understand correctly, "jdk.tls.maxClientCertificateChainLength" is meant to override "jdk.tls.maxClientCertificateChainLength" if both are defined. Then what would happen if user has specified `-Djdk.tls.maxClientCertificateChainLength=8 -Djdk.tls.maxCertificateChainLength=4`?
>
> `jdk.tls.maxCertificateChainLength` will only override `jdk.tls.maxClientCertificateChainLength` if `jdk.tls.maxCertificateChainLength` is set AND `jdk.tls.maxClientCertificateChainLength` is using the default. For the case your provided here, `jdk.tls.maxClientCertificateChainLength` will be overridden to be 4 which is set by `jdk.tls.maxCertificateChainLength`.

That's not my understanding. Since `jdk.tls.maxClientCertificateChainLength` is explicitly set on the command line you should honor it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1358952446

From valeriep at openjdk.org  Sat Oct 14 00:04:03 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 14 Oct 2023 00:04:03 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
Message-ID: <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>

On Tue, 10 Oct 2023 21:11:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>> 
>> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 82:

> 80:     }
> 81: 
> 82:     private static class ExitException extends RuntimeException {

If we want to use ExitException as internal exception, perhaps it's easier to not extending RuntimeException? This way we can rely on compiler to flag all methods which throw it and handle it accordingly.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 155:

> 153:     private static void exit(int exitCode) {
> 154:         throw new ExitException(exitCode);
> 155:     }

I don't see much benefit of this method since it's one-line to one-line. For other classes, it seems that value 0 is ok, but here an exception is thrown regardless of exit code value. Is this really intended?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1358982000
PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1358985633

From aturbanov at openjdk.org  Mon Oct 16 07:08:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 16 Oct 2023 07:08:57 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v4]
In-Reply-To: <OnbCXyuStbwZFOt0V12Y3EiP3wfRwFVVbmDkEqpTBpU=.d3aee46f-0cfa-4c24-9348-255cd6447b37@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <OnbCXyuStbwZFOt0V12Y3EiP3wfRwFVVbmDkEqpTBpU=.d3aee46f-0cfa-4c24-9348-255cd6447b37@github.com>
Message-ID: <30bnmvxt7SH99oYZKK8LnXrKhZ64xICJPdp-d2XnKTI=.d596b2c9-b5f4-4083-af37-a345ec4cd37b@github.com>

On Fri, 13 Oct 2023 21:57:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>> 
>> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   displayError

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java line 151:

> 149:                 target = CredentialsCache.getInstance(name);
> 150: 
> 151:             if (target != null)  {

Suggestion:

            if (target != null) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1360200185

From mullan at openjdk.org  Mon Oct 16 12:29:50 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 16 Oct 2023 12:29:50 GMT
Subject: RFR: 8268916: Tests for AffirmTrust roots
In-Reply-To: <zTwVF1rZtt2ObepMhlc2yY5PDAcD9DG74qrW-z4sBg0=.c7cdd3e9-99af-44e6-9909-1b22f849bf34@github.com>
References: <zTwVF1rZtt2ObepMhlc2yY5PDAcD9DG74qrW-z4sBg0=.c7cdd3e9-99af-44e6-9909-1b22f849bf34@github.com>
Message-ID: <SPXp8abPZRLmdAhiDIofDa_dFbmLWWXYxhykrFK8r8Q=.8b7372ae-3b84-4182-91a7-1ecf944ccc03@github.com>

On Fri, 13 Oct 2023 19:01:22 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test is updated to include interoperability testing for 4 AffirmTrust root CAs.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16190#pullrequestreview-1679844797

From mullan at openjdk.org  Mon Oct 16 13:35:25 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 16 Oct 2023 13:35:25 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <qVN7ZIdI1R8C4XcflrmtmW_vcm5xa2DuobMAp0zIjZ0=.8b96dd26-090d-469d-8183-3ff41ff08867@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
 <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>
 <VU1Lxn0ybjrx7Fvx3NsLMDq8DBYrDS3Fv57pF-xbbZs=.f83f6e66-c65c-44a3-a4e5-95624054a185@github.com>
 <JGKV7mcQ1swM0Gpi99gITwvOZfShGP0EEvKr2vavT0s=.e734bfc7-5764-42ff-aca2-91ae2ce3ca2e@github.com>
 <qVN7ZIdI1R8C4XcflrmtmW_vcm5xa2DuobMAp0zIjZ0=.8b96dd26-090d-469d-8183-3ff41ff08867@github.com>
Message-ID: <LwxUd6Iw44CIAgvGQRt1QhiuObVS1oQqH9Af4Z_NO8U=.9723da09-7b11-47c5-8d01-5484c4065268@github.com>

On Fri, 13 Oct 2023 23:15:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> `jdk.tls.maxCertificateChainLength` will only override `jdk.tls.maxClientCertificateChainLength` if `jdk.tls.maxCertificateChainLength` is set AND `jdk.tls.maxClientCertificateChainLength` is using the default. For the case your provided here, `jdk.tls.maxClientCertificateChainLength` will be overridden to be 4 which is set by `jdk.tls.maxCertificateChainLength`.
>
> That's not my understanding. Since `jdk.tls.maxClientCertificateChainLength` is explicitly set on the command line you should honor it.

Yes, I agree that if the application sets `jdk.tls.maxClientCertificateChainLength` or `jdk.tls.maxServerCertificateChainLength`, it should always take precedence even if the specified value is the same as the default. This would also preserve application behavior if one day we want to change the default to something else.

You will need to first see if these properties are set before assigning the default value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1360672720

From jlaskey at openjdk.org  Mon Oct 16 13:50:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 13:50:58 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview)
Message-ID: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>

Update String Templates for a second preview. With the addition of

- Expression type and throws are determined from the `process` method of the processor type and not the processor type.

- Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .

- Raw (generic) process types are no longer an error.

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

Commit messages:
 - Accept qualified STR and RAW
 - String Templates (second preview)

Changes: https://git.openjdk.org/jdk/pull/16202/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315457
  Stats: 91 lines in 29 files changed: 29 ins; 30 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

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

From alanb at openjdk.org  Mon Oct 16 14:30:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 14:30:15 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview)
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>

On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:

> 134:      * @param value       value to mix in
> 135:      * @return            new length and coder
> 136:      * @since 22

The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360750529

From weijun at openjdk.org  Mon Oct 16 14:35:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 16 Oct 2023 14:35:36 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
 <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>
Message-ID: <L9eOKBkrjv1sfeE_WLi0zp30dY7BoQRtdoOY746vwic=.1ca317b5-1879-424c-b952-aaffe4b932d9@github.com>

On Fri, 13 Oct 2023 23:58:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 82:
> 
>> 80:     }
>> 81: 
>> 82:     private static class ExitException extends RuntimeException {
> 
> If we want to use ExitException as internal exception, perhaps it's easier to not extending RuntimeException? This way we can rely on compiler to flag all methods which throw it and handle it accordingly.

Well, not sure if makes code simpler. For the 3 tools where `ExitException` is used, all `run` methods explicitly catch it and returns the exit code. Therefore it's not likely to be ignored. On the other hand, if I make it a checked exception, I would need to add a lot (more than 10) of `throws ExitException` in methods where it could be thrown and they are noises to this code change.  After all, `ExitException` is unrecoverable and IMO should be a `RuntimeException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1360758084

From jlaskey at openjdk.org  Mon Oct 16 14:35:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 14:35:37 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview)
In-Reply-To: <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
Message-ID: <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>

On Mon, 16 Oct 2023 14:27:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:
> 
>> 134:      * @param value       value to mix in
>> 135:      * @return            new length and coder
>> 136:      * @since 22
> 
> The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

Wasn't sure about that. Thx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360757078

From mbaesken at openjdk.org  Mon Oct 16 15:52:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Oct 2023 15:52:47 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <UVdVKMRqhPmOAI2RgE-kY1btCkHHJAdcOzPkOSdh9tY=.f6de512d-ac41-4c00-87fb-7554c6390052@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

Hello, any comments about the idea of calling into 'os::dll_load' instead ? That would indeed make the coding smaller and less 'messy' .

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1764687056

From weijun at openjdk.org  Mon Oct 16 16:23:13 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 16 Oct 2023 16:23:13 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v5]
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
> 
> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.

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

  inline some throw statements, remove duplicated whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15951/files
  - new: https://git.openjdk.org/jdk/pull/15951/files/ffb17d0b..78466670

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

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

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

From weijun at openjdk.org  Mon Oct 16 16:23:41 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 16 Oct 2023 16:23:41 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v4]
In-Reply-To: <30bnmvxt7SH99oYZKK8LnXrKhZ64xICJPdp-d2XnKTI=.d596b2c9-b5f4-4083-af37-a345ec4cd37b@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <OnbCXyuStbwZFOt0V12Y3EiP3wfRwFVVbmDkEqpTBpU=.d3aee46f-0cfa-4c24-9348-255cd6447b37@github.com>
 <30bnmvxt7SH99oYZKK8LnXrKhZ64xICJPdp-d2XnKTI=.d596b2c9-b5f4-4083-af37-a345ec4cd37b@github.com>
Message-ID: <avqLVvww-rCfjUV36znVL-TL8KZBD_Ye9CQjjUGVSOc=.acb2128f-7bb9-433d-a3e2-72502eb56677@github.com>

On Mon, 16 Oct 2023 07:02:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   displayError
>
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java line 151:
> 
>> 149:                 target = CredentialsCache.getInstance(name);
>> 150: 
>> 151:             if (target != null)  {
> 
> Suggestion:
> 
>             if (target != null) {

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1360767584

From weijun at openjdk.org  Mon Oct 16 16:23:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 16 Oct 2023 16:23:57 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
 <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>
Message-ID: <as_vb-RI4HPObOAXsBD2EdRYe2Yuv6HVOTKZR5_jE2k=.58da72d4-120a-4d2c-b672-19fc70303d13@github.com>

On Sat, 14 Oct 2023 00:00:52 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 155:
> 
>> 153:     private static void exit(int exitCode) {
>> 154:         throw new ExitException(exitCode);
>> 155:     }
> 
> I don't see much benefit of this method since it's one-line to one-line. For other classes, it seems that value 0 is ok, but here an exception is thrown regardless of exit code value. Is this really intended?

I'll inline the throw statements.

Yes, no matter if it's zero or not. Throwing the exception makes sure it jumps back to `run` immediately. If the code is 0, then the `main` method will return normally.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1360764046

From rhalade at openjdk.org  Mon Oct 16 16:31:47 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 16 Oct 2023 16:31:47 GMT
Subject: Integrated: 8268916: Tests for AffirmTrust roots
In-Reply-To: <zTwVF1rZtt2ObepMhlc2yY5PDAcD9DG74qrW-z4sBg0=.c7cdd3e9-99af-44e6-9909-1b22f849bf34@github.com>
References: <zTwVF1rZtt2ObepMhlc2yY5PDAcD9DG74qrW-z4sBg0=.c7cdd3e9-99af-44e6-9909-1b22f849bf34@github.com>
Message-ID: <xmQ1hRcLh0yNI97sgP0AekyuXdkGXmWBVlCH4O1w6c4=.f55cad1e-855b-478f-b1c3-3556f1dc14e0@github.com>

On Fri, 13 Oct 2023 19:01:22 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test is updated to include interoperability testing for 4 AffirmTrust root CAs.

This pull request has now been integrated.

Changeset: 8c1bb2b2
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c1bb2b28066ee32bef22110df06318d938c7d8b
Stats:     54 lines in 1 file changed: 54 ins; 0 del; 0 mod

8268916: Tests for AffirmTrust roots

Reviewed-by: mullan

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

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

From duke at openjdk.org  Mon Oct 16 22:33:26 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 22:33:26 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does
 not throw CharacterCodingException
Message-ID: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>

When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

Commit messages:
 - Make the NoRepl methods throw IllegalArgument

Changes: https://git.openjdk.org/jdk/pull/16209/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318200
  Stats: 93 lines in 8 files changed: 10 ins; 58 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

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

From hchao at openjdk.org  Mon Oct 16 23:01:28 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 16 Oct 2023 23:01:28 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v4]
In-Reply-To: <LwxUd6Iw44CIAgvGQRt1QhiuObVS1oQqH9Af4Z_NO8U=.9723da09-7b11-47c5-8d01-5484c4065268@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <8Wrdm6yJFzIrQhxHnHjTWw8pHPgdkB7o3BrFuPe46Gc=.185b3173-5e8d-413e-a0bd-3dfb4867cfdb@github.com>
 <AMM02vFBAnG2_TpPWRWFDa2TCi99Z-hoObY818UY54I=.089298be-c559-48fc-b674-5fc897a1f83c@github.com>
 <TIdydhhPW0tQaoMmYiayZiNgyJzHmgPsoIWtTU8UlYo=.5028bfc7-0bde-46b8-8f5e-59caca66dd2f@github.com>
 <VU1Lxn0ybjrx7Fvx3NsLMDq8DBYrDS3Fv57pF-xbbZs=.f83f6e66-c65c-44a3-a4e5-95624054a185@github.com>
 <JGKV7mcQ1swM0Gpi99gITwvOZfShGP0EEvKr2vavT0s=.e734bfc7-5764-42ff-aca2-91ae2ce3ca2e@github.com>
 <qVN7ZIdI1R8C4XcflrmtmW_vcm5xa2DuobMAp0zIjZ0=.8b96dd26-090d-469d-8183-3ff41ff08867@github.com>
 <LwxUd6Iw44CIAgvGQRt1QhiuObVS1oQqH9Af4Z_NO8U=.9723da09-7b11-47c5-8d01-5484c4065268@github.com>
Message-ID: <kEoAB8tCDXfKK7bZXTdJq9-eGOsYQxmMaXKFjlLcibY=.e3fb23c8-35bd-4578-a636-70a0c56b756c@github.com>

On Mon, 16 Oct 2023 13:31:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> That's not my understanding. Since `jdk.tls.maxClientCertificateChainLength` is explicitly set on the command line you should honor it.
>
> Yes, I agree that if the application sets `jdk.tls.maxClientCertificateChainLength` or `jdk.tls.maxServerCertificateChainLength`, it should always take precedence even if the specified value is the same as the default.
> 
> You will need to first see if these properties are set before assigning the default value.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1361340286

From hchao at openjdk.org  Mon Oct 16 23:01:27 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 16 Oct 2023 23:01:27 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v5]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <HcWNIl0Qu0LCU-Yxf69_TkBMuwh40KvSJ5OJakReN4k=.025b937f-c61e-4114-9e3a-ae36a564d8b3@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Override the client/server defaults

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/53ae43bf..2e264f94

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

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

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

From liach at openjdk.org  Tue Oct 17 03:12:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 03:12:21 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>

On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

src/java.base/share/classes/java/lang/String.java line 932:

> 930: 
> 931:     private static byte[] getBytesNoRepl1(String s, Charset cs) {
> 932:         return getBytesNoRepl1(s, cs);

This method should probably be removed. This current implementation is an infinite recursion.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 319:

> 317:                 }
> 318:             } catch (IllegalArgumentException e) {
> 319:                 return Comparison.NO_MATCH;

Should check if the cause is `CharacterCodingException`

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

Changes requested by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1681283802
PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455389
PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455717

From duke at openjdk.org  Tue Oct 17 03:22:56 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 03:22:56 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <uBEU92GDEPocWi5zI0E3mQdzQyfE5YvddA3-zDnPhC0=.28191342-1e25-49a1-8529-03538c311f68@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @liach 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/aa76c505..d2063b08

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

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

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

From duke at openjdk.org  Tue Oct 17 07:39:06 2023
From: duke at openjdk.org (Varada M)
Date: Tue, 17 Oct 2023 07:39:06 GMT
Subject: RFR: 8318240: [AIX] Cleaners.java test failure
Message-ID: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>

When the test sets the sun.security.jgss.native and sun.security.nativegss.debug as true, the test fails on AIX due to missing Kerberos GSS API dynamic library` libgssapi_krb5.so` 

JBS Issue : [JDK-8318240](https://bugs.openjdk.org/browse/JDK-8318240)

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

Commit messages:
 - fix for Cleaners.java

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

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

From redestad at openjdk.org  Tue Oct 17 09:34:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 09:34:22 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
Message-ID: <FRlXtni8mqAfPaTetCo2745x_b4yZnBQa5YTBnZVggk=.30c0e192-f563-4043-a6ae-52f759ca7b3a@github.com>

On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix from @liach 's review
>
> The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

I agree with @liach that `Files.readString / writeString` should continue to throw `CCE`, not `IAE`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766035016

From alanb at openjdk.org  Tue Oct 17 10:36:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 10:36:14 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
Message-ID: <Z3iDeeamWd9xO9ubJKKfW3IBNbpCywZPjdJv5-6XQ-Q=.66cdb1c1-05a1-42aa-8d37-091afed5b69b@github.com>

On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

Right, these APIs are specified to throw an IOException "If an I/O error occurs reading from the file or a malformed or unmappable byte sequence is read". Changing this to throw an unexpected IAE would be a breaking change. So good to spot this. Need to make sure that tier2 tests are run with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766104613

From duke at openjdk.org  Tue Oct 17 10:42:59 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 10:42:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v3]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Files.readString/writeString throws CCE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/d2063b08..a93be313

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

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

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

From redestad at openjdk.org  Tue Oct 17 10:45:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 10:45:22 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v3]
In-Reply-To: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>
Message-ID: <rdO145zAvUiv4srzlq69oOFrjEMNpR61fDNbam_EOX8=.cb536a25-2f91-4c09-bd84-99e307bada23@github.com>

On Tue, 17 Oct 2023 10:42:59 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.readString/writeString throws CCE

test/jdk/java/lang/String/NoReplTest.java line 62:

> 60:                             .withUpperCase()
> 61:                             .formatHex(read.getBytes(UTF_16)));
> 62:         } catch (CharacterCodingException cce) {

Shouldn't these test changes be completely reverted now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361904067

From duke at openjdk.org  Tue Oct 17 11:11:52 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 11:11:52 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  revert NoReplTest, from @cl4es 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/a93be313..cc3bc9ed

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

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

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

From alanb at openjdk.org  Tue Oct 17 11:15:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 11:15:51 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
Message-ID: <E08AepxGA8OzEZeTREiCbMhzSnnvlqh77AJcOfystuQ=.fc0d6647-0aca-416d-8bb4-c96229e15123@github.com>

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

src/java.base/share/classes/java/nio/file/Files.java line 3361:

> 3359:                 throw cause;
> 3360:             }
> 3361:             throw e;

This is wrong, if IAE is thrown for any other reason than CharacterCodingException then it means the JDK is broken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361937982

From alanb at openjdk.org  Tue Oct 17 11:19:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 11:19:00 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
Message-ID: <sSWobByGIMZOlW7k9XqVOLQrsHEme6oGqwVMIJVr-4I=.0d67b44e-a9cd-428e-ae79-92899233f319@github.com>

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

I've set this PR to require two Reviewers as there is obvious breakage here and no evidence that the tier2 tests have been run.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766203522

From lkorinth at openjdk.org  Tue Oct 17 12:29:46 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 17 Oct 2023 12:29:46 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:

 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/27da7150..44af07b9

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

  Stats: 1102 lines in 462 files changed: 11 ins; 22 del; 1069 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From rgiulietti at openjdk.org  Tue Oct 17 14:12:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 14:12:07 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
Message-ID: <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

@wenshao The proposal changes the exception types for seemingly no reason.
What concrete problem does this enhancement PR address?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766499191

From duke at openjdk.org  Tue Oct 17 14:22:10 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:22:10 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @AlanBateman 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/cc3bc9ed..f7023991

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

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

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

From duke at openjdk.org  Tue Oct 17 14:36:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:36:40 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
 <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>
Message-ID: <xhjiNfqPxaQx0sUbfnYnKHklpTFlgG2jn_XAhPgjmtg=.f1ce9f92-f8a7-421c-9e9d-939b4907d865@github.com>

On Tue, 17 Oct 2023 14:09:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> @wenshao The proposal changes the exception types for seemingly no reason. What concrete problem does this enhancement PR address?

@lianch 's suggestion in PR #14812 : 
"Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed. "

We used noRepl in UUID/HexFormat to handle CCE. I felt that the code was not clean enough, so I submitted this PR.

After the discussion above, I found that things are not that simple. Should I continue this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766540065

From liach at openjdk.org  Tue Oct 17 14:43:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 14:43:52 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <xhjiNfqPxaQx0sUbfnYnKHklpTFlgG2jn_XAhPgjmtg=.f1ce9f92-f8a7-421c-9e9d-939b4907d865@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
 <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>
 <xhjiNfqPxaQx0sUbfnYnKHklpTFlgG2jn_XAhPgjmtg=.f1ce9f92-f8a7-421c-9e9d-939b4907d865@github.com>
Message-ID: <wNmL-X3JCNaAWgz1abkEj1EhZsWbhN2_DP7HtERda6s=.bfbb68e1-be70-478b-b6fe-023b43c7cfbc@github.com>

On Tue, 17 Oct 2023 14:30:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> @wenshao The proposal changes the exception types for seemingly no reason.
> What concrete problem does this enhancement PR address?

@rgiulietti The API was exposed to create a String without duplicating an array in compatible encoding. Initially they are added for Files.readString and writeString, which has a custom exception logic. However, in the coming years, the usages for no-replication has grown, but no other user needs the CCE behavior, which makes code complex. As a result, we are proposing to localize the CCE logoc to Files.readString and writeString so other use sites can call the APIs without try-catch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766561936

From weijun at openjdk.org  Tue Oct 17 15:38:44 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Oct 2023 15:38:44 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
Message-ID: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>

Add `getParams` to `PublicKey` and `PrivateKey` so it's available to all current and future public and private keys.

No test. Might add one.

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

Commit messages:
 - 8318096: Add getParams method in PublicKey and PrivateKey

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

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

From sean.mullan at oracle.com  Tue Oct 17 17:12:15 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 17 Oct 2023 17:12:15 +0000
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <A6282C7A-270C-48B5-BA36-87A54D6FF2A0@oracle.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
 <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
 <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>
 <A6282C7A-270C-48B5-BA36-87A54D6FF2A0@oracle.com>
Message-ID: <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com>

Hi Karl,

I discussed your proposal with some other colleagues.

We generally feel a PEM KeyStore would be a useful addition to the JDK. This would alleviate usability issues that many users encounter when configuring and deploying applications that store keys or certificates in PEM files.

However, we would like to first make sure that your PEM KeyStore implementation will work well with the PEM API that we will be proposing soon. We think this is a perfect opportunity to ensure they work well together and would appreciate your help in reviewing and validating the API - would you be interested in helping out?

Once that is done, we can discuss next steps.

Thanks,
Sean


On Oct 5, 2023, at 9:41 AM, Sean Mullan <sean.mullan at oracle.com<mailto:sean.mullan at oracle.com>> wrote:



On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer <karl.scheibelhofer at gmx.net<mailto:karl.scheibelhofer at gmx.net>> wrote:

Hi Sean,

Yes, I had a look at the Contributing docs at the OpenJDK site before. I also signed the OCA.

Great, thanks.


Honestly, I thought there would be some more reaction on the suggested PEM KeyStore. It would really be good to discuss the topic with others. Is there anything we can do to get others in sharing their thoughts on this?

I think there is a fair amount of interest in it, but reviewing something significant like this takes a bit of time, as I mentioned in my prior email. Also, if we do decide to accept the contribution, we want to make sure it works well with the PEM API that we are working on - we hope to have a draft of a JEP for that out in the next few weeks. So I think we probably need a few weeks to review your contribution.


There is already a fair amount of documentation und unit tests. See https://github.com/KarlScheibelhofer/java-crypto-tools/ .

Ok.

?Sean


Best regards,
Karl

On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mullan at oracle.com<mailto:sean.mullan at oracle.com>> wrote:
Hi Karl,

The OpenJDK Developer?s Guide includes a helpful section on Contributing to an OpenJDK Project [1]. I suggest you read through that if you have not already. In particular, have you signed the OCA? I don?t want to review your code/contribution until that is done.

For this particular contribution, I don?t think there has been enough discussion and evaluation from members of the Security project. This would be a fairly major contribution. Keep in mind that a contribution doesn?t mean the work ends there.  There would need to be documentation, tests, and ongoing support for the foreseeable future. We need to think about these aspects every time we add a new feature, so there needs to be a strong motivation for doing it.

Thanks,
Sean

[1] https://openjdk.org/guide/#contributing-to-an-openjdk-project

> On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer <karl.scheibelhofer at gmx.net<mailto:karl.scheibelhofer at gmx.net>> wrote:
>
> Hi All,
>
> I would like to contribute my PEM KeyStore implementation to the
> OpenJDK, including integration in the OpenJDK source and creating a
> pull request.
> What is the recommended way to do this?
> Who can create a suitable ticket in OpenJDK to document the
> enhancement and to track the progress?
>
> What are the requirements for a pull request to get merged?
>
> Best regards
>
> Karl
>
> Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
> <karl.scheibelhofer at gmx.net<mailto:karl.scheibelhofer at gmx.net>>:
>>
>> Hi  Tony!
>>
>> When the PEM API implementation becomes available it would make sense
>> to use it inside the PEM Keystore implementation. It will reduce the
>> code (the internal classes PemReader und PemWriter may become
>> obsolete), but it does not affect the functionality of the PEM
>> keystore. Users of the PEM Keystore won't experience a difference.
>>
>> Let me know when there is something for the PEM API and I will see if
>> I can assist.
>>
>> I would suggest starting with PEM Keystore now and not wait for the
>> PEM API, because the time schedule for it seems vague. I would try to
>> refactor my current PEM Keystore implementation to integrate in the
>> OpenJDK sun.security.provider package. I do not expect any API changes
>> or other compatibility issues with existing code. Then consult this
>> group for feedback before creating a pull request.
>>
>> When the PEM API becomes available, rework the PEM Keystore
>> implementation to use it internally.
>>
>> What do you think?
>>
>> Best regards
>>
>>  Karl Scheibelhofer
>>
>> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
>> <anthony.scarpino at oracle.com<mailto:anthony.scarpino at oracle.com>>:
>>>
>>> There are no doc links yet.
>>>
>>> Tony
>>>
>>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
>>>> Hi Tony,
>>>>
>>>> The motivation was mostly about reading PEM keys and certificates
>>>> generated somewhere else. This is common practice in enterprise
>>>> environments I work in. Because corporate key material is subject to
>>>> centralized key management, including generation, backup and rollover.
>>>> PEM is the format most software products can handle. For Java
>>>> applications, having a PEM KeyStore would reduce the often required
>>>> additional step of converting PEM key and certificate in a Java
>>>> Keystore/PKCS#12.
>>>> Even truststores handling is easier with individual PEM certificates
>>>> instead of a single PKCS#12 Truststore. Adding or deleting a single
>>>> file instead of replacing the complete PKCS#12 store is less error
>>>> prone and cleaner to track in version control. The additional benefit
>>>> of a MAC in PKCS#12 adds little to no security in most cases.
>>>> And being text based, PEM is more version control friendly than binary PKCS#12.
>>>>
>>>> But to enable sound support of PEM, I also implemented writing PEM
>>>> keys and certificates. This way, one can use the JDK keytool to
>>>> generate key and certificate signing requests in PEM format. Getting
>>>> the certificate from the CA in PEM, one can use PEM throughout the
>>>> process.
>>>>
>>>> Do you have any links or documentation on the PEM API JEP that you mentioned?
>>>>
>>>> Thank you for your feedback and best regards
>>>>
>>>>   Karl
>>>>
>>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
>>>> <anthony.scarpino at oracle.com<mailto:anthony.scarpino at oracle.com>>:
>>>>>
>>>>> Hi Karl
>>>>>
>>>>> The keystore is interesting and may have some value.  Was your use case
>>>>> mostly reading PEM keys and certificates generated elsewhere for use
>>>>> with a particular application, maybe webservers?  Did you see value in
>>>>> writing to this keystore from Java?
>>>>>
>>>>> On the topic of PEM, I hope before the end of the year to have a PEM API
>>>>> JEP.  I would be interested in your API feedback from your keystore
>>>>> experiences.  I think if this keystore contribution was accepted, it
>>>>> should wait so it can use that API.
>>>>>
>>>>> thanks
>>>>>
>>>>> Tony
>>>>>
>>>>>
>>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Working with Java and the JCA KeyStore for decades, I came across
>>>>>> many situations where I thought it would be convenient to be
>>>>>> able to load private keys and certificates in PEM format directly
>>>>>> using the KeyStore API. Without the need to convert them to PKCS#12/JKS.
>>>>>>
>>>>>> You can find my implementation of a PEM KeyStore in
>>>>>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ .
>>>>>>
>>>>>> I wondered if it would make sense to integrate such an implementation
>>>>>> in one of the standard providers of OpenJDK - like the SUN provider.
>>>>>> What do you think?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>>    Karl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231017/a73e04e5/attachment-0001.htm>

From sviswanathan at openjdk.org  Tue Oct 17 18:05:13 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 17 Oct 2023 18:05:13 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
Message-ID: <_lBt1OmMnO2QRMX00Pto3q5Vre9A30WAjbBqzB51Dv0=.ebd6b351-78ae-440b-a2b2-92362cfadfe7@github.com>

On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments, removed unused labels

@TobiHartmann Please advice if we could integrate this or if you would like to run it through your testing first.

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1766906345

From rriggs at openjdk.org  Tue Oct 17 18:09:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 18:09:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
Message-ID: <2s6POSrQenTCvzxYraKH7J4oGJ4UqTiDl5ppDTYZ1fM=.fdb440b4-d33e-46e2-98b5-bd629b2b8c3e@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

Hacking around the exception types isn't a good fix.
If the exception is thrown, it is because of a charset conversion error.
IllegalArgumentException is for cases where the arguments are incorrect.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1683043411

From weijun at openjdk.org  Tue Oct 17 18:13:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Oct 2023 18:13:30 GMT
Subject: RFR: 8318328: DHKEM should check XDH name in case-insensitive mode
Message-ID: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>

The comparison should have been done in case-insensitive mode.

The new test confirms the change inside `DHKEM.java`. The one in `XDHPrivateKeyImpl.java` is not easy to confirm. The SUN provider's implementation always got the name "correct".

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

Commit messages:
 - the fix

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

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

From ascarpino at openjdk.org  Tue Oct 17 18:13:31 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 17 Oct 2023 18:13:31 GMT
Subject: RFR: 8318328: DHKEM should check XDH name in case-insensitive mode
In-Reply-To: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
References: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
Message-ID: <92cAZRivgZmtGyOelbBH93wYCi0N1ZjBwr1j8W2MxbI=.51c57e87-07a5-4dbd-a97a-52a9c91b427a@github.com>

On Tue, 17 Oct 2023 18:03:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The comparison should have been done in case-insensitive mode.
> 
> The new test confirms the change inside `DHKEM.java`. The one in `XDHPrivateKeyImpl.java` is not easy to confirm. The SUN provider's implementation always got the name "correct".

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16225#pullrequestreview-1683046543

From mullan at openjdk.org  Tue Oct 17 18:42:45 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 17 Oct 2023 18:42:45 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <um-_jxPkWzDFixhO0kbpndwJojZ_g5dUdHsndWzO_eQ=.367272cd-084d-4f0b-b19c-ff23335ae6d7@github.com>

On Tue, 17 Oct 2023 15:30:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add `getParams` to `PublicKey` and `PrivateKey` so it's available to all current and future public and private keys.
> 
> No test. Might add one.

src/java.base/share/classes/java/security/PrivateKey.java line 86:

> 84:      * The default implementation returns {@code null}.
> 85:      *
> 86:      * @return the associated parameters, may be null

Put `@code` around null. Same comment applies to other `getParams` methods.

src/java.base/share/classes/java/security/PrivateKey.java line 89:

> 87:      * @since 22
> 88:      */
> 89:     default AlgorithmParameterSpec getParams(){

Nit: add space before `{`. Same comment applies to other getParams methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1362598718
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1362597869

From mpowers at openjdk.org  Tue Oct 17 18:50:50 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 17 Oct 2023 18:50:50 GMT
Subject: RFR: 8318328: DHKEM should check XDH name in case-insensitive mode
In-Reply-To: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
References: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
Message-ID: <ZkkXj5UR0JGzCUt4x43bC9M3gb_halBa445W0lZ3voE=.139f5774-bb71-4e5b-bde2-2c6058164ab7@github.com>

On Tue, 17 Oct 2023 18:03:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The comparison should have been done in case-insensitive mode.
> 
> The new test confirms the change inside `DHKEM.java`. The one in `XDHPrivateKeyImpl.java` is not easy to confirm. The SUN provider's implementation always got the name "correct".

Looks good to me too.

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

PR Review: https://git.openjdk.org/jdk/pull/16225#pullrequestreview-1683131322

From hchao at openjdk.org  Tue Oct 17 19:27:41 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 17 Oct 2023 19:27:41 GMT
Subject: RFR: 8318328: DHKEM should check XDH name in case-insensitive mode
In-Reply-To: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
References: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
Message-ID: <YI-GN8LNVPfFIsUl367qkeStGooMCgCwI3FfsGL0YR8=.7dcb348d-7e5f-46fc-9303-f58fce6d7d63@github.com>

On Tue, 17 Oct 2023 18:03:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The comparison should have been done in case-insensitive mode.
> 
> The new test confirms the change inside `DHKEM.java`. The one in `XDHPrivateKeyImpl.java` is not easy to confirm. The SUN provider's implementation always got the name "correct".

Marked as reviewed by hchao (Committer).

Looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/16225#pullrequestreview-1683198437
PR Comment: https://git.openjdk.org/jdk/pull/16225#issuecomment-1767027432

From weijun at openjdk.org  Tue Oct 17 19:38:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Oct 2023 19:38:58 GMT
Subject: Integrated: 8318328: DHKEM should check XDH name in case-insensitive
 mode
In-Reply-To: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
References: <b0GQf-1AbhVLtM64MOcA38cM9k3yLcWXILqZ7FZa_y8=.7b561fc1-e9bd-4903-8f85-d789507b7f50@github.com>
Message-ID: <TjL8ua22e1kgXWtFUwatAUprCOKUjo3rnQxSSdAGVcc=.5aac4048-71c5-4701-8958-d97f6c527d3c@github.com>

On Tue, 17 Oct 2023 18:03:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The comparison should have been done in case-insensitive mode.
> 
> The new test confirms the change inside `DHKEM.java`. The one in `XDHPrivateKeyImpl.java` is not easy to confirm. The SUN provider's implementation always got the name "correct".

This pull request has now been integrated.

Changeset: 5145e5a4
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5145e5a40a8e9a87b3bc9f236dbf9e4b89094e46
Stats:     66 lines in 3 files changed: 63 ins; 0 del; 3 mod

8318328: DHKEM should check XDH name in case-insensitive mode

Reviewed-by: ascarpino, hchao

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

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

From weijun at openjdk.org  Tue Oct 17 19:48:26 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Oct 2023 19:48:26 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
 [v2]
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <w4sxToh8xC5WVMlMWmsbmhfVFkCRipprXusiupu1XUI=.2f30c056-e544-451d-a6bb-46f48c13a521@github.com>

> Add `getParams` to `PublicKey` and `PrivateKey` so it's available to all current and future public and private keys.
> 
> No test. Might add one.

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

  add spaces and code tags, and a test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16222/files
  - new: https://git.openjdk.org/jdk/pull/16222/files/9f2e4007..d0cf5c56

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

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

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

From hchao at openjdk.org  Wed Oct 18 00:25:02 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 18 Oct 2023 00:25:02 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

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

 - Merge
 - Override the client/server defaults
 - Change made to configure max allowed cert chain lengths based on updated CSR
 - Merge
 - Set to default if a negative value is set
 - 8311596: Add separate system properties for TLS server and client for maximum chain length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/2e264f94..aca5841a

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

  Stats: 9838 lines in 359 files changed: 6898 ins; 1383 del; 1557 mod
  Patch: https://git.openjdk.org/jdk/pull/15163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15163/head:pull/15163

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

From duke at openjdk.org  Wed Oct 18 04:46:48 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 18 Oct 2023 04:46:48 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
 [v2]
In-Reply-To: <w4sxToh8xC5WVMlMWmsbmhfVFkCRipprXusiupu1XUI=.2f30c056-e544-451d-a6bb-46f48c13a521@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <w4sxToh8xC5WVMlMWmsbmhfVFkCRipprXusiupu1XUI=.2f30c056-e544-451d-a6bb-46f48c13a521@github.com>
Message-ID: <bDpWzfVRxz96hp9LFggdHkgk41DRVBX9B02K2ThS1TU=.5bdb3006-a306-4b09-95bf-d70a9a0c24fd@github.com>

On Tue, 17 Oct 2023 19:48:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add `getParams` to `PublicKey` and `PrivateKey` so it's available to all current and future public and private keys.
>> 
>> No test. Might add one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add spaces and code tags, and a test

Would `getParameterSpec` be a better/more descriptive name, given that the thing it returns is an `AlgorithmParameterSpec`?

(Disclosure: Our security library (WildFly Elytron) has a `getParameterSpec` on every one of its key implementation classes... it would be serendipitous if it would retroactively fit in with this change!)

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

PR Comment: https://git.openjdk.org/jdk/pull/16222#issuecomment-1767631116

From dholmes at openjdk.org  Wed Oct 18 05:35:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Oct 2023 05:35:46 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <UVdVKMRqhPmOAI2RgE-kY1btCkHHJAdcOzPkOSdh9tY=.f6de512d-ac41-4c00-87fb-7554c6390052@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
 <UVdVKMRqhPmOAI2RgE-kY1btCkHHJAdcOzPkOSdh9tY=.f6de512d-ac41-4c00-87fb-7554c6390052@github.com>
Message-ID: <-mnRIhYxnLvgUVnwxr_thupKgzfav_NdaT79AS1PO7M=.7cb2174c-9808-42ea-beb7-312ebab3e683@github.com>

On Mon, 16 Oct 2023 15:04:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   windows aarch64 build issues
>
> Hello, any comments about the idea of calling into 'os::dll_load' instead ? That would indeed make the coding smaller and less 'messy' .

@MBaesken I'm not at all sure what it would look like - sorry. But there doesn't seem to be any general support from the library folk for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1767673904

From aturbanov at openjdk.org  Wed Oct 18 06:28:01 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 18 Oct 2023 06:28:01 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package [v3]
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <lKU_NAVjMzcSTvR0HnANyfsZuwWCmCa5SO_UQXejcEA=.5050dd6a-2ae9-48b1-9ab3-adf62ad11734@github.com>

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'origin/master' into final_fields_com.sun.crypto.provider
   
   # Conflicts:
   #	src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
 - Merge remote-tracking branch 'origin/master' into final_fields_com.sun.crypto.provider
   
   # Conflicts:
   #	src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
 - 8315974: Make fields final in 'com.sun.crypto.provider' package
   
   apply review suggestions
 - [PATCH]: Make fields final in com.sun.crypto.provider package

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

Changes: https://git.openjdk.org/jdk/pull/15412/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15412&range=02
  Stats: 117 lines in 31 files changed: 11 ins; 26 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/15412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15412/head:pull/15412

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

From aturbanov at openjdk.org  Wed Oct 18 08:04:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 18 Oct 2023 08:04:00 GMT
Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider'
 package [v3]
In-Reply-To: <lKU_NAVjMzcSTvR0HnANyfsZuwWCmCa5SO_UQXejcEA=.5050dd6a-2ae9-48b1-9ab3-adf62ad11734@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
 <lKU_NAVjMzcSTvR0HnANyfsZuwWCmCa5SO_UQXejcEA=.5050dd6a-2ae9-48b1-9ab3-adf62ad11734@github.com>
Message-ID: <PzPPD928-iF_ZhPpJfKIzTo-j77xNyyw1MqIzJ6W7w8=.3de41dda-3911-4b7e-9708-8a6bb3858d34@github.com>

On Wed, 18 Oct 2023 06:28:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into final_fields_com.sun.crypto.provider
>    
>    # Conflicts:
>    #	src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
>  - Merge remote-tracking branch 'origin/master' into final_fields_com.sun.crypto.provider
>    
>    # Conflicts:
>    #	src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
>  - 8315974: Make fields final in 'com.sun.crypto.provider' package
>    
>    apply review suggestions
>  - [PATCH]: Make fields final in com.sun.crypto.provider package

`jdk_security` tests are still green.
Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/15412#issuecomment-1767871228

From thartmann at openjdk.org  Wed Oct 18 08:30:13 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 18 Oct 2023 08:30:13 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
Message-ID: <po82ntYiKGLjUQN-15UbmhgM7lXPOxqVbwMkAWWRgzA=.306013e9-b26e-4edc-812c-05bc3439df9c@github.com>

On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments, removed unused labels

Sorry for the delay on our side. I submitted testing and will report back once it passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1767939001

From aturbanov at openjdk.org  Wed Oct 18 08:34:04 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 18 Oct 2023 08:34:04 GMT
Subject: Integrated: 8315974: Make fields final in 'com.sun.crypto.provider'
 package
In-Reply-To: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
References: <bqf4BD9vFBB5-JrwOTvAILvWIMAJ0tVghCLtP-I27AA=.376ede22-adc3-49f8-b9af-f2d8bf1eb77f@github.com>
Message-ID: <CyN-FlKeJ76f4xvQDVhXDuu5xv4N4K9_Xhh17GO_mV0=.a5368553-47c3-4010-8bfe-a1a74ecf7f94@github.com>

On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`.

This pull request has now been integrated.

Changeset: 4e77b3c3
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e77b3c378dd08470ebccd1ea2fe48f2819d3eac
Stats:     117 lines in 31 files changed: 11 ins; 26 del; 80 mod

8315974: Make fields final in 'com.sun.crypto.provider' package

Reviewed-by: valeriep

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

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

From karl.scheibelhofer at gmx.net  Wed Oct 18 10:00:08 2023
From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer)
Date: Wed, 18 Oct 2023 12:00:08 +0200
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
 <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
 <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>
 <A6282C7A-270C-48B5-BA36-87A54D6FF2A0@oracle.com>
 <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com>
Message-ID: <CACSnhuVo1=YFdKxomMQ5y-ECYHx2Wus_wXYthtJoa2XxR2vtYw@mail.gmail.com>

Hi Sean,

Yes, I can help with this new PEM API.

Let me know, when there is something to review.

Best regards,

Karl


On Tue, Oct 17, 2023, 19:12 Sean Mullan <sean.mullan at oracle.com> wrote:

> Hi Karl,
>
> I discussed your proposal with some other colleagues.
>
> We generally feel a PEM KeyStore would be a useful addition to the JDK.
> This would alleviate usability issues that many users encounter when
> configuring and deploying applications that store keys or certificates in
> PEM files.
>
> However, we would like to first make sure that your PEM KeyStore
> implementation will work well with the PEM API that we will be proposing
> soon. We think this is a perfect opportunity to ensure they work well
> together and would appreciate your help in reviewing and validating the API
> - would you be interested in helping out?
>
> Once that is done, we can discuss next steps.
>
> Thanks,
> Sean
>
>
> On Oct 5, 2023, at 9:41 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>
>
>
> On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer <karl.scheibelhofer at gmx.net>
> wrote:
>
> Hi Sean,
>
> Yes, I had a look at the Contributing docs at the OpenJDK site before. I
> also signed the OCA.
>
>
> Great, thanks.
>
>
> Honestly, I thought there would be some more reaction on the suggested PEM
> KeyStore. It would really be good to discuss the topic with others. Is
> there anything we can do to get others in sharing their thoughts on this?
>
>
> I think there is a fair amount of interest in it, but reviewing something
> significant like this takes a bit of time, as I mentioned in my prior
> email. Also, if we do decide to accept the contribution, we want to make
> sure it works well with the PEM API that we are working on - we hope to
> have a draft of a JEP for that out in the next few weeks. So I think we
> probably need a few weeks to review your contribution.
>
>
> There is already a fair amount of documentation und unit tests. See
> https://github.com/KarlScheibelhofer/java-crypto-tools/ .
>
>
> Ok.
>
> ?Sean
>
>
> Best regards,
> Karl
>
> On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mullan at oracle.com> wrote:
>
>> Hi Karl,
>>
>> The OpenJDK Developer?s Guide includes a helpful section on Contributing
>> to an OpenJDK Project [1]. I suggest you read through that if you have not
>> already. In particular, have you signed the OCA? I don?t want to review
>> your code/contribution until that is done.
>>
>> For this particular contribution, I don?t think there has been enough
>> discussion and evaluation from members of the Security project. This would
>> be a fairly major contribution. Keep in mind that a contribution doesn?t
>> mean the work ends there.  There would need to be documentation, tests, and
>> ongoing support for the foreseeable future. We need to think about these
>> aspects every time we add a new feature, so there needs to be a strong
>> motivation for doing it.
>>
>> Thanks,
>> Sean
>>
>> [1] https://openjdk.org/guide/#contributing-to-an-openjdk-project
>>
>> > On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer <
>> karl.scheibelhofer at gmx.net> wrote:
>> >
>> > Hi All,
>> >
>> > I would like to contribute my PEM KeyStore implementation to the
>> > OpenJDK, including integration in the OpenJDK source and creating a
>> > pull request.
>> > What is the recommended way to do this?
>> > Who can create a suitable ticket in OpenJDK to document the
>> > enhancement and to track the progress?
>> >
>> > What are the requirements for a pull request to get merged?
>> >
>> > Best regards
>> >
>> > Karl
>> >
>> > Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
>> > <karl.scheibelhofer at gmx.net>:
>> >>
>> >> Hi  Tony!
>> >>
>> >> When the PEM API implementation becomes available it would make sense
>> >> to use it inside the PEM Keystore implementation. It will reduce the
>> >> code (the internal classes PemReader und PemWriter may become
>> >> obsolete), but it does not affect the functionality of the PEM
>> >> keystore. Users of the PEM Keystore won't experience a difference.
>> >>
>> >> Let me know when there is something for the PEM API and I will see if
>> >> I can assist.
>> >>
>> >> I would suggest starting with PEM Keystore now and not wait for the
>> >> PEM API, because the time schedule for it seems vague. I would try to
>> >> refactor my current PEM Keystore implementation to integrate in the
>> >> OpenJDK sun.security.provider package. I do not expect any API changes
>> >> or other compatibility issues with existing code. Then consult this
>> >> group for feedback before creating a pull request.
>> >>
>> >> When the PEM API becomes available, rework the PEM Keystore
>> >> implementation to use it internally.
>> >>
>> >> What do you think?
>> >>
>> >> Best regards
>> >>
>> >>  Karl Scheibelhofer
>> >>
>> >> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
>> >> <anthony.scarpino at oracle.com>:
>> >>>
>> >>> There are no doc links yet.
>> >>>
>> >>> Tony
>> >>>
>> >>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
>> >>>> Hi Tony,
>> >>>>
>> >>>> The motivation was mostly about reading PEM keys and certificates
>> >>>> generated somewhere else. This is common practice in enterprise
>> >>>> environments I work in. Because corporate key material is subject to
>> >>>> centralized key management, including generation, backup and
>> rollover.
>> >>>> PEM is the format most software products can handle. For Java
>> >>>> applications, having a PEM KeyStore would reduce the often required
>> >>>> additional step of converting PEM key and certificate in a Java
>> >>>> Keystore/PKCS#12.
>> >>>> Even truststores handling is easier with individual PEM certificates
>> >>>> instead of a single PKCS#12 Truststore. Adding or deleting a single
>> >>>> file instead of replacing the complete PKCS#12 store is less error
>> >>>> prone and cleaner to track in version control. The additional benefit
>> >>>> of a MAC in PKCS#12 adds little to no security in most cases.
>> >>>> And being text based, PEM is more version control friendly than
>> binary PKCS#12.
>> >>>>
>> >>>> But to enable sound support of PEM, I also implemented writing PEM
>> >>>> keys and certificates. This way, one can use the JDK keytool to
>> >>>> generate key and certificate signing requests in PEM format. Getting
>> >>>> the certificate from the CA in PEM, one can use PEM throughout the
>> >>>> process.
>> >>>>
>> >>>> Do you have any links or documentation on the PEM API JEP that you
>> mentioned?
>> >>>>
>> >>>> Thank you for your feedback and best regards
>> >>>>
>> >>>>   Karl
>> >>>>
>> >>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
>> >>>> <anthony.scarpino at oracle.com>:
>> >>>>>
>> >>>>> Hi Karl
>> >>>>>
>> >>>>> The keystore is interesting and may have some value.  Was your use
>> case
>> >>>>> mostly reading PEM keys and certificates generated elsewhere for use
>> >>>>> with a particular application, maybe webservers?  Did you see value
>> in
>> >>>>> writing to this keystore from Java?
>> >>>>>
>> >>>>> On the topic of PEM, I hope before the end of the year to have a
>> PEM API
>> >>>>> JEP.  I would be interested in your API feedback from your keystore
>> >>>>> experiences.  I think if this keystore contribution was accepted, it
>> >>>>> should wait so it can use that API.
>> >>>>>
>> >>>>> thanks
>> >>>>>
>> >>>>> Tony
>> >>>>>
>> >>>>>
>> >>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> Working with Java and the JCA KeyStore for decades, I came across
>> >>>>>> many situations where I thought it would be convenient to be
>> >>>>>> able to load private keys and certificates in PEM format directly
>> >>>>>> using the KeyStore API. Without the need to convert them to
>> PKCS#12/JKS.
>> >>>>>>
>> >>>>>> You can find my implementation of a PEM KeyStore in
>> >>>>>>
>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$
>> .
>> >>>>>>
>> >>>>>> I wondered if it would make sense to integrate such an
>> implementation
>> >>>>>> in one of the standard providers of OpenJDK - like the SUN
>> provider.
>> >>>>>> What do you think?
>> >>>>>>
>> >>>>>> Best regards
>> >>>>>>
>> >>>>>>    Karl
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231018/6f6ef98b/attachment-0001.htm>

From sviswanathan at openjdk.org  Wed Oct 18 16:10:02 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 18 Oct 2023 16:10:02 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
Message-ID: <wziGYn-WAQitpnzhA11VzcakLR4dvB-wV7pldlGdBFk=.5389b531-f007-4f0f-86a6-180a5c6e2153@github.com>

On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments, removed unused labels

Thanks a lot Tobias!

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1768857138

From rriggs at openjdk.org  Wed Oct 18 16:30:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 16:30:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
Message-ID: <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array.  The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.  


     /**
       * Return a String constructed using the byte array containing latin1 (ISO-8859-1) characters.
       * The byte array must not be modified or otherwise referenced or used after the String is created.
       * If COMPACT_STRINGS is true the coder will be LATIN1 and the byte array is the string value;
       * otherwise the contents are inflated to create a UTF16 string.
       */ 
    public String newStringLatin1NoRepl(byte[] src) {
         if (COMPACT_STRINGS)
             return new String(src, LATIN1);
         return new String(StringLatin1.inflate(src, 0, src.length), UTF16);
    }

Creating strings from other encodings that may or have encoding errors should continue to use the current function and handle CCE as required.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768911569

From alanb at openjdk.org  Wed Oct 18 16:43:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 16:43:19 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
 <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>
Message-ID: <QBl1DscpCZvgH3CykHU0pGNGYqWxH9fO11mjjXrdYi0=.0f838a37-55e5-4bd0-89fd-954ad5f56245@github.com>

On Wed, 18 Oct 2023 16:27:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array. The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.

We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768937914

From valeriep at openjdk.org  Wed Oct 18 17:00:24 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Oct 2023 17:00:24 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <as_vb-RI4HPObOAXsBD2EdRYe2Yuv6HVOTKZR5_jE2k=.58da72d4-120a-4d2c-b672-19fc70303d13@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
 <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>
 <as_vb-RI4HPObOAXsBD2EdRYe2Yuv6HVOTKZR5_jE2k=.58da72d4-120a-4d2c-b672-19fc70303d13@github.com>
Message-ID: <6OZ_R0Ri5UwCxbZbgCh7oihtWjvZHj22LnGLdEfR7b0=.b740db28-8533-4450-aab4-ce0212895873@github.com>

On Mon, 16 Oct 2023 14:37:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 155:
>> 
>>> 153:     private static void exit(int exitCode) {
>>> 154:         throw new ExitException(exitCode);
>>> 155:     }
>> 
>> I don't see much benefit of this method since it's one-line to one-line. For other classes, it seems that value 0 is ok, but here an exception is thrown regardless of exit code value. Is this really intended?
>
> I'll inline the throw statements.
> 
> Yes, no matter if it's zero or not. Throwing the exception makes sure it jumps back to `run` immediately. If the code is 0, then the `main` method will return normally.

Hmm, interesting usage. Thanks for the explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1364229675

From aturbanov at openjdk.org  Wed Oct 18 17:33:29 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 18 Oct 2023 17:33:29 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v5]
In-Reply-To: <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>
Message-ID: <aB3NEKKs6f3sNfjQzR-u7SurFnf4mSGz2LzS8EgdkGs=.c511adab-10d5-490b-9100-b89e9f07821c@github.com>

On Mon, 16 Oct 2023 16:23:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>> 
>> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inline some throw statements, remove duplicated whitespaces

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kinit.java line 131:

> 129:         } catch (Exception e) {
> 130:             String msg;
> 131:             if (e instanceof KrbException) {

Let's simplify with pattern matching variable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1364260468

From valeriep at openjdk.org  Wed Oct 18 17:33:36 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Oct 2023 17:33:36 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v3]
In-Reply-To: <L9eOKBkrjv1sfeE_WLi0zp30dY7BoQRtdoOY746vwic=.1ca317b5-1879-424c-b952-aaffe4b932d9@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <5gXndDhs1WCJ1edww62Yxhn40XoI646-i5Qg_hi22FU=.3884c59b-0a71-41ec-8313-ab1b2c41af52@github.com>
 <E808cRdkKoHlMc45z10flZaypsALcB2kwT3IkLgRExw=.a0565e2d-38de-41f5-9f72-7d57d300f21d@github.com>
 <L9eOKBkrjv1sfeE_WLi0zp30dY7BoQRtdoOY746vwic=.1ca317b5-1879-424c-b952-aaffe4b932d9@github.com>
Message-ID: <n_SL2rxlQL2R8nuK7kOmOA5pAwzQnk-LKdGRmCJ24zc=.0a60ba6c-8dc2-4557-b65c-8af848431b92@github.com>

On Mon, 16 Oct 2023 14:32:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 82:
>> 
>>> 80:     }
>>> 81: 
>>> 82:     private static class ExitException extends RuntimeException {
>> 
>> If we want to use ExitException as internal exception, perhaps it's easier to not extending RuntimeException? This way we can rely on compiler to flag all methods which throw it and handle it accordingly.
>
> Well, not sure if makes code simpler. For the 3 tools where `ExitException` is used, all `run` methods explicitly catch it and returns the exit code. Therefore it's not likely to be ignored. On the other hand, if I make it a checked exception, I would need to add a lot (more than 10) of `throws ExitException` in methods where it could be thrown and they are noises to this code change.  After all, `ExitException` is unrecoverable and IMO should be a `RuntimeException`.

Yes, it comes with a price. It's up to you then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1364236882

From rriggs at openjdk.org  Wed Oct 18 17:39:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 17:39:13 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <QBl1DscpCZvgH3CykHU0pGNGYqWxH9fO11mjjXrdYi0=.0f838a37-55e5-4bd0-89fd-954ad5f56245@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
 <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>
 <QBl1DscpCZvgH3CykHU0pGNGYqWxH9fO11mjjXrdYi0=.0f838a37-55e5-4bd0-89fd-954ad5f56245@github.com>
Message-ID: <EeSotk1tQYJ-ulNRj9za1tACprxAICs1nm0z9tWWqy0=.7785f4da-1b9e-4fe2-8357-f34e99bb5648@github.com>

On Wed, 18 Oct 2023 16:39:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns.

Yes, adding another method in the "NoRepl" family needs to be done with care and be narrowly focused.
JLA already exposes several methods that allow the contents of strings to be read from the underlying value or created from caller provided buffers. All to avoid extra allocations and copying.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769026087

From duke at openjdk.org  Wed Oct 18 18:13:38 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 18 Oct 2023 18:13:38 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v7]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <T3rcRFWr66tdi5v5_iM8XltYJtSmH7d--6juXs8L1PQ=.cb41c071-c310-4c3d-9198-59c7968df070@github.com>

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

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

 - Merge branch 'openjdk:master' into latin1-no-repl
 - Use newStringLatin1NoRepl in UUID
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - update javadoc
 - clean newStringNoRepl1
 - clean newStringNoRepl1
 - Rename jla to JLA
 - Create new method JavaLangAccess::newStringLatin1NoRepl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/96788ddd..e92a877c

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

  Stats: 298265 lines in 6160 files changed: 131638 ins; 106892 del; 59735 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

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

From duke at openjdk.org  Wed Oct 18 18:17:24 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 18 Oct 2023 18:17:24 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
Message-ID: <ysDhEySjAnB44ap6qOosv_0-UH-zxpEly4lgJjW-bPY=.c938682a-950c-42e0-94be-b4cb61106400@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

Should we revisit https://github.com/openjdk/jdk/pull/14655?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769082700

From weijun at openjdk.org  Wed Oct 18 18:26:22 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 18 Oct 2023 18:26:22 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
 [v2]
In-Reply-To: <bDpWzfVRxz96hp9LFggdHkgk41DRVBX9B02K2ThS1TU=.5bdb3006-a306-4b09-95bf-d70a9a0c24fd@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <w4sxToh8xC5WVMlMWmsbmhfVFkCRipprXusiupu1XUI=.2f30c056-e544-451d-a6bb-46f48c13a521@github.com>
 <bDpWzfVRxz96hp9LFggdHkgk41DRVBX9B02K2ThS1TU=.5bdb3006-a306-4b09-95bf-d70a9a0c24fd@github.com>
Message-ID: <_Mb1EOnvYWjzmHNuEEFHnlTG7EtnNjqX5xT69on0vRE=.e650e4d3-166d-4d7f-81fe-d19d94ae806f@github.com>

On Wed, 18 Oct 2023 04:44:07 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Would `getParameterSpec` be a better/more descriptive name, given that the thing it returns is an `AlgorithmParameterSpec`?
> 
> (Disclosure: Our security library (WildFly Elytron) has a `getParameterSpec` on every one of its key implementation classes... it would be serendipitous if it would retroactively fit in with this change!)

We already have the `getParams` method everywhere and we are actually reusing that name and make all these methods a mesh (not a mess). If we create another method, there will be 2 ways to do the same thing and users will be confused. And we cannot simply deprecate the old one since that will be even more disruptive.

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

PR Comment: https://git.openjdk.org/jdk/pull/16222#issuecomment-1769095093

From duke at openjdk.org  Wed Oct 18 18:35:41 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 18 Oct 2023 18:35:41 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
 [v2]
In-Reply-To: <_Mb1EOnvYWjzmHNuEEFHnlTG7EtnNjqX5xT69on0vRE=.e650e4d3-166d-4d7f-81fe-d19d94ae806f@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <w4sxToh8xC5WVMlMWmsbmhfVFkCRipprXusiupu1XUI=.2f30c056-e544-451d-a6bb-46f48c13a521@github.com>
 <bDpWzfVRxz96hp9LFggdHkgk41DRVBX9B02K2ThS1TU=.5bdb3006-a306-4b09-95bf-d70a9a0c24fd@github.com>
 <_Mb1EOnvYWjzmHNuEEFHnlTG7EtnNjqX5xT69on0vRE=.e650e4d3-166d-4d7f-81fe-d19d94ae806f@github.com>
Message-ID: <PmfPFBXmMIqk27OBdvQKk9fdjjpJkJhS84ZQju9jc7I=.a33c4984-ae8b-4dcb-8ab4-7079f410dcfb@github.com>

On Wed, 18 Oct 2023 18:23:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > Would `getParameterSpec` be a better/more descriptive name, given that the thing it returns is an `AlgorithmParameterSpec`?
> 
> > 
> 
> > (Disclosure: Our security library (WildFly Elytron) has a `getParameterSpec` on every one of its key implementation classes... it would be serendipitous if it would retroactively fit in with this change!)
> 
> 
> 
> We already have the `getParams` method everywhere and we are actually reusing that name and make all these methods a mesh (not a mess). If we create another method, there will be 2 ways to do the same thing and users will be confused. And we cannot simply deprecate the old one since that will be even more disruptive.

Okay, I didn't know about the old name, that makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/16222#issuecomment-1769107414

From liach at openjdk.org  Thu Oct 19 07:11:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 07:11:18 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl to
 FailFast
Message-ID: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>

Please review a patch that renames `JavaLangAccess::newStringUTF8NoRepl` and `getBytesUTF8NoRepl` to `newStringUTF8FailFast` and `getBytesUTF8FailFast` to accurately describe these APIs. This also renames other associated methods.

NoRepl means "no replication", which is not what these APIs are for. They instead expose the fail-fast construction fast-path in String, allowing `ZipCoder` to quickly throw encoding exceptions wrapped in `IllegalArgumentException` without going through decoders and encoders.

In addition, there is already `newStringNoRepl` and `getBytesNoRepl` in `JavaLangAccess` that actually avoids copying arrays for trusted usages, further increasing the confusion. Given these internal APIs are frequently used in recent contributions around improving string performance, I believe a rename of these APIs is necessary.

Pinging @cl4es for a review since you use this particular API the most often.

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

Commit messages:
 - Rename JavaLangAccess.newString/getBytesUTF8NoRepl to FailFast

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

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

From liach at openjdk.org  Thu Oct 19 07:28:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 07:28:00 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl
 to FailFast
In-Reply-To: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
Message-ID: <57STR4aMtZ68n1J2al2cAed6kE6C5XRD_y29XKuyRlo=.b0debe5e-7439-48c3-9d14-3da6c6b2f498@github.com>

On Thu, 19 Oct 2023 07:04:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a patch that renames `JavaLangAccess::newStringUTF8NoRepl` and `getBytesUTF8NoRepl` to `newStringUTF8FailFast` and `getBytesUTF8FailFast` to accurately describe these APIs. This also renames other associated methods.
> 
> NoRepl means "no replication", which is not what these APIs are for. They instead expose the fail-fast construction fast-path in String, allowing `ZipCoder` to quickly throw encoding exceptions wrapped in `IllegalArgumentException` without going through decoders and encoders.
> 
> In addition, there is already `newStringNoRepl` and `getBytesNoRepl` in `JavaLangAccess` that actually avoids copying arrays for trusted usages, further increasing the confusion. Given these internal APIs are frequently used in recent contributions around improving string performance, I believe a rename of these APIs is necessary.
> 
> Pinging @cl4es for a review since you use this particular API the most often.

On second thought, an alternative solution is to consolidate the String access internal APIs into:

String newStringFailFast(byte[] bytes, Charset charset, boolean trusted);
byte[] getBytesFailFast(String string, Charset charset, boolean trusted);

These APIs will immediately throw encoding errors as an IAE with a CCE cause instead of silently performing a character substitution.

There are 2 flags we want to consider: `trusted` and `failFast`. 
| | `trusted == true` | `trusted == false`|
|-|--------|--------|
| __`failFast == true`__| Usual trusted scenario | Usual fail-fast scenario |
| __`failFast == false`__| Meaningless, if failure happens, trust is already broken | Can be done with public APIs | 

In conclusion, we can simplify the internal API to assume `failFast` holds true and only request a `trusted` flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1770215673

From alanb at openjdk.org  Thu Oct 19 07:28:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Oct 2023 07:28:01 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl
 to FailFast
In-Reply-To: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
Message-ID: <R2QvLkNx4clnvi8rAzfrxopnSHblwHSsar88kA9VpXk=.77dabbce-f92c-4eaa-9ea4-fe0d5b22c115@github.com>

On Thu, 19 Oct 2023 07:04:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> NoRepl means "no replication", which is not what these APIs are for. 

I assume it's "no replace", meaning it reports the error rather than use the coder's replacement value.

I agree it could be renamed but I think look at CodingErrorAction for the established terminology. Your suggestion for "fast fail" will create confusion as maintainers will be forced to wonder if there is potential for failing lazily.

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

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1770217422

From liach at openjdk.org  Thu Oct 19 09:03:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 09:03:38 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl
 to FailFast
In-Reply-To: <R2QvLkNx4clnvi8rAzfrxopnSHblwHSsar88kA9VpXk=.77dabbce-f92c-4eaa-9ea4-fe0d5b22c115@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
 <R2QvLkNx4clnvi8rAzfrxopnSHblwHSsar88kA9VpXk=.77dabbce-f92c-4eaa-9ea4-fe0d5b22c115@github.com>
Message-ID: <TUU4lzRbOjv0XalccB_mVABVoyZD3nAwFCoForntIzw=.1a2bf239-b8b6-4863-be3f-77cf5790709c@github.com>

On Thu, 19 Oct 2023 07:25:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume it's "no replace", meaning it reports the error rather than use the coder's replacement value.

This revelation is too important; I might have to reevaluate my choices, for many contributors have assumed that `NoRepl` was intended to avoid duplication instead of error substitution. That said, I will look for better solutions to en/decode strings with error reporting, or creating strings or accessing the arrays with trust (as seen in a recent FFM API string writing JLA addition)

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

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1770372141

From mbaesken at openjdk.org  Thu Oct 19 11:56:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 19 Oct 2023 11:56:39 GMT
Subject: RFR: 8318240: [AIX] Cleaners.java test failure
In-Reply-To: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
References: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
Message-ID: <p_KA_f0RsAdOrwsAMJq0e498FIBX_dlOxgEiTLQrpHw=.eae811a5-43d7-4d3e-97a7-1ee737dc6e01@github.com>

On Tue, 17 Oct 2023 07:31:07 GMT, Varada M <duke at openjdk.org> wrote:

> When the test sets the sun.security.jgss.native and sun.security.nativegss.debug as true, the test fails on AIX due to missing Kerberos GSS API dynamic library` libgssapi_krb5.so` 
> 
> JBS Issue : [JDK-8318240](https://bugs.openjdk.org/browse/JDK-8318240)

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16212#pullrequestreview-1687488869

From thartmann at openjdk.org  Thu Oct 19 15:10:05 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 19 Oct 2023 15:10:05 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
Message-ID: <OLNjpxDkghI8x-Zl7dL9lThCLa60xr1NMuKA9UOb0zA=.45721c97-67dc-4531-845c-41e4be8157e1@github.com>

On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi All, 
>> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
>> 
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
>> 
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
>> |-------------|------------|---------------|------------------|-----------|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
>> ? | ? | ? | ? | ?
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments, removed unused labels

All tests passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1771115519

From asteiner at openjdk.org  Thu Oct 19 15:13:49 2023
From: asteiner at openjdk.org (Andreas Steiner)
Date: Thu, 19 Oct 2023 15:13:49 GMT
Subject: RFR: 8318240: [AIX] Cleaners.java test failure
In-Reply-To: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
References: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
Message-ID: <D9fBdhxWP3GbpDNX7OBeNmaaeh1I9wJTzqMcWl10PNg=.8844b4d5-5c99-44e2-9699-ee431d851c5d@github.com>

On Tue, 17 Oct 2023 07:31:07 GMT, Varada M <duke at openjdk.org> wrote:

> When the test sets the sun.security.jgss.native and sun.security.nativegss.debug as true, the test fails on AIX due to missing Kerberos GSS API dynamic library` libgssapi_krb5.so` 
> 
> JBS Issue : [JDK-8318240](https://bugs.openjdk.org/browse/JDK-8318240)

Marked as reviewed by asteiner (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/16212#pullrequestreview-1688013499

From lkorinth at openjdk.org  Thu Oct 19 15:16:13 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:13 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Batch update using sed
   
   find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
 - Merge branch '_master_jdk' into _8315097
 - explain usage
 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
 - fix static import
 - copyright
 - 8315097: Rename createJavaProcessBuilder

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

Changes: https://git.openjdk.org/jdk/pull/15452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04
  Stats: 894 lines in 560 files changed: 34 ins; 10 del; 850 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From lkorinth at openjdk.org  Thu Oct 19 15:16:42 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:42 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
Message-ID: <3XTw5IAFj_YpaMrqyLdO9mNbWDENFMVkwk8JBmKHDcE=.5e4b1c70-0b36-4ff5-9cce-ee4f25a8e3bb@github.com>

On Tue, 17 Oct 2023 12:29:46 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

If this looks roughly acceptable, I will manually add indentation spaces. I am now running tests.

The changes can be verified by running the following commands:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9 

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"

git diff HEAD f80dda8d7109c2ef6bc1f685d0b611704dec645e


Only the documentation changes should be visible.  When I have manually indented everything it should be easy to that verify that change as a whitespace-only change. But that is for tomorrow (at best).

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1771194189

From svkamath at openjdk.org  Thu Oct 19 18:05:46 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 19 Oct 2023 18:05:46 GMT
Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions [v8]
In-Reply-To: <OLNjpxDkghI8x-Zl7dL9lThCLa60xr1NMuKA9UOb0zA=.45721c97-67dc-4531-845c-41e4be8157e1@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
 <Z07gvp5Pdq5aKfuNsjexqYgOo2tv_aCl-QEAnMMMlPs=.756b31ca-049d-4de1-bf2a-558d12c7e8b0@github.com>
 <OLNjpxDkghI8x-Zl7dL9lThCLa60xr1NMuKA9UOb0zA=.45721c97-67dc-4531-845c-41e4be8157e1@github.com>
Message-ID: <OBQDWVA5k_S6GeyaP9VVr43_Or-b142HA_6xGl0D6Po=.8f27a052-9439-450b-8b6d-b53ca37b6bb0@github.com>

On Thu, 19 Oct 2023 14:32:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated comments, removed unused labels
>
> All tests passed.

@TobiHartmann Thank you for running the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1771384900

From svkamath at openjdk.org  Thu Oct 19 18:32:17 2023
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 19 Oct 2023 18:32:17 GMT
Subject: Integrated: JDK-8314901: AES-GCM interleaved implementation using AVX2
 instructions
In-Reply-To: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
References: <B_-77vUi_vLOEXpttctZXh5zm8fTPfWx74zoEfMG77k=.98ac65e5-62d0-4486-a6c6-51b792a4fabe@github.com>
Message-ID: <F1P7J4MSQjaf4TIwg-_MvSNUrPrRNuGVH8-FO80Gv7M=.7ba1092c-e50c-4b0d-af72-6e5586ea1c3b@github.com>

On Thu, 24 Aug 2023 06:12:29 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> Hi All, 
> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations.
> 
> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option:
> 
> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup
> |-------------|------------|---------------|------------------|-----------|
> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
> small.AESGCMBench.decrypt | 8192 |  527854.353 |663131.48 | 1.25
> small.AESGCMBench.encrypt | 8192 |  548193.804 | 683624.232 |1.24
> full.AESGCMBench.decryptMultiPart | 8192 |  299865.766 | 299815.851 | 0.99
> full.AESGCMBench.encryptMultiPart | 8192 |  534406.564 |539235.462 | 1.00
> small.AESGCMBench.decryptMultiPart | 8192 |  299960.202 |298913.629 | 0.99
> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 16384 |  307266.364 |390397.778 | 1.27
> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
> small.AESGCMBench.decrypt | 16384 |  306257.801 | 389531.665 |1.27
> small.AESGCMBench.encrypt | 16384 |  311468.972 | 397804.753 | 1.27
> full.AESGCMBench.decryptMultiPart | 16384 |  159634.341 | 181271.487 | 1.13
> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 |  1.12
> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 32768 |  162284.703 | 213257.481 |1.31
> full.AESGCMBench.encrypt | 32768 |  164833.104 | 215568.639 | 1.30
> small.AESGCMBench.decrypt | 32768 |  164416.491 | 213422.347 | 1.29
> small.AESGCMBench.encrypt | 32768 |  166619.205 | 214584.208 |1.28
> full.AESGCMBench.decryptMultiPart | 32768 |  83306.239 | 93762.988 |1.12
> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 |  1.27
> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
> small.AESGCMBench.encryptMultiPart | 32768 |  162975.904 |212085.047 | 1.30
> ? | ? | ? | ? | ?
> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
> full.AESGCMBench.encrypt | 65536 |  86471.805 | 113320.536 |1.31
> small.AESGCMBench.decrypt | 65536 |  84490.816 | 112122.358 |1.32
> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 |  1.32
> full.AESGCMBench.decryptMultiPart | 65536 |  42649.816 | 47591.587 |1.11
> full.AESGCMBe...

This pull request has now been integrated.

Changeset: 17409500
Author:    Smita Kamath <svkamath at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17409500369bd8503782b2e6f4e885e33837087a
Stats:     706 lines in 8 files changed: 699 ins; 0 del; 7 mod

8314901: AES-GCM interleaved implementation using AVX2 instructions

Reviewed-by: sviswanathan, djelinski

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

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

From rhalade at openjdk.org  Thu Oct 19 19:47:13 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 19 Oct 2023 19:47:13 GMT
Subject: RFR: 8317373: Add Telia Root CA v2
Message-ID: <lXMnFPecXl7FaaKpTsRTVStPPTP_E9QNfYT8hfqB2w8=.0c59fa7a-6ba3-431b-a4e6-d76f23a6ebdf@github.com>

This PR is to add two new TLS root certificates from Telia. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.


The release-note is at [JDK-8318472](https://bugs.openjdk.org/browse/JDK-8318472)

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

Commit messages:
 - 8317373: Add Telia Root CA v2

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

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

From Nico.Williams at twosigma.com  Thu Oct 19 22:09:16 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Thu, 19 Oct 2023 22:09:16 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/ native
 GSS introduced by 8303809
Message-ID: <20231019220916.GG202255@twosigma.com>

# Crashes

We recently upgrade to OpenJDK 17.0.8.1 and started observing crashes
resulting from double-frees via `gss_delete_sec_context()`. 

Adding `-Djdk.spnego.cache=false` to our java invocations stops the
crashes.  We believe this is due to a race condition that has long been
in `HttpURLConnection` that was mostly harmless before but which with
the addition of this commit:

    16843770b5a 8303809: Dispose context in SPNEGO NegotiatorImpl

became a use-after-free / double-free bug, leading to crashes.

This happens with stock 17.0.8.1+1 from Adoptium.

Attached is a reproducer, Test.java, which you can run like this:

    $ # credendials are kinit user at jgssbug.twosigma.com, password password
    $ #
    $ "$JAVA_HOME/bin/java" \
              -Dsun.security.jgss.native=true \
              -Dsun.security.jgss.lib=/usr/lib/libgssapi_krb5.so \
              Test.java https://kerberos.club/tmp/jgssbug.txt

It doesn't crash every time, but it crashes often.

A typical Java stack trace upon crashing looks like:

j  sun.security.jgss.wrapper.GSSLibStub.deleteContext(J)J+0 java.security.jgss at 17.0.8.1
j  sun.security.jgss.wrapper.NativeGSSContext.dispose()V+76 java.security.jgss at 17.0.8.1
j  sun.security.jgss.GSSContextImpl.dispose()V+16 java.security.jgss at 17.0.8.1
j  sun.net.www.protocol.http.spnego.NegotiatorImpl.disposeContext()V+11 java.security.jgss at 17.0.8.1
J 4456 c1 sun.net.www.protocol.http.NegotiateAuthentication.disposeContext()V java.base at 17.0.8.1 (24 bytes) @ 0x00007f909dc33834 [0x00007f909dc337c0+0x0000000
000000074]
j  sun.net.www.protocol.http.HttpURLConnection.getInputStream0()Ljava/io/InputStream;+1923 java.base at 17.0.8.1
j  sun.net.www.protocol.http.HttpURLConnection.getInputStream()Ljava/io/InputStream;+62 java.base at 17.0.8.1
j  sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream()Ljava/io/InputStream;+4 java.base at 17.0.8.1
j  Test.lambda$main$0()V+16
j  Test$$Lambda$207+0x00007f9020144208.run()V+0
j  java.lang.Thread.run()V+11 java.base at 17.0.8.1
v  ~StubRoutines::call_stub

On the C side the crash typically happens in the allocator, typically in
`free()`:

#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fb6e1185535 in __GI_abort () at abort.c:79
#2  0x00007fb6e11dc648 in __libc_message (action=action at entry=do_abort, fmt=fmt at entry=0x7fb6e12e62a0 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007fb6e11e2d6a in malloc_printerr (str=str at entry=0x7fb6e12e444e "free(): invalid pointer") at malloc.c:5359
#4  0x00007fb6e11e459c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4180
#5  0x00007fb582ba5b6d in krb5_free_address (context=context at entry=0x7fb5d80cbf60, val=0x7fb5d8000080) at kfree.c:62
#6  0x00007fb582b93d9e in krb5_auth_con_free (context=context at entry=0x7fb5d80cbf60, auth_context=0x7fb5d80778a0) at auth_con.c:60
#7  0x00007fb6440a3eec in krb5_gss_delete_sec_context (minor_status=0x7fb586868504, context_handle=0x7fb5d80e22d0, output_token=<optimized out>)
    at delete_sec_context.c:77
#8  0x00007fb6440964b0 in gssint_delete_internal_sec_context (minor_status=0x7fb586868504, mech_type=<optimized out>,
    internal_ctx=internal_ctx at entry=0x7fb5d80e22d0, output_token=0x0) at g_glue.c:606
#9  0x00007fb6440946dd in gss_delete_sec_context (minor_status=<optimized out>, context_handle=0x7fb5d80d2be8, output_token=<optimized out>)
    at g_delete_sec_context.c:91
#10 0x00007fb6440b8dfe in spnego_gss_delete_sec_context (minor_status=<optimized out>, context_handle=0x7fb5d807bd70, output_token=<optimized out>)
    at spnego_mech.c:2161
#11 0x00007fb6440964b0 in gssint_delete_internal_sec_context (minor_status=0x7fb586868504, mech_type=<optimized out>,
    internal_ctx=internal_ctx at entry=0x7fb5d807bd70, output_token=0x0) at g_glue.c:606
#12 0x00007fb6440946dd in gss_delete_sec_context (minor_status=<optimized out>, context_handle=0x7fb586868508, output_token=<optimized out>)
    at g_delete_sec_context.c:91
#13 0x00007fb6dc0559ff in Java_sun_security_jgss_wrapper_GSSLibStub_deleteContext () from /home/nico/tmp/jdk-17.0.8.1+1/lib/libj2gss.so
#14 0x00007fb6c89a653a in ?? ()
#15 0x0000000000000000 in ?? ()

We've seen other variations, but always they can be traced to
`HttpURLConnection`.

(We do maintain local patches to OpenJDK JGSS code as well.  But that's
a story for another time.  We do want to try again to upstream those
patches.  Because we maintain such patches we developed an interim fix
where we use `synchronized (lock)` in the JGSS `dispose()` methods and
also `Reference.reachabilityFence(this)`, which worked to prevent the
crashes, but that was before we learned that `-Djdk.spnego.cache=false`
also works.  In any case, stock, unpatched OpenJDK 17.0.8.1 evinces this
crasher.)

# Root cause

What 8303809 did was add calls to `dispose()` on `GSSContext` objects in
NegotiatorImpl.java in a new method called `disposeContext()` that all
HTTP authentication mechanisms now implement and which 8303809 also
added.

It took us a while to realize that the use of the `AuthCache` in
`HttpURLConnection` implies concurrent access to the cached contexts via
concurrent HTTP requests to the same origin.

Concurrent access to and disposal of those context objects then leads to
use-after-free / double-free errors when using sun.security.jgss.native.

There's really several issues going on here:

 - The `dispose()` methods in 17.x in the JGSS native C GSS bindings
   clases are dangerous, as are finalizers generally (and these
   `dispose()` methods are called from finalizers).

   This is fixed in later OpenJDK releases by making use of `Cleaner`,
   so there's not much more to say about this here.

 - The `AuthCache` in `src/java.base/share/classes/sun/net/www/protocol/http/`
   implies concurrency, and it's not clear that concurrency is allowable
   in all cases.

 - In the case of RFC 4559 "Negotiate" and GSS concurrency is very much
   not permitted.  The GSS APIs can and should be thread-safe, but it is
   still an error to invoke `initSecContext()` concurrently on the same
   `GSSContext`!

   GSS-API `initSecContext()`/`acceptSecContext()` are strictly
   synchronous and serial.

 - The `AuthCache` in `src/java.base/share/classes/sun/net/www/protocol/http/`
   is likely a misfeature altogether, at least as far as sharing GSS-
   like HTTP authentication mechanism contexts goes, and probably for
   all other HTTP auth methods too.

   It's not ok to take a reply token from a `WWW-Authenticate:` response
   header and consume it together with a "context" created by a
   unrelated request [to the same origin].

   Every `WWW-Authenticate:`/`Authorization:` token must be matched to
   the same [serial train of] request[s].

   Thus if we have an RFC 4559 Negotiate exchange requiring 5 tokens, so
   something like:

   0: request..
   1: 401 response w/ WWW-Authenticate: Negotiate
   2: request w/ Authorization: Negotiate ...           (continue needed)
   3: 200 response w/ WWW-Authenticate: Negotiate ...   (continue needed)
   4: request w/ Authorization: Negotiate ...           (continue needed)
   5: 200 response w/ WWW-Authenticate: Negotiate ...   (complete)

   it would not be permissible for one of those reply tokens to be fed
   to another request's GSSContext, nor would it be OK to have more than
   one serial set of requests share the same GSSContext.

 - The foregoing also applies to SCRAM, DIGEST-MD5, and just about any
   and all HTTP authentication methods that I know.  I believe that
   there is no value in caching HTTP authentication mechanism contexts
   on the client side.

   HTTP Authentication mechanisms like SCRAM and DIGEST-MD5 are
   three-message mechanisms when counting the initial challenge:

   0: request...
   1: 401 response w/ WWW-Authenticate: DIGEST-MD5 <challenge>
   2: request w/ Authorization: DIGEST-MD5 ...
   3: 200 w/ WWW-Authenticate: DIGEST-MD5 ... (complete)

   There is no case in which caching and sharing a SCRAM or DIGEST-MD5
   authentication context is useful because there is only one request/
   response in which there is a context needed at all: between 2 and 3
   inclusive in the above diagram.

   Perhaps a single challenge can be shared with multiple subsequent
   requests that will optimistically use SCRAM or DIGEST-MD5 knowing
   that one response demanded it, but one should probably not do this,
   though I could find nothing in RFC 5802 and 7677.

 - Negotiate is really a bearer token system, albeit with the
   possibility of using channel bindings.  Meaning we never use the
   resulting GSSContext to encrypt or sign any part of the HTTP requests
   and responses authenticated with that context.  Therefore there's
   never any point in sharing a GSSContext in HTTP, not even once it's
   fully-established -- there is no point in doing anything other than
   disposing of a fully-established GSSContext in HTTP/Negotiate.

   (Attempts to develop standards for encrypting/signing of HTTP
   requests and responses at the HTTP layer rather than in TLS have
   historically failed.  If one attempt to standardize such a thing
   succeeds, _then_ there will be something worth sharing in a cache
   with care to prevent use-after-dispose.)

 - Because of the preceding, in HTTP/Negotiate it is desirable to "free"
   any GSSContext immediately after it is complete.

   This is presumably how you came to add the `disposeContext()` method:
   because those cached contexts otherwise sit there using lots of
   memory for no reason; someone must have noticed.  However, rather
   than have an explicit `disposeContext()` these contexts should just
   immediately be disposed of when complete or failed.

# Possible fixes

 - Backport the use of `Cleaner` in the JGSS `dispose()` methods.

   This would not be very satisfying because the `HttpURLConnection`
   `AuthCache` would remain buggy, but at least the JVM wouldn't crash.

 - Default `jdk.spnego.cache` to `false`.

 - Rethink or remove the `AuthCache` in `HttpURLConnection`.

 - Something else?

Thanks,

Nico
-- 

From Nico.Williams at twosigma.com  Thu Oct 19 22:57:37 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Thu, 19 Oct 2023 22:57:37 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <20231019220916.GG202255@twosigma.com>
References: <20231019220916.GG202255@twosigma.com>
Message-ID: <SJ0PR08MB6783924D291B40DDA0325E8B85D4A@SJ0PR08MB6783.namprd08.prod.outlook.com>

I failed to include the reproducer, which is:

import java.net.*;

public class Test {
    public static void main(String[] args) {
        for (int i = 0; i < 500; i++) {
            new Thread(() -> {
                    try {
                        URL url = new URL(args[0]);
                        var huc = url.openConnection();
                        huc.getInputStream().readAllBytes();
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
            }).start();
        }
        System.out.print(".");
    }
}

From valeriep at openjdk.org  Fri Oct 20 00:15:36 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 20 Oct 2023 00:15:36 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v5]
In-Reply-To: <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>
Message-ID: <2XezQ6_OIuoxQw28G1Cd21yGyRJT8BSMxbWsknNqcFY=.3ed5e683-f2c0-4097-881f-4d65b77499f7@github.com>

On Mon, 16 Oct 2023 16:23:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>> 
>> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inline some throw statements, remove duplicated whitespaces

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 425:

> 423:     }
> 424: 
> 425:     public int run(String[] args, PrintStream out) throws Exception {

Is this run() method used outside of this class, and thus the scope change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1366269790

From weijun at openjdk.org  Fri Oct 20 01:15:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 20 Oct 2023 01:15:35 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v5]
In-Reply-To: <2XezQ6_OIuoxQw28G1Cd21yGyRJT8BSMxbWsknNqcFY=.3ed5e683-f2c0-4097-881f-4d65b77499f7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>
 <2XezQ6_OIuoxQw28G1Cd21yGyRJT8BSMxbWsknNqcFY=.3ed5e683-f2c0-4097-881f-4d65b77499f7@github.com>
Message-ID: <KKQNBms8DaxByZ-84VO_1FIi4kyszZ_sC6cpxhNgCLQ=.a4f6a2ad-1cb0-429d-8046-5d97869a177c@github.com>

On Fri, 20 Oct 2023 00:12:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   inline some throw statements, remove duplicated whitespaces
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 425:
> 
>> 423:     }
>> 424: 
>> 425:     public int run(String[] args, PrintStream out) throws Exception {
> 
> Is this run() method used outside of this class, and thus the scope change?

This allows the tools to be called externally. These are still non-public APIs but at least with some `--add-exports` it can be called elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1366319639

From liach at openjdk.org  Fri Oct 20 02:29:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 02:29:15 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError [v2]
In-Reply-To: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
Message-ID: <cx9pgdiMSuOQWVFVl8bG-xmqHpKRtT5AxIgQvxcJgNA=.d09c998d-52ab-4fa1-b280-c8fc64afdbe2@github.com>

> Please review a patch that renames `JavaLangAccess::newStringUTF8NoRepl` and `getBytesUTF8NoRepl` to `newStringUTF8FailFast` and `getBytesUTF8FailFast` to accurately describe these APIs. This also renames other associated methods.
> 
> NoRepl means "no replication", which is not what these APIs are for. They instead expose the fail-fast construction fast-path in String, allowing `ZipCoder` to quickly throw encoding exceptions wrapped in `IllegalArgumentException` without going through decoders and encoders.
> 
> In addition, there is already `newStringNoRepl` and `getBytesNoRepl` in `JavaLangAccess` that actually avoids copying arrays for trusted usages, further increasing the confusion. Given these internal APIs are frequently used in recent contributions around improving string performance, I believe a rename of these APIs is necessary.
> 
> Pinging @cl4es for a review since you use this particular API the most often.

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

  NoRepl -> ReportError

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16260/files
  - new: https://git.openjdk.org/jdk/pull/16260/files/1af50e96..3a94643c

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

  Stats: 240 lines in 10 files changed: 95 ins; 96 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/16260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16260/head:pull/16260

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

From liach at openjdk.org  Fri Oct 20 02:32:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 02:32:35 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError [v2]
In-Reply-To: <cx9pgdiMSuOQWVFVl8bG-xmqHpKRtT5AxIgQvxcJgNA=.d09c998d-52ab-4fa1-b280-c8fc64afdbe2@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
 <cx9pgdiMSuOQWVFVl8bG-xmqHpKRtT5AxIgQvxcJgNA=.d09c998d-52ab-4fa1-b280-c8fc64afdbe2@github.com>
Message-ID: <KoIXp5EugYBeOZmJOI5MfgT8oz1wFREYBRn7P0FDKbY=.b462aaed-0b4e-47c9-931d-d2cceac7e083@github.com>

On Fri, 20 Oct 2023 02:29:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review a patch that renames `JavaLangAccess::xxNoRepl` to `xxReportError` to explicitly indicate these APIs report encoding errors.
>> 
>> The old "NoRepl" suffix presumably means "No Replacement", but it has been misunderstood as "No Replication" (#16209) and misused as an array sharing API in performance optimization patches.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoRepl -> ReportError

I have decided to rename `NoRepl` to `ReportError`, as it corresponds to `CodingErrorAction.REPORT`. I have replaced all `NoRepl` occurrences I've found with `ReportError`, including in tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1771979541

From Nico.Williams at twosigma.com  Fri Oct 20 02:39:06 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 20 Oct 2023 02:39:06 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <20231019220916.GG202255@twosigma.com>
References: <20231019220916.GG202255@twosigma.com>
Message-ID: <SJ0PR08MB67839FAED36BC3BAD03CCF8E85DBA@SJ0PR08MB6783.namprd08.prod.outlook.com>

Also, a colleague informs me that 17.0.5 (as packaged by Debian) w/o `-Djdk.spnego.cache=false` doesn't exhibit the double-free/use-after-free crashes (as expected), but:

> I do see some "Authentication failure" / and "java.lang.NullPointerException: Cannot invoke "sun.net.www.protocol.http.Negotiator.nextToken(byte[])" because "this.negotiator" is null".

That seems to support the idea that the `AuthCache` is harmful.

Nico
--




From liach at openjdk.org  Fri Oct 20 04:35:39 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 04:35:39 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v7]
In-Reply-To: <T3rcRFWr66tdi5v5_iM8XltYJtSmH7d--6juXs8L1PQ=.cb41c071-c310-4c3d-9198-59c7968df070@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <T3rcRFWr66tdi5v5_iM8XltYJtSmH7d--6juXs8L1PQ=.cb41c071-c310-4c3d-9198-59c7968df070@github.com>
Message-ID: <Cx-OcJoi-2Jn7U4Dj3iH681jVAeABunNYi6wCoYJqE8=.a7aefad7-0e9f-4b01-b542-9d90b5965861@github.com>

On Wed, 18 Oct 2023 18:13:38 GMT, Glavo <duke at openjdk.org> wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Use newStringLatin1NoRepl in UUID
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

See [#16260](https://github.com/openjdk/jdk/pull/16260#issuecomment-1770217422): `NoRepl` means to report encoding error as CCE. The API you are creating should be renamed to something like `newTrustedLatin1String` as we don't check encoding errors and this API solely focuses on sharing the array.

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

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1772064234

From lkorinth at openjdk.org  Fri Oct 20 08:34:35 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 20 Oct 2023 08:34:35 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>
Message-ID: <CQLu4BqqXQpv1m-Z4mKvfK890bjfytSkMMBunchwlmc=.95e9f73e-0275-4dcf-bdbb-707ce50c4902@github.com>

On Thu, 19 Oct 2023 15:16:13 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Batch update using sed
>    
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
>  - Merge branch '_master_jdk' into _8315097
>  - explain usage
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
>  - fix static import
>  - copyright
>  - 8315097: Rename createJavaProcessBuilder

Just ignore what I just pushed, I will have a new version out

sorry...

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309579
PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309992

From duke at openjdk.org  Fri Oct 20 11:38:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 20 Oct 2023 11:38:40 GMT
Subject: Withdrawn: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <x5p2cxiUOf-lSt4fUmTgnJs78qp195fQXGslzu0PSaY=.142d5d6a-9552-4ff7-9934-920bd5baa362@github.com>

On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

This pull request has been closed without being integrated.

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

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

From mullan at openjdk.org  Fri Oct 20 12:29:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Oct 2023 12:29:36 GMT
Subject: RFR: 8317373: Add Telia Root CA v2
In-Reply-To: <lXMnFPecXl7FaaKpTsRTVStPPTP_E9QNfYT8hfqB2w8=.0c59fa7a-6ba3-431b-a4e6-d76f23a6ebdf@github.com>
References: <lXMnFPecXl7FaaKpTsRTVStPPTP_E9QNfYT8hfqB2w8=.0c59fa7a-6ba3-431b-a4e6-d76f23a6ebdf@github.com>
Message-ID: <WQ_y3O4TF0R35ftbnzhaHv40B2B-jrLCy2TISqKlVwk=.da291b80-564e-4623-ba83-d07cd2abd5ae@github.com>

On Thu, 19 Oct 2023 19:40:24 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

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

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16275#pullrequestreview-1689926917

From weijun.wang at oracle.com  Fri Oct 20 13:42:44 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 20 Oct 2023 13:42:44 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <SJ0PR08MB67839FAED36BC3BAD03CCF8E85DBA@SJ0PR08MB6783.namprd08.prod.outlook.com>
References: <20231019220916.GG202255@twosigma.com>
 <SJ0PR08MB67839FAED36BC3BAD03CCF8E85DBA@SJ0PR08MB6783.namprd08.prod.outlook.com>
Message-ID: <DB505C3E-C853-4F48-9015-3BA34DFAE44A@oracle.com>

Hi Nico,

I've filed a bug at https://bugs.openjdk.org/browse/JDK-8318599. Will look into it.

Thanks,
Max

> On Oct 19, 2023, at 10:39 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> Also, a colleague informs me that 17.0.5 (as packaged by Debian) w/o `-Djdk.spnego.cache=false` doesn't exhibit the double-free/use-after-free crashes (as expected), but:
> 
>> I do see some "Authentication failure" / and "java.lang.NullPointerException: Cannot invoke "sun.net.www.protocol.http.Negotiator.nextToken(byte[])" because "this.negotiator" is null".
> 
> That seems to support the idea that the `AuthCache` is harmful.
> 
> Nico
> --
> 
> 
> 


From Nico.Williams at twosigma.com  Fri Oct 20 16:50:12 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 20 Oct 2023 16:50:12 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <DB505C3E-C853-4F48-9015-3BA34DFAE44A@oracle.com>
References: <20231019220916.GG202255@twosigma.com>
 <SJ0PR08MB67839FAED36BC3BAD03CCF8E85DBA@SJ0PR08MB6783.namprd08.prod.outlook.com>
 <DB505C3E-C853-4F48-9015-3BA34DFAE44A@oracle.com>
Message-ID: <20231020165012.GA1617108@twosigma.com>

On Fri, Oct 20, 2023 at 01:42:44PM +0000, Wei-Jun Wang wrote:
> I've filed a bug at https://bugs.openjdk.org/browse/JDK-8318599. Will look into it.

Thanks Max!

A comment if I may (did I ever complete my bugs.openjdk.org account setup?):

This is primarily a bug in HttpURLConnection and related classes, not really a
JGSS bug, so either a second issue should be opened for HttpURLConnection /
core-libs, or JDK-8318599 should be moved to core-libs.

Also, the HttpURLConnection issue should be higher than P4 in my opinion, even
if there is a workaround (`-Djdk.spnego.cache=false`).  At the very least there
should be a high-priority issue to default `jdk.spnego.cache` to `false` in the
interim and then a lower-priority issue to fix the `AuthCache` issues.

Also, we're not asking for the fixes to the `dispose()` hazards in JGSS to be
backported, though we're not opposed to it either :)

Nico
-- 

From xuelei at openjdk.org  Fri Oct 20 17:22:36 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 20 Oct 2023 17:22:36 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>
Message-ID: <colncAa5fScnKt-cn2Cm_EG4OaifiHr9XZafBg2bWUg=.9c235083-e953-4143-a445-24ce9132d638@github.com>

On Wed, 18 Oct 2023 00:25:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Override the client/server defaults
>  - Change made to configure max allowed cert chain lengths based on updated CSR
>  - Merge
>  - Set to default if a negative value is set
>  - 8311596: Add separate system properties for TLS server and client for maximum chain length

I was wondering, if it is easier to learn and remember/search by following the naming style "jdk.tls.client.XXX" or "jdk.tls.server.XXX" in SunJSSE provider?

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

PR Comment: https://git.openjdk.org/jdk/pull/15163#issuecomment-1773113371

From rhalade at openjdk.org  Fri Oct 20 18:28:44 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 20 Oct 2023 18:28:44 GMT
Subject: Integrated: 8317373: Add Telia Root CA v2
In-Reply-To: <lXMnFPecXl7FaaKpTsRTVStPPTP_E9QNfYT8hfqB2w8=.0c59fa7a-6ba3-431b-a4e6-d76f23a6ebdf@github.com>
References: <lXMnFPecXl7FaaKpTsRTVStPPTP_E9QNfYT8hfqB2w8=.0c59fa7a-6ba3-431b-a4e6-d76f23a6ebdf@github.com>
Message-ID: <2HYSqkbJ0vx-V04-s596J5SinlU4BvF1V2hhUborZd8=.b7099206-9cc1-498e-a803-9924f707c2fa@github.com>

On Thu, 19 Oct 2023 19:40:24 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: d3ebb4a1
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3ebb4a155be8ed93e79b6b58c645e861ec30267
Stats:     58 lines in 3 files changed: 55 ins; 0 del; 3 mod

8317373: Add Telia Root CA v2

Reviewed-by: mullan

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

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

From kdriver at openjdk.org  Fri Oct 20 18:42:34 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 20 Oct 2023 18:42:34 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <KaEh8G7eu-lnGhgTwltnl8MFlGJ_wq0BnxNlLRcq5Zc=.fe12e0df-ea88-4559-ab8a-ccab4b6b0a4b@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <KaEh8G7eu-lnGhgTwltnl8MFlGJ_wq0BnxNlLRcq5Zc=.fe12e0df-ea88-4559-ab8a-ccab4b6b0a4b@github.com>
Message-ID: <0CYtR-nFB0bA0oNcU1aLYcRY5JtYt5D18ihaYG3v-5A=.b2a11b36-c833-430d-882e-243cb4188a18@github.com>

On Mon, 7 Aug 2023 15:48:08 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge
>>  - Override the client/server defaults
>>  - Change made to configure max allowed cert chain lengths based on updated CSR
>>  - Merge
>>  - Set to default if a negative value is set
>>  - 8311596: Add separate system properties for TLS server and client for maximum chain length
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 150:
> 
>> 148:      */
>> 149:     static {
>> 150:         Integer clientLen = GetIntegerAction.privilegedGetProperty(
> 
> I think you could call `privilegedGetProperty` with the default value as second argument.

If I'm looking at the latest version, I don't see @mcpowers suggestion implemented. He's suggesting using the method with this signature: 


public static String privilegedGetProperty(String theProp, String defaultVal)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1367380332

From mdonovan at openjdk.org  Fri Oct 20 19:24:42 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 20 Oct 2023 19:24:42 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer
Message-ID: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>

Hello,

In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.

Thanks

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

Commit messages:
 - 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and newer

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

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

From erikj at openjdk.org  Fri Oct 20 21:36:34 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 20 Oct 2023 21:36:34 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <OjMJ6zM3GWEXHRBHS7td9VyIMOnHCJyS_LT_uD_ksS4=.22497608-75d5-408c-815c-74b10a146375@github.com>

On Fri, 20 Oct 2023 19:18:47 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

doc/testing.md line 605:

> 603: correctly, the system property `jdk.test.lib.artifacts.<NAME>` is required on Ubuntu 18.04
> 604: to specify the alternative NSS lib directories. The `<NAME>` component should be replaced
> 605: with the name of the appropriate `@Artfact` class. (See `test/jdk/sun/security/pkcs11/PKCS11Test.java`)

Could you please adjust the line length to match the surrounding text.

When changing any `doc/*.md` file, you will need to regenerate the corresponding html files and include that update in the commit. This can be done with the following make target if you have an appropriate pandoc configured.

make update-build-docs

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1367499783

From hchao at openjdk.org  Fri Oct 20 22:09:36 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 20 Oct 2023 22:09:36 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <0CYtR-nFB0bA0oNcU1aLYcRY5JtYt5D18ihaYG3v-5A=.b2a11b36-c833-430d-882e-243cb4188a18@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <KaEh8G7eu-lnGhgTwltnl8MFlGJ_wq0BnxNlLRcq5Zc=.fe12e0df-ea88-4559-ab8a-ccab4b6b0a4b@github.com>
 <0CYtR-nFB0bA0oNcU1aLYcRY5JtYt5D18ihaYG3v-5A=.b2a11b36-c833-430d-882e-243cb4188a18@github.com>
Message-ID: <cUNe99CL8lILysDStvgg_yp3EXurAs08WXcB6d1f37M=.7b7f2335-bf74-48a6-8185-9a27543ac695@github.com>

On Fri, 20 Oct 2023 18:39:38 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 150:
>> 
>>> 148:      */
>>> 149:     static {
>>> 150:         Integer clientLen = GetIntegerAction.privilegedGetProperty(
>> 
>> I think you could call `privilegedGetProperty` with the default value as second argument.
>
> If I'm looking at the latest version, I don't see @mcpowers suggestion implemented. He's suggesting using the method with this signature: 
> 
> 
> public static String privilegedGetProperty(String theProp, String defaultVal)

I did update the code with his suggestion, and please see it in webrev **01: Incremental.**  However, I further change the code based on the updated CSR, that the new client and server properties have different default values now  from the existing property, and the need to know whether the new property is explicitly set or not. We want to make sure the new properties are not overridden when they are set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1367517385

From duke at openjdk.org  Sat Oct 21 15:05:57 2023
From: duke at openjdk.org (Ismael Juma)
Date: Sat, 21 Oct 2023 15:05:57 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v21]
In-Reply-To: <lLe1aDKcwMjhFT8K09YMNU_YMiqmr24zNQinRncHdFk=.68cdee09-5dce-4662-b57f-409894d74eef@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <lLe1aDKcwMjhFT8K09YMNU_YMiqmr24zNQinRncHdFk=.68cdee09-5dce-4662-b57f-409894d74eef@github.com>
Message-ID: <0Yd0aqiJQYtnSe_WPTMt5RHHUtKlErdzZl6ooRm_FLs=.1e1e1ef2-4843-47c3-a546-87faa236c75e@github.com>

On Thu, 6 Jul 2023 13:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into rematerialization-of-merges
>  - Addressing PR feedback.
>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Merge branch 'openjdk:master' into rematerialization-of-merges
>  - Rome minor refactorings.
>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>    Catching up with master.
>  - Address PR review 6: debug format output & some refactoring.
>  - Catching up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Address PR review 6: refactoring around rematerialization & improve test cases.
>  - Address PR review 5: refactor on rematerialization & add tests.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/97e99f01...25b683d6

If I understand correctly, this change was backported to older Microsoft OpenJDK versions. Is there a plan to do the same for upstream?

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

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

From mdonovan at openjdk.org  Sun Oct 22 12:08:52 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Sun, 22 Oct 2023 12:08:52 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v2]
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <8jiTNjfHN0ewSsSImcSX3I6pic1M8KUS4wOV3xUUksw=.98ee2221-7639-43d2-b298-9af5635e541a@github.com>

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

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

  fixed line lengths and regenerated html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16294/files
  - new: https://git.openjdk.org/jdk/pull/16294/files/348b326c..fdc5aad0

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

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

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

From azeller at openjdk.org  Mon Oct 23 10:28:36 2023
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 23 Oct 2023 10:28:36 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v2]
In-Reply-To: <8jiTNjfHN0ewSsSImcSX3I6pic1M8KUS4wOV3xUUksw=.98ee2221-7639-43d2-b298-9af5635e541a@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <8jiTNjfHN0ewSsSImcSX3I6pic1M8KUS4wOV3xUUksw=.98ee2221-7639-43d2-b298-9af5635e541a@github.com>
Message-ID: <IPQlO3BIv_KP5MVI2VYrpyfjibP-W5y6jM4Rd_XQ3OY=.0a6378b4-d516-4696-9a10-8c1ca6d82e85@github.com>

On Sun, 22 Oct 2023 12:08:52 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed line lengths and regenerated html

I am not sure, but shouldn`t the change also adopt the documentation in test/jdk/sun/security/pkcs11/README

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

PR Comment: https://git.openjdk.org/jdk/pull/16294#issuecomment-1774891107

From mdonovan at openjdk.org  Mon Oct 23 11:40:56 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 23 Oct 2023 11:40:56 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v3]
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <2lSkTKImeSu47NqrR3fhj2P5Yfo6Idl93GXTxtVuNvo=.d10fa740-e760-4af9-854a-2eebf82aa893@github.com>

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

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

  updated pkcs11/README; did a little wordsmithing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16294/files
  - new: https://git.openjdk.org/jdk/pull/16294/files/fdc5aad0..50479182

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

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

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

From mdonovan at openjdk.org  Mon Oct 23 11:45:35 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 23 Oct 2023 11:45:35 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v2]
In-Reply-To: <IPQlO3BIv_KP5MVI2VYrpyfjibP-W5y6jM4Rd_XQ3OY=.0a6378b4-d516-4696-9a10-8c1ca6d82e85@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <8jiTNjfHN0ewSsSImcSX3I6pic1M8KUS4wOV3xUUksw=.98ee2221-7639-43d2-b298-9af5635e541a@github.com>
 <IPQlO3BIv_KP5MVI2VYrpyfjibP-W5y6jM4Rd_XQ3OY=.0a6378b4-d516-4696-9a10-8c1ca6d82e85@github.com>
Message-ID: <fMAtTRYBr8H2_RWEgp9ZLHsaRPNqHuSvLYIqYX7AsO0=.622cc669-9f30-47ec-ae4c-77f1368aaf21@github.com>

On Mon, 23 Oct 2023 10:25:56 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> I am not sure, but shouldn`t the change also adopt the documentation in test/jdk/sun/security/pkcs11/README

Good catch!

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

PR Comment: https://git.openjdk.org/jdk/pull/16294#issuecomment-1775011697

From duke at openjdk.org  Mon Oct 23 14:53:28 2023
From: duke at openjdk.org (Varada M)
Date: Mon, 23 Oct 2023 14:53:28 GMT
Subject: RFR: 8318240: [AIX] Cleaners.java test failure
In-Reply-To: <p_KA_f0RsAdOrwsAMJq0e498FIBX_dlOxgEiTLQrpHw=.eae811a5-43d7-4d3e-97a7-1ee737dc6e01@github.com>
References: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
 <p_KA_f0RsAdOrwsAMJq0e498FIBX_dlOxgEiTLQrpHw=.eae811a5-43d7-4d3e-97a7-1ee737dc6e01@github.com>
Message-ID: <zUp4UvSZUa-SZeJQCvRhUed_BMXBPgDGLFuq2xNqOr0=.72d3f83d-98d7-4e96-baf3-c923ab10a81b@github.com>

On Thu, 19 Oct 2023 11:53:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When the test sets the sun.security.jgss.native and sun.security.nativegss.debug as true, the test fails on AIX due to missing Kerberos GSS API dynamic library` libgssapi_krb5.so` 
>> 
>> JBS Issue : [JDK-8318240](https://bugs.openjdk.org/browse/JDK-8318240)
>
> Marked as reviewed by mbaesken (Reviewer).

Thank you @MBaesken & @ansteiner

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

PR Comment: https://git.openjdk.org/jdk/pull/16212#issuecomment-1775382239

From michael.x.mcmahon at oracle.com  Mon Oct 23 15:26:42 2023
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 23 Oct 2023 16:26:42 +0100
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <20231019220916.GG202255@twosigma.com>
References: <20231019220916.GG202255@twosigma.com>
Message-ID: <baa8a5a0-e5bb-4b6c-829c-13acbd36d67b@oracle.com>

Hi,

Thanks for bringing this to our attention. You are right that this is a 
misuse of the authentication cache in the case of Kerberos (Negotiate) 
authentication. Though that is not the case for other auth schemes, 
because normally what gets cached are credentials, rather than security 
tokens.

It makes no sense to cache GSS contexts either, outside the scope of any 
individual request (being authenticated through multiple 
request/responses). We don't need to cache it in this situation as it is 
already kept as a local variable in the HttpURLConnection impl class.

So, my first impression is that the fix here needs to disable the cache 
permanently for the Negotiate scheme, which is basically what the system 
property workaround is doing. But, we need to just be sure about that 
before we publish a PR.

Thanks,

Michael.

On 19/10/2023 23:09, Nico Williams wrote:
> # Crashes
>
> We recently upgrade to OpenJDK 17.0.8.1 and started observing crashes
> resulting from double-frees via `gss_delete_sec_context()`.
>
> Adding `-Djdk.spnego.cache=false` to our java invocations stops the
> crashes.  We believe this is due to a race condition that has long been
> in `HttpURLConnection` that was mostly harmless before but which with
> the addition of this commit:
>
>      16843770b5a 8303809: Dispose context in SPNEGO NegotiatorImpl
>
> became a use-after-free / double-free bug, leading to crashes.
>
> This happens with stock 17.0.8.1+1 from Adoptium.
>
> Attached is a reproducer, Test.java, which you can run like this:
>
>      $ # credendials are kinituser at jgssbug.twosigma.com, password password
>      $ #
>      $ "$JAVA_HOME/bin/java" \
>                -Dsun.security.jgss.native=true \
>                -Dsun.security.jgss.lib=/usr/lib/libgssapi_krb5.so \
>                Test.javahttps://kerberos.club/tmp/jgssbug.txt
>
> It doesn't crash every time, but it crashes often.
>
> A typical Java stack trace upon crashing looks like:
>
> j  sun.security.jgss.wrapper.GSSLibStub.deleteContext(J)J+0java.security.jgss at 17.0.8.1
> j  sun.security.jgss.wrapper.NativeGSSContext.dispose()V+76java.security.jgss at 17.0.8.1
> j  sun.security.jgss.GSSContextImpl.dispose()V+16java.security.jgss at 17.0.8.1
> j  sun.net.www.protocol.http.spnego.NegotiatorImpl.disposeContext()V+11java.security.jgss at 17.0.8.1
> J 4456 c1 sun.net.www.protocol.http.NegotiateAuthentication.disposeContext()Vjava.base at 17.0.8.1  (24 bytes) @ 0x00007f909dc33834 [0x00007f909dc337c0+0x0000000
> 000000074]
> j  sun.net.www.protocol.http.HttpURLConnection.getInputStream0()Ljava/io/InputStream;+1923java.base at 17.0.8.1
> j  sun.net.www.protocol.http.HttpURLConnection.getInputStream()Ljava/io/InputStream;+62java.base at 17.0.8.1
> j  sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream()Ljava/io/InputStream;+4java.base at 17.0.8.1
> j  Test.lambda$main$0()V+16
> j  Test$$Lambda$207+0x00007f9020144208.run()V+0
> j  java.lang.Thread.run()V+11java.base at 17.0.8.1
> v  ~StubRoutines::call_stub
>
> On the C side the crash typically happens in the allocator, typically in
> `free()`:
>
> #0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007fb6e1185535 in __GI_abort () at abort.c:79
> #2  0x00007fb6e11dc648 in __libc_message (action=action at entry=do_abort, fmt=fmt at entry=0x7fb6e12e62a0 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x00007fb6e11e2d6a in malloc_printerr (str=str at entry=0x7fb6e12e444e "free(): invalid pointer") at malloc.c:5359
> #4  0x00007fb6e11e459c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4180
> #5  0x00007fb582ba5b6d in krb5_free_address (context=context at entry=0x7fb5d80cbf60, val=0x7fb5d8000080) at kfree.c:62
> #6  0x00007fb582b93d9e in krb5_auth_con_free (context=context at entry=0x7fb5d80cbf60, auth_context=0x7fb5d80778a0) at auth_con.c:60
> #7  0x00007fb6440a3eec in krb5_gss_delete_sec_context (minor_status=0x7fb586868504, context_handle=0x7fb5d80e22d0, output_token=<optimized out>)
>      at delete_sec_context.c:77
> #8  0x00007fb6440964b0 in gssint_delete_internal_sec_context (minor_status=0x7fb586868504, mech_type=<optimized out>,
>      internal_ctx=internal_ctx at entry=0x7fb5d80e22d0, output_token=0x0) at g_glue.c:606
> #9  0x00007fb6440946dd in gss_delete_sec_context (minor_status=<optimized out>, context_handle=0x7fb5d80d2be8, output_token=<optimized out>)
>      at g_delete_sec_context.c:91
> #10 0x00007fb6440b8dfe in spnego_gss_delete_sec_context (minor_status=<optimized out>, context_handle=0x7fb5d807bd70, output_token=<optimized out>)
>      at spnego_mech.c:2161
> #11 0x00007fb6440964b0 in gssint_delete_internal_sec_context (minor_status=0x7fb586868504, mech_type=<optimized out>,
>      internal_ctx=internal_ctx at entry=0x7fb5d807bd70, output_token=0x0) at g_glue.c:606
> #12 0x00007fb6440946dd in gss_delete_sec_context (minor_status=<optimized out>, context_handle=0x7fb586868508, output_token=<optimized out>)
>      at g_delete_sec_context.c:91
> #13 0x00007fb6dc0559ff in Java_sun_security_jgss_wrapper_GSSLibStub_deleteContext () from /home/nico/tmp/jdk-17.0.8.1+1/lib/libj2gss.so
> #14 0x00007fb6c89a653a in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> We've seen other variations, but always they can be traced to
> `HttpURLConnection`.
>
> (We do maintain local patches to OpenJDK JGSS code as well.  But that's
> a story for another time.  We do want to try again to upstream those
> patches.  Because we maintain such patches we developed an interim fix
> where we use `synchronized (lock)` in the JGSS `dispose()` methods and
> also `Reference.reachabilityFence(this)`, which worked to prevent the
> crashes, but that was before we learned that `-Djdk.spnego.cache=false`
> also works.  In any case, stock, unpatched OpenJDK 17.0.8.1 evinces this
> crasher.)
>
> # Root cause
>
> What 8303809 did was add calls to `dispose()` on `GSSContext` objects in
> NegotiatorImpl.java in a new method called `disposeContext()` that all
> HTTP authentication mechanisms now implement and which 8303809 also
> added.
>
> It took us a while to realize that the use of the `AuthCache` in
> `HttpURLConnection` implies concurrent access to the cached contexts via
> concurrent HTTP requests to the same origin.
>
> Concurrent access to and disposal of those context objects then leads to
> use-after-free / double-free errors when using sun.security.jgss.native.
>
> There's really several issues going on here:
>
>   - The `dispose()` methods in 17.x in the JGSS native C GSS bindings
>     clases are dangerous, as are finalizers generally (and these
>     `dispose()` methods are called from finalizers).
>
>     This is fixed in later OpenJDK releases by making use of `Cleaner`,
>     so there's not much more to say about this here.
>
>   - The `AuthCache` in `src/java.base/share/classes/sun/net/www/protocol/http/`
>     implies concurrency, and it's not clear that concurrency is allowable
>     in all cases.
>
>   - In the case of RFC 4559 "Negotiate" and GSS concurrency is very much
>     not permitted.  The GSS APIs can and should be thread-safe, but it is
>     still an error to invoke `initSecContext()` concurrently on the same
>     `GSSContext`!
>
>     GSS-API `initSecContext()`/`acceptSecContext()` are strictly
>     synchronous and serial.
>
>   - The `AuthCache` in `src/java.base/share/classes/sun/net/www/protocol/http/`
>     is likely a misfeature altogether, at least as far as sharing GSS-
>     like HTTP authentication mechanism contexts goes, and probably for
>     all other HTTP auth methods too.
>
>     It's not ok to take a reply token from a `WWW-Authenticate:` response
>     header and consume it together with a "context" created by a
>     unrelated request [to the same origin].
>
>     Every `WWW-Authenticate:`/`Authorization:` token must be matched to
>     the same [serial train of] request[s].
>
>     Thus if we have an RFC 4559 Negotiate exchange requiring 5 tokens, so
>     something like:
>
>     0: request..
>     1: 401 response w/ WWW-Authenticate: Negotiate
>     2: request w/ Authorization: Negotiate ...           (continue needed)
>     3: 200 response w/ WWW-Authenticate: Negotiate ...   (continue needed)
>     4: request w/ Authorization: Negotiate ...           (continue needed)
>     5: 200 response w/ WWW-Authenticate: Negotiate ...   (complete)
>
>     it would not be permissible for one of those reply tokens to be fed
>     to another request's GSSContext, nor would it be OK to have more than
>     one serial set of requests share the same GSSContext.
>
>   - The foregoing also applies to SCRAM, DIGEST-MD5, and just about any
>     and all HTTP authentication methods that I know.  I believe that
>     there is no value in caching HTTP authentication mechanism contexts
>     on the client side.
>
>     HTTP Authentication mechanisms like SCRAM and DIGEST-MD5 are
>     three-message mechanisms when counting the initial challenge:
>
>     0: request...
>     1: 401 response w/ WWW-Authenticate: DIGEST-MD5 <challenge>
>     2: request w/ Authorization: DIGEST-MD5 ...
>     3: 200 w/ WWW-Authenticate: DIGEST-MD5 ... (complete)
>
>     There is no case in which caching and sharing a SCRAM or DIGEST-MD5
>     authentication context is useful because there is only one request/
>     response in which there is a context needed at all: between 2 and 3
>     inclusive in the above diagram.
>
>     Perhaps a single challenge can be shared with multiple subsequent
>     requests that will optimistically use SCRAM or DIGEST-MD5 knowing
>     that one response demanded it, but one should probably not do this,
>     though I could find nothing in RFC 5802 and 7677.
>
>   - Negotiate is really a bearer token system, albeit with the
>     possibility of using channel bindings.  Meaning we never use the
>     resulting GSSContext to encrypt or sign any part of the HTTP requests
>     and responses authenticated with that context.  Therefore there's
>     never any point in sharing a GSSContext in HTTP, not even once it's
>     fully-established -- there is no point in doing anything other than
>     disposing of a fully-established GSSContext in HTTP/Negotiate.
>
>     (Attempts to develop standards for encrypting/signing of HTTP
>     requests and responses at the HTTP layer rather than in TLS have
>     historically failed.  If one attempt to standardize such a thing
>     succeeds, _then_ there will be something worth sharing in a cache
>     with care to prevent use-after-dispose.)
>
>   - Because of the preceding, in HTTP/Negotiate it is desirable to "free"
>     any GSSContext immediately after it is complete.
>
>     This is presumably how you came to add the `disposeContext()` method:
>     because those cached contexts otherwise sit there using lots of
>     memory for no reason; someone must have noticed.  However, rather
>     than have an explicit `disposeContext()` these contexts should just
>     immediately be disposed of when complete or failed.
>
> # Possible fixes
>
>   - Backport the use of `Cleaner` in the JGSS `dispose()` methods.
>
>     This would not be very satisfying because the `HttpURLConnection`
>     `AuthCache` would remain buggy, but at least the JVM wouldn't crash.
>
>   - Default `jdk.spnego.cache` to `false`.
>
>   - Rethink or remove the `AuthCache` in `HttpURLConnection`.
>
>   - Something else?
>
> Thanks,
>
> Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231023/eaa05ccf/attachment-0001.htm>

From djelinski at openjdk.org  Mon Oct 23 16:42:03 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Oct 2023 16:42:03 GMT
Subject: RFR: 8318479: [jmh] the test security.CacheBench failed for multiple
 threads run
Message-ID: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>

Remove the hardcoded maximum heap size.

Verified that the benchmark now passes with 100 threads given sufficient heap:

make test TEST=micro:CacheBench MICRO="OPTIONS=-t 100;JAVA_OPTIONS=-Xmx16g"

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

Commit messages:
 - Remove hardcoded Xmx

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

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

From Nico.Williams at twosigma.com  Mon Oct 23 18:50:11 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 23 Oct 2023 18:50:11 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <baa8a5a0-e5bb-4b6c-829c-13acbd36d67b@oracle.com>
References: <20231019220916.GG202255@twosigma.com>
 <baa8a5a0-e5bb-4b6c-829c-13acbd36d67b@oracle.com>
Message-ID: <20231023185011.GA2670319@twosigma.com>

On Mon, Oct 23, 2023 at 04:26:42PM +0100, Michael McMahon wrote:
> Thanks for bringing this to our attention. You are right that this is a
> misuse of the authentication cache in the case of Kerberos (Negotiate)
> authentication. Though that is not the case for other auth schemes, because
> normally what gets cached are credentials, rather than security tokens.

I see.  I guess you could cache `GSSCredential` handles if the caller
were using non-default GSS credentials.  With password-based HTTP
schemes the credentials aren't process-global like GSS credentials
typically are, but rather can vary per request.

> It makes no sense to cache GSS contexts either, outside the scope of any
> individual request (being authenticated through multiple request/responses).
> We don't need to cache it in this situation as it is already kept as a local
> variable in the HttpURLConnection impl class.
> 
> So, my first impression is that the fix here needs to disable the cache
> permanently for the Negotiate scheme, which is basically what the system
> property workaround is doing. But, we need to just be sure about that before
> we publish a PR.

For what it's worth, disabling the cache for Negotiate does indeed work
right now as a workaround.  You can reproduce both, the crashes and the
workaround using the instructions I provided.

Nico
-- 

From calanelyse at icloud.com  Tue Oct 17 12:16:52 2023
From: calanelyse at icloud.com (Elyse Grubb)
Date: Tue, 17 Oct 2023 07:16:52 -0500
Subject: The fix for JDK-806769 breaks some ldap usages.
Message-ID: <A7FB0E96-A0D1-493F-A92C-D94D4CE1B0F0@icloud.com>



Sent from my iPhone

From weijun at openjdk.org  Mon Oct 23 21:13:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 23 Oct 2023 21:13:08 GMT
Subject: RFR: 8318689: jtreg is confused when folder name is the same as the
 test name
Message-ID: <UZ505yWfItHh_nFHorv9cW20a1MdmvZWP5kYMbfXaQw=.08ff7d64-cb37-4c33-8d4c-091be65e4df2@github.com>

Rename the test.

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

Commit messages:
 - the fix

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

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

From duke at openjdk.org  Tue Oct 24 01:52:56 2023
From: duke at openjdk.org (Ben Perez)
Date: Tue, 24 Oct 2023 01:52:56 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated with
 leading period
Message-ID: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>

Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

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

Commit messages:
 - removed tabs
 - replaced tabs with spaces
 - Merge branch 'openjdk:master' into JDK-8311546
 - Changed documentation for LeadingPeriod test
 - Removed unnecessary doc
 - removed unnecessary files related to cert generation
 - Added test for checking certs with leading period
 - Added check for leading '.' in DNS name

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

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

From lkorinth at openjdk.org  Tue Oct 24 07:49:30 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 07:49:30 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:

 - static import
 - copyright
 - whitespace
 - whitespace
 - sed
 - fix test/lib/jdk/test/lib/process/ProcessTools.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/f80dda8d..2f57a32d

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

  Stats: 1580 lines in 560 files changed: 44 ins; 34 del; 1502 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From lkorinth at openjdk.org  Tue Oct 24 09:10:43 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 09:10:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <U_NEwp1RAk4Dq_2OXmgi4TOR6vYQF9IVj-PU6X7-h-M=.8ee4eda5-7d48-44d7-b896-3237fae1620d@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Hi, if you want to see what I have modified manually, you can do my sed commands and compare to this pull request:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedTestJavaProcessBuilder/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createTestJvm/import static jdk.test.lib.process.ProcessTools.createTestJavaProcessBuilder/g"
git add -u; git commit -m sed

git diff-tree --no-commit-id --name-only -r 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9..HEAD | xargs sed -i -e "s%^( * Copyright (c) ....)[^[:alpha:]]*(Oracle.*)%\1, 2023, \2%"
git ls-files -m | xargs sed -i -e "s%(Copyright (c) 2023), 2023, (Oracle.*)%\1, \2%"
git add -u; git commit -m copyright

git diff HEAD 2f57a32df8d17da51a04177563327ca2a75e8061


It will give you an easier way to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1776817287

From stefank at openjdk.org  Tue Oct 24 09:51:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 24 Oct 2023 09:51:39 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <gQyz0Ymz5D09Wuwv4hsUjuWMSHG32Fkp_vhzQtrMAhI=.806fba1c-cc72-452e-b3d2-316b25600e3c@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1694437335

From duke at openjdk.org  Tue Oct 24 12:26:38 2023
From: duke at openjdk.org (Varada M)
Date: Tue, 24 Oct 2023 12:26:38 GMT
Subject: Integrated: 8318240: [AIX] Cleaners.java test failure
In-Reply-To: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
References: <AZOH7qfso2quAfdfjCWNoI--mrAhSrmOWMlp6CJhxvE=.7eedc07b-52e4-4ac0-af21-67355515d26b@github.com>
Message-ID: <CvMhZgLtyHoiLqXT0VCd6RXNdpAlXNNdrB6fzRxqTRk=.c54a17bd-1d2c-4c5a-ad3b-13733a0a34b9@github.com>

On Tue, 17 Oct 2023 07:31:07 GMT, Varada M <duke at openjdk.org> wrote:

> When the test sets the sun.security.jgss.native and sun.security.nativegss.debug as true, the test fails on AIX due to missing Kerberos GSS API dynamic library` libgssapi_krb5.so` 
> 
> JBS Issue : [JDK-8318240](https://bugs.openjdk.org/browse/JDK-8318240)

This pull request has now been integrated.

Changeset: d4b76124
Author:    Varada M <mvarada2000 at gmail.com>
Committer: Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b761242d91aa1bcadc438cce0a9465c0f8b23d
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8318240: [AIX] Cleaners.java test failure

Reviewed-by: mbaesken, asteiner

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

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

From valeriep at openjdk.org  Tue Oct 24 16:21:31 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 24 Oct 2023 16:21:31 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v5]
In-Reply-To: <aB3NEKKs6f3sNfjQzR-u7SurFnf4mSGz2LzS8EgdkGs=.c511adab-10d5-490b-9100-b89e9f07821c@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <DLotXZpPUSBvgH9dO01EVVc4JZuwT8OxTl2jPh6aVQg=.a2682af8-d230-4d8a-8467-21d5a131bea8@github.com>
 <aB3NEKKs6f3sNfjQzR-u7SurFnf4mSGz2LzS8EgdkGs=.c511adab-10d5-490b-9100-b89e9f07821c@github.com>
Message-ID: <LdUfGZtDrBq8-gAt9qft0y0L5_Iu0jwO0mW74oo-WMY=.08d3ad9b-371a-40f2-963d-f54595d93b2c@github.com>

On Wed, 18 Oct 2023 17:22:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   inline some throw statements, remove duplicated whitespaces
>
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kinit.java line 131:
> 
>> 129:         } catch (Exception e) {
>> 130:             String msg;
>> 131:             if (e instanceof KrbException) {
> 
> Let's simplify with pattern matching variable

+1. Rest looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15951#discussion_r1370484614

From hchao at openjdk.org  Tue Oct 24 16:36:42 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 24 Oct 2023 16:36:42 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <colncAa5fScnKt-cn2Cm_EG4OaifiHr9XZafBg2bWUg=.9c235083-e953-4143-a445-24ce9132d638@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>
 <colncAa5fScnKt-cn2Cm_EG4OaifiHr9XZafBg2bWUg=.9c235083-e953-4143-a445-24ce9132d638@github.com>
Message-ID: <4vtqoNqiBg_xG6dUOphOZlaXUKv1Sw9jWl_XZKR8d8g=.96a65296-926b-480d-a47b-f935cc7f5d59@github.com>

On Fri, 20 Oct 2023 17:19:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge
>>  - Override the client/server defaults
>>  - Change made to configure max allowed cert chain lengths based on updated CSR
>>  - Merge
>>  - Set to default if a negative value is set
>>  - 8311596: Add separate system properties for TLS server and client for maximum chain length
>
> I was wondering, if it is easier to learn and remember/search by following the naming style "jdk.tls.client.XXX" or "jdk.tls.server.XXX" in SunJSSE provider?

@XueleiFan The current properties named` jdk.tls.client.*` and `jdk.tls.server.*` apply to settings either on the client or the server, so we'd have to rename the properties here. My suggestion is to:

- Change `jdk.tls.maxServerCertificateChainLength` to `jdk.tls.client.maxAcceptedCertificateChainLength`

- Change `jdk.tls.maxClientCertificateChainLength` to `jdk.tls.server.maxAcceptedCertificateChainLength`

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/15163#issuecomment-1777609067

From weijun at openjdk.org  Tue Oct 24 16:37:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Oct 2023 16:37:12 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v6]
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <hczYj8uQ6s1-2PD9p8sNe7Vo5Ue1bpW6_12iIAPPeTs=.b9eed89e-ec1c-408d-878b-23993046dec4@github.com>

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
> 
> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.

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

  simplify with pattern matching variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15951/files
  - new: https://git.openjdk.org/jdk/pull/15951/files/78466670..5ecd7624

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

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

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

From lmesnik at openjdk.org  Tue Oct 24 17:04:41 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 24 Oct 2023 17:04:41 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <G2CSM_N-_TwMdAlZX8c-AJtweGPX39TTxuu9HXtGrbc=.1d47edf7-9d08-46ba-9e3b-3549574ebbea@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1695447658

From valeriep at openjdk.org  Tue Oct 24 17:09:30 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 24 Oct 2023 17:09:30 GMT
Subject: RFR: 8316964: Security tools should not call System.exit [v6]
In-Reply-To: <hczYj8uQ6s1-2PD9p8sNe7Vo5Ue1bpW6_12iIAPPeTs=.b9eed89e-ec1c-408d-878b-23993046dec4@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
 <hczYj8uQ6s1-2PD9p8sNe7Vo5Ue1bpW6_12iIAPPeTs=.b9eed89e-ec1c-408d-878b-23993046dec4@github.com>
Message-ID: <d5-XZmNXdD2JrjQaxHe79DH5UbRcHuFcOW5yJeJcq8Y=.71ab9ddf-0f44-4250-9e01-b4faaa5db349@github.com>

On Tue, 24 Oct 2023 16:37:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
>> 
>> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify with pattern matching variable

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15951#pullrequestreview-1695456281

From weijun at openjdk.org  Tue Oct 24 18:35:43 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Oct 2023 18:35:43 GMT
Subject: Integrated: 8316964: Security tools should not call System.exit
In-Reply-To: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
References: <w6h4-M1xRgafvYmYXJVWtIDRZisy7a42T4bUZHAICMY=.af49613c-5c4e-49bd-926a-c0d78e95b3b7@github.com>
Message-ID: <48e1zl-nNn2rq1DYHegqcofbt3OVp9-UdMw7fxqYTh0=.8d9bad99-5d7e-4716-b7ec-c1cfeb5e04bc@github.com>

On Wed, 27 Sep 2023 20:33:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools.
> 
> Note: before this change, the behavior of a successful `main()` method execution is not consistent. Sometimes the method returns silently, sometimes a `System.exit(0)` is called somewhere. After this change, the method always returns silently. This makes sure that existing programs that calls the `main` method directly will continue and does not exit the VM.

This pull request has now been integrated.

Changeset: 1ddf826a
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ddf826aea7fd18209336dce550821638d5ef89c
Stats:     471 lines in 8 files changed: 263 ins; 113 del; 95 mod

8316964: Security tools should not call System.exit

Reviewed-by: valeriep

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

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

From rriggs at openjdk.org  Tue Oct 24 19:42:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 19:42:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <6qyfRp98A2DA7Q7YhscmdmokkIvVVn9HxB_XjRdM47g=.615d7a65-e109-41db-b955-31c0a934debd@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

test/lib/jdk/test/lib/process/ProcessTools.java line 506:

> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List<String> command) {
> 506:         return createTestJavaProcessBuilder(command.toArray(String[]::new));

The javadoc shoul d describe all of the options being added to the ProcessBuilder.
They were inadequated described previously and still are.
The other options (seem to be from the code), test.noclasspath, java.class.path, and test.thread.factory.
The description of test.thread.factory and addTestThreadFactoryArgs method seems inadequately described.

test/lib/jdk/test/lib/process/ProcessTools.java line 527:

> 525:      * Create ProcessBuilder using the java launcher from the jdk to
> 526:      * be tested.
> 527:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for `reateTestJavaProcessBuilder(...)`

test/lib/jdk/test/lib/process/ProcessTools.java line 549:

> 547:      * Create ProcessBuilder using the java launcher from the jdk to
> 548:      * be tested.
> 549:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for reateTestJavaProcessBuilder(...)

test/lib/jdk/test/lib/process/ProcessTools.java line 599:

> 597:      */
> 598:     public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception {
> 599:         ProcessBuilder pb = createTestJavaProcessBuilder(cmds);

This should also describe *all* of the options being set in the ProcessBuilder before executing the process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370728371
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729609
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729925
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370730637

From mdonovan at openjdk.org  Tue Oct 24 19:58:58 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 24 Oct 2023 19:58:58 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v4]
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <Cb1fSpB5dyCr9dUDnH0_xn5qsOlC8CNeO851CAJ7kc4=.a5414197-af46-439d-ab2c-268a735bf507@github.com>

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

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

  fixed whitespace errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16294/files
  - new: https://git.openjdk.org/jdk/pull/16294/files/50479182..8df921f6

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

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

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

From erikj at openjdk.org  Tue Oct 24 21:24:35 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 24 Oct 2023 21:24:35 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v4]
In-Reply-To: <Cb1fSpB5dyCr9dUDnH0_xn5qsOlC8CNeO851CAJ7kc4=.a5414197-af46-439d-ab2c-268a735bf507@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <Cb1fSpB5dyCr9dUDnH0_xn5qsOlC8CNeO851CAJ7kc4=.a5414197-af46-439d-ab2c-268a735bf507@github.com>
Message-ID: <NmvmKQlmcqlimbhQyUkzLNv42_25C2HbIQ_L0tlV_4s=.7e375631-91a6-4d25-a59a-34e884b112ec@github.com>

On Tue, 24 Oct 2023 19:58:58 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed whitespace errors

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16294#pullrequestreview-1695908744

From kdriver at openjdk.org  Tue Oct 24 22:05:55 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 24 Oct 2023 22:05:55 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v4]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <4HDhD2YB5Q8U9yTML9nFHf8BDJ9ZDssp9h8HsSNZtRM=.f635c1f6-533d-4eec-a8eb-50e700f0420b@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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 11 additional commits since the last revision:

 - update keystore/truststore type for more dependent tests
 - password for the keystore wasn't being set automatically by the test harness; set it explicitly
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - wip
 - JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
 - JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bb245846...8146a694

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/e118be60..8146a694

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

  Stats: 25112 lines in 956 files changed: 16307 ins; 4396 del; 4409 mod
  Patch: https://git.openjdk.org/jdk/pull/16159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16159/head:pull/16159

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

From mullan at openjdk.org  Tue Oct 24 22:05:57 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 24 Oct 2023 22:05:57 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v3]
In-Reply-To: <2cFYklJ0Yft3dNTG57Wi4WLGiC6j26y92E_aRzAo_1U=.0c781796-6f66-44c7-8baf-8d18148c1795@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <2cFYklJ0Yft3dNTG57Wi4WLGiC6j26y92E_aRzAo_1U=.0c781796-6f66-44c7-8baf-8d18148c1795@github.com>
Message-ID: <1sVE2TGeG64_HfnLET3FvbMJoUoEJOWYNhywapUfBYU=.f7d758e8-1359-446f-8848-edbfbddc3993@github.com>

On Thu, 12 Oct 2023 17:36:49 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

There are other tests under `test/jdk/sun/security/ssl` that are instantiating the keystores in `test/jdk/javax/net/ssl/etc` as "JKS". For example, see `test/jdk/javax/net/ssl/SSLSession/SSLCtxAccessToSessCtx.java`. Although the compatibility mode by default allows JKS keystores to load PKCS12 keystores (and vice-versa), I think it would be better/cleaner to change all of these tests to load them as "PKCS12".

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

PR Comment: https://git.openjdk.org/jdk/pull/16159#issuecomment-1761462843

From stefank at openjdk.org  Wed Oct 25 07:27:32 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Oct 2023 07:27:32 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
 <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>
Message-ID: <BYTPUH_b0INyCGVwslaQVyQkTYKNOQvJfnLhKv6mlLM=.bbd8a311-3af8-4288-9491-55c8098af7c8@github.com>

On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.
>> 
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.
>
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca
> 
> The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.
> 
> There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
> @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
> Every test writer should be aware that additional command line options may be mixed in.
> 
> There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.
> 
> As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

@RogerRiggs You seem to know what you want w.r.t. the extra java doc comments. Could you help write those? Could we also do that as a separate RFE? I think that would make it easier to get this PR and the javadoc update through the door.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1778669353

From duke at openjdk.org  Wed Oct 25 08:34:53 2023
From: duke at openjdk.org (duke)
Date: Wed, 25 Oct 2023 08:34:53 GMT
Subject: Withdrawn: 8309330: Allow java.security to be extended via a
 properties directory
In-Reply-To: <dkwAA8O3Tvr5RPC7OSjq3Y2jQW5QHg5gBxyAcAgokoU=.75c53221-56f0-494c-a4fc-c8c09952093c@github.com>
References: <dkwAA8O3Tvr5RPC7OSjq3Y2jQW5QHg5gBxyAcAgokoU=.75c53221-56f0-494c-a4fc-c8c09952093c@github.com>
Message-ID: <ckwFSNmFdeVp7c4y8j3_Egl2vR7nUanpXk1ERrFzSM0=.1f03a749-bd81-4ba0-a5ce-cf5bf851fbc6@github.com>

On Fri, 2 Jun 2023 00:57:49 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties.
> 
> There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required.
> 
> This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`.
> 
> As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK.
> 
> The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true.
> 
> A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream.

This pull request has been closed without being integrated.

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

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

From lkorinth at openjdk.org  Wed Oct 25 08:44:29 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 25 Oct 2023 08:44:29 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright year and indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/2f57a32d..4cc3865a

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

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

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

From weijun at openjdk.org  Wed Oct 25 16:31:02 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Oct 2023 16:31:02 GMT
Subject: RFR: 8318096: Add getParams method in PublicKey and PrivateKey
 [v3]
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <wEAUh0R_MpEo7n2ETt_AvC8Gr6MopQJ8kpqwJZ--VKU=.23ebc98c-a030-4a4b-9e55-307fd47e598a@github.com>

> Add `getParams` to `PublicKey` and `PrivateKey` so it's available to all current and future public and private keys.
> 
> No test. Might add one.

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

  AsymmetricKey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16222/files
  - new: https://git.openjdk.org/jdk/pull/16222/files/d0cf5c56..8017cc4d

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

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

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

From xuelei at openjdk.org  Wed Oct 25 17:43:32 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 25 Oct 2023 17:43:32 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <colncAa5fScnKt-cn2Cm_EG4OaifiHr9XZafBg2bWUg=.9c235083-e953-4143-a445-24ce9132d638@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>
 <colncAa5fScnKt-cn2Cm_EG4OaifiHr9XZafBg2bWUg=.9c235083-e953-4143-a445-24ce9132d638@github.com>
Message-ID: <HByoON_xBsBe5Cc2ve2-3fG5EfPERqDoFMpKZKfhhfY=.d37217c9-c165-4fcf-8a12-ca4bd351cfe3@github.com>

On Fri, 20 Oct 2023 17:19:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge
>>  - Override the client/server defaults
>>  - Change made to configure max allowed cert chain lengths based on updated CSR
>>  - Merge
>>  - Set to default if a negative value is set
>>  - 8311596: Add separate system properties for TLS server and client for maximum chain length
>
> I was wondering, if it is easier to learn and remember/search by following the naming style "jdk.tls.client.XXX" or "jdk.tls.server.XXX" in SunJSSE provider?

> @XueleiFan The current properties named` jdk.tls.client.*` and `jdk.tls.server.*` apply to settings either on the client or the server, so we'd have to rename the properties here. My suggestion is to:
> 
> * Change `jdk.tls.maxServerCertificateChainLength` to `jdk.tls.client.maxAcceptedCertificateChainLength`
> * Change `jdk.tls.maxClientCertificateChainLength` to `jdk.tls.server.maxAcceptedCertificateChainLength`
> 
> Thanks!

For the name "jdk.tls.maxServerCertificateChainLength", it is not clear to me which side, client or server, the property should be applied to.   It could also mean that server can only send out certification with this limitation.

For the name `jdk.tls.client.maxAcceptedCertificateChainLength`, it could be confused to parse the word "accepted".  It could mean that the accepted cert-chain length for sending out certificates.

Maybe, you can have a try with "jdk.tls.client.maxServerCertificateChainLength", which means for client side, the server certificate chain length (inbound) is limited.  Or if you want to simplify the property name, you can have a try for ""jdk.tls.client.maxInboundCertificateChainLength"".

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

PR Comment: https://git.openjdk.org/jdk/pull/15163#issuecomment-1779753163

From hchao at openjdk.org  Wed Oct 25 18:35:37 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 25 Oct 2023 18:35:37 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v6]
In-Reply-To: <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <0_dOr0TX-qMGHesphTF266JCFnEqSlereiQHakoSLY8=.47163d4f-7559-4052-b61b-699a6ec5f74e@github.com>
Message-ID: <N1-Cy3OlpV26zF4Vb7JYUgsgVhgNlhqQX8B0eA0hzLg=.9635107c-14e6-4bcc-9a9e-a5b15b5eb108@github.com>

On Wed, 18 Oct 2023 00:25:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Override the client/server defaults
>  - Change made to configure max allowed cert chain lengths based on updated CSR
>  - Merge
>  - Set to default if a negative value is set
>  - 8311596: Add separate system properties for TLS server and client for maximum chain length

It sounds good to me that the word "Accepted" is replaced with "Inbound". It should clear out the confusion I think. Thanks for the suggestion.

So how about changing the properties names from:
`jdk.tls.maxServerCertificateChainLength`  --> `jdk.tls.client.maxInboundCertificateChainLength`
`jdk.tls.maxClientCertificateChainLength` --> `jdk.tls.server.maxInboundCertificateChainLength`

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

PR Comment: https://git.openjdk.org/jdk/pull/15163#issuecomment-1779834440

From kdriver at openjdk.org  Wed Oct 25 19:17:01 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 25 Oct 2023 19:17:01 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v5]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <yP4rZ2nhWqr2yiObMvtjPHQv7hMcZK1LDqGo1b9H4GE=.2cd98652-0ce1-4527-9c92-914660b352c8@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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 12 additional commits since the last revision:

 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - update keystore/truststore type for more dependent tests
 - password for the keystore wasn't being set automatically by the test harness; set it explicitly
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - wip
 - JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
 - ... and 2 more: https://git.openjdk.org/jdk/compare/ce71d0f7...e104fb92

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/8146a694..e104fb92

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

  Stats: 3648 lines in 112 files changed: 1969 ins; 1320 del; 359 mod
  Patch: https://git.openjdk.org/jdk/pull/16159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16159/head:pull/16159

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

From rriggs at openjdk.org  Wed Oct 25 22:00:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 22:00:31 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <qyv3_2FCcacwbDL17B7JewcsR5XazNJjio3Z_WNTq_U=.88ec5e8f-7929-443c-a85f-617260b584e4@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Suggestions to complete the descriptions of the createXXXJavaProcessBuilder methods.

test/lib/jdk/test/lib/process/ProcessTools.java line 505:

> 503:      * @return The ProcessBuilder instance representing the java command.
> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List<String> command) {

Include the same description of other properties that are included in creating the ProcessBuilder...
```     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 520:

> 518:      * @return The ProcessBuilder instance representing the java command.
> 519:      */
> 520:     public static ProcessBuilder createTestJavaProcessBuilder(String... command) {

Include the same description of other properties that are included in creating the ProcessBuilder...

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 538:

> 536:      * it in combination with <b>@requires vm.flagless</b> JTREG
> 537:      * anotation as to not waste energy and test resources.
> 538:      *

Consider adding this description of what this method does.
Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 560:

> 558:      * it in combination with <b>@requires vm.flagless</b> JTREG
> 559:      * anotation as to not waste energy and test resources.
> 560:      *

Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1698308785
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364800
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364171
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372361862
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372362333

From weijun at openjdk.org  Thu Oct 26 00:23:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Oct 2023 00:23:04 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v4]
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <xId9OLGchvmETKhEoM5ySK-BQvtp3_Y0yF_-fLZPa9U=.22c4863c-7fc1-4617-b4e4-0969d19e7238@github.com>

> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
> 
> No test. Might add one.

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

  no longer sealed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16222/files
  - new: https://git.openjdk.org/jdk/pull/16222/files/8017cc4d..096b95a1

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

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

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

From darcy at openjdk.org  Thu Oct 26 00:52:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Oct 2023 00:52:33 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v4]
In-Reply-To: <xId9OLGchvmETKhEoM5ySK-BQvtp3_Y0yF_-fLZPa9U=.22c4863c-7fc1-4617-b4e4-0969d19e7238@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <xId9OLGchvmETKhEoM5ySK-BQvtp3_Y0yF_-fLZPa9U=.22c4863c-7fc1-4617-b4e4-0969d19e7238@github.com>
Message-ID: <3yRkDYhovtMu0-PHmcsUDAd7CSDk1-ykIQaFqox3Lto=.e6f35629-20d9-41a2-9d91-5fe8f584b144@github.com>

On Thu, 26 Oct 2023 00:23:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
>> 
>> No test. Might add one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no longer sealed

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java line 78:

> 76:      * @since 22
> 77:      */
> 78:     default DSAParams getParams() {

Suggestion: for this methods I recommend `@Override`-ing them and for the javadoc to used directed inheritance, roughly:


/**
 * {@inhertiDoc AsymmetricKey}
 * @implSpec ..
 * @return {@inhertiDoc AsymmetricKey}
 * @since 22
 */

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

PR Review: https://git.openjdk.org/jdk/pull/16222#pullrequestreview-1698553257
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1372451471

From weijun at openjdk.org  Thu Oct 26 02:43:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Oct 2023 02:43:14 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v5]
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <nQ-RZxXcZHn7M10UYq-sdkZNE6OXgq-OFlCtPcy0Has=.8abdaa0e-d59e-4990-9844-d8013e79d406@github.com>

> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
> 
> No test. Might add one.

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

  use @inheritDoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16222/files
  - new: https://git.openjdk.org/jdk/pull/16222/files/096b95a1..319eaa54

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

  Stats: 72 lines in 12 files changed: 12 ins; 36 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16222/head:pull/16222

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

From anthony.scarpino at oracle.com  Thu Oct 26 05:33:05 2023
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 25 Oct 2023 22:33:05 -0700
Subject: [External] : Re: RFD: Services lockdown for security providers
In-Reply-To: <9c212429-6045-5b0a-c6b0-6370488039b1@redhat.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
 <4b159d35-ee2e-952d-8e22-c035e5ed17ea@oracle.com>
 <1a0ad927-2da8-c881-a80f-b4928341375f@redhat.com>
 <d7a607e0-7acc-1929-7464-a70ceb6d7c91@oracle.com>
 <7c07a7b1-6c68-9534-59e1-1813439d7f47@redhat.com>
 <85e89abd-eac3-87df-9e4b-1fa2c36a6286@oracle.com>
 <CAKZz+geGA3Hs4jV8AFTKPrehiquXWbiA9BvPVFPSaWzLVsn6Rw@mail.gmail.com>
 <dc1c22ab-b130-364f-d7d2-880d899a5184@oracle.com>
 <9c212429-6045-5b0a-c6b0-6370488039b1@redhat.com>
Message-ID: <d8a80c8c-70ad-4284-88a5-8d8d6f8a97da@oracle.com>

Hi Martin,

Thanks for the additional motivation.

While thinking about this PR, I found that the filter can be 
inconsistently applied between JDK and 3rd party providers.  The java 
providers use the JCA to build combined algorithms. For example, the 
ECDSAwithSHA1 that comes from SunEC uses getInstance() for 
MessageDigest.SHA-1.  HmacSHA1 and PBEWithHmacSHA1AndAES_128 do the same.

If a filter only contains "*.MessageDigest.SHA-1", it will disable all 
the combined algorithms for JDK providers that use SHA1.  For 3rd party 
providers, these algorithms would likely be enabled.  A PKCS11 provider 
that supports ECDSAwithSHA1 would use its internal SHA1 that the filter 
would not effect.

I think the filters should be consistently applied to all providers. 
JDK providers and any 3rd party providers that uses this pluggable 
design, should not be more restricted.  This inconsistency could lead to 
an incorrect configuration.  Have you noticed this in your testing?  Can 
you think of a way to avoid the inconsistency without changing all these 
combined getInstance() calls?

thanks

Tony


On 10/6/23 9:55 AM, Martin Balao wrote:
> Hi Tony,
> 
> Thanks for having a look at our proposal.
> 
> The main motivation for this enhancement is related to cryptographic 
> policy enforcement and, in particular, the following capabilities: 1) 
> enforcing that cryptographic services are provided by chosen security 
> providers only, and 2) allowing or disallowing selected algorithms or 
> service types across all Java Security APIs.
> 
> None of this is entirely new. In regards to capability #1, users can 
> install or uninstall security providers already, or rely on priorities 
> and algorithms shadowing. However, we deem this insufficient for the 
> purposes of policy enforcement, lacking in flexibility, and at risk of 
> introducing dependencies on implementation details. Some more details 
> are provided under the section "What is the current limitation?" of the 
> 8315487 ticket [1]. As for capability #2, there is partial support 
> currently: algorithms can be blocked from TLS or certificate paths 
> validation uses but not across all JCA APIs. Thus, we share some of the 
> motivations that led to existing features but intend to have a more 
> powerful, comprehensive and flexible solution. As documented in our 
> proposal, both solutions were combined in a multi-layer model.
> 
> The FIPS case is interesting because it requires a combination of 
> capabilities #1 and #2. However, there are other cases that could 
> benefit from different policies. I have described some of them below, 
> providing a summary rationale for why a user might want to adopt the 
> given policy, a filter conforming to the proposal that would achieve the 
> desired outcome, and a comparison with how the same outcome might be met 
> (or potentially be hard/impossible to meet) with the status quo. See 
> Appendix #1.
> 
> As with most security properties, a specific configuration may render an 
> application completely or partially unusable, and require a 
> sysadmin/developer/security-expert to perform an assessment. This effect 
> may be a desired outcome and trigger a remediation action. Other 
> applications may react in a more resilient way and smoothly adapt to the 
> policy enforced: use cryptography from an allowed security provider, 
> skip the use of algorithms that are not allowed, ask the user to take 
> action, etc. Our concern is that the lack of strong policy enforcement 
> capabilities may lead to non-compliance issues going unnoticed.
> 
> Existing security capabilities such as the one to install or uninstall 
> security providers, or even the one that allows to select preference per 
> algorithm, require the knowledge of what these security providers 
> implement and what applications require to use. Our proposal allows 
> better granularity but is not different in terms of relying on public 
> documentation or sysadmin/developer/security-expert knowledge.
> 
> While we don't necessarily share the view of the syntax as hard to use 
> or error-prone, we concede that it leans more towards the expert UI side 
> of all security properties. We designed the syntax with the ideas of 
> consistency, similarity to the serialization filter ?to the extent 
> possible?, simplicity for trivial cases and powerfulness for complex 
> ones. We want to make sure that it's not only tailored to our needs 
> today but generic enough for other current or future uses. We tried to 
> explain the use cases and desirable properties underneath the proposed 
> design, but at the same time we would like to know if there is any 
> aspect in particular that is of your concern and if you have any 
> improvements to suggest so it's more accessible to less experienced 
> users. We are open to considering specification, implementation and/or 
> documentation changes.
> 
> Thanks,
> Martin.-
> 
> -- 
> 
> Appendix #1
> 
> 1) A policy that only authorizes the storage of certificates and keys in 
> PKCS #11 devices, or in a specific instance managed by the 
> CentralKeysProvider security provider:
> 
> *.KeyStore.PKCS11; !*.KeyStore; *
> 
> or
> 
> CentralKeysProvider.KeyStore; !*.KeyStore; *
> 
> In this scenario, a system administrator is concerned about how 
> applications store sensitive cryptographic keys and intends to enforce a 
> centralized or more restricted management. This policy aims to mitigate 
> security risks and drawbacks associated with local file-based key 
> storage. In the event of a key update, if centralized management is 
> applied, applications have access to the latest key without any key 
> population hassle. While this policy imposes restrictions on key 
> storage, any security provider (including OpenJDK default ones) can use 
> these keys after retrieval. This latter observation is relevant when, 
> for example, PKCS #11 token devices with limited performance or 
> algorithms availability are used.
> 
> We deem this type of policy useful for scenarios where centralized key 
> management is feasible and desirable, or scenarios where keys are stored 
> in hardware devices.
> 
> Enforcing this policy without the Security Provider Filter would be 
> hard. While changing the default key store type by means of the 
> keystore.type security property is possible, that configuration does not 
> make other key store types unavailable. In addition, this security 
> property lets users choose a key store algorithm but not its provider. 
> Uninstalling security providers that offer unwanted KeyStore service 
> types is not always an option because other service types they offer 
> might be legitimately required. In other words, this option lacks 
> granularity. The only way to enforce a policy such as the one described 
> in this case is to audit the application and library sources, 
> configurations or logs and check how keys are managed. This approach 
> would require manual actions and rechecks after each application or 
> library change.
> 
> The Security Provider Filter makes the enforcement of this policy easy, 
> even under the circumstances of an application or library update, or 
> after the deployment of a new application. The policy can also be 
> updated to include other key store algorithms, security providers or 
> combinations of both.
> 
> 2) A policy that enforces the use of PKCS #12 key stores only:
> 
> *.KeyStore.PKCS12; !*.KeyStore; *
> 
> In this scenario, a system administrator is concerned about applications 
> using key stores with non-standard formats such as JKS, JCEKS, BKS 
> (Bouncy Castle) or BCFKS (Bouncy Castle) among others. These key store 
> algorithms may introduce interoperability issues and require unwanted 
> file conversions at some point. Thus, the system administrator enforces 
> a policy that only authorizes the PKCS #12 standard for key storage.
> 
> As in case #1, the security property for controlling the default key 
> store type is not enough to prevent applications from using other 
> formats; uninstalling security providers is not always an option; and 
> auditing application or libraries source code, configurations or logs to 
> check how key storage is done could be inconvenient or unfeasible.
> 
> The Security Provider Filter provides flexibility to change the approved 
> key store type or authorize more than one. Third-party security 
> providers may refer to the PKCS #12 standard by different algorithm 
> names but that should not be a problem either. For example, the filter 
> may authorize algorithm name variations such as PKCS12, BCPKCS12 (Bouncy 
> Castle) and PKCS12-3DES-3DES (Bouncy Castle): "*.KeyStore.PKCS12; 
> *.KeyStore.BCPKCS12; *.KeyStore.PKCS12-3DES-3DES; ...", or more simply 
> "*.KeyStore.*PKCS12*; ...".
> 
> 3) A policy that does not allow algorithms considered insecure:
> 
> !*.*.MD5; !*.*.MD2; !*.*.SHA-1; *
> 
> Security concerns are the motivation behind this type of policy. A 
> system administrator may enforce it with a deny-list ?as done in the 
> example? or even with a more strict allow-list one. This type of policy 
> can be applied with algorithms considered secure today or algorithms 
> that will be required in the future. The latter serves for the purpose 
> of identifying potential compatibility issues and providing applications 
> advanced notice to adapt.
> 
> While the Security Provider Filter is platform-independent, Linux 
> crypto-policies is one of the motivations related to this case. Many 
> Linux distributions, such as RHEL [2], have system-wide crypto-policies 
> enabled by default. Different crypto-policies profiles (LEGACY, DEFAULT, 
> FIPS, FUTURE, etc.) define sets of algorithms authorized for different 
> software packages, including OpenJDK. Our intention is that 
> crypto-policies for OpenJDK define, according to each profile, the set 
> of algorithms allowed for all security APIs.
> 
> Before the Security Provider Filter, algorithms can be restricted for 
> some uses with a deny-list type of configuration. However, not all uses 
> are under scope and applications may use unauthorized algorithms by 
> calling, for example, Signature.getInstance("<unauthorized-algorithm>") 
> and using the service directly. Other approaches such as auditing 
> application and libraries source code, configurations or logs to check 
> which algorithms are used may not be practical, as pointed out in case #1.
> 
> The Security Provider Filter allows a system administrator to keep sets 
> of authorized algorithms updated and apply its policy widely to all JCA 
> service types.
> 
> 4) A policy in which some uses of MD5 are acceptable (e.g. 
> MessageDigest) but others are not:
> 
> !*.Signature.MD5*; !*.Mac.*MD5; !*.Cipher.*MD5*; *
> 
> or
> 
> *.MessageDigest.MD5; !*.*.*MD5*; *
> 
> Some algorithms may be secure for some uses but not for others. In this 
> case, a system administrator authorizes MD5 for UUIDs, redundancy-check 
> codes or other hashes, but prohibits its use for signatures, message 
> authentication, and for deriving encryption keys (PBE).
> 
> This type of policy enforcement is possible because the Security 
> Provider Filter lets users specify the service type, in addition to the 
> algorithm. A system administrator can easily adjust the algorithms and 
> service types that are allowed or disallowed.
> 
> For the same reasons explained in case #3, implementing this policy 
> without the Security Provider Filter would not be possible or practical.
> 
> 5) A policy in which only algorithms implemented by the FastProvider 
> security provider are authorized for encryption:
> 
> FastProvider.Cipher; !*.Cipher; *
> 
> In this case, a system administrator is concerned about performance and 
> wants applications to only do cipher operations in FastProvider.
> 
> While it is possible to insert FastProvider in the first place of the 
> security providers list, or even use the preferred algorithms security 
> property, an application that is using an algorithm not available in 
> FastProvider will silently slide to a slower implementation. As 
> described for other cases, removing slower security providers may not be 
> an option, and auditing applications or libraries source code, 
> configurations or logs may not be practical.
> 
> 6) A policy that only allows a specific source of randomness, 
> irrespective of the algorithm:
> 
> SunPKCS11-HSM.SecureRandom; !*.SecureRandom; *
> 
> A system administrator has security concerns about sources of randomness 
> and decides to authorize only one of them, irrespective of the 
> algorithm. In this case, the prioritized list of security providers is 
> not enough to use SunPKCS11-HSM because applications may try to use 
> algorithms not implemented there and silently slide into other security 
> providers.
> 
> Enforcing this type of policy without the Security Provider Filter may 
> require actions such as uninstalling security providers or auditing 
> source code, configurations or logs that is not always possible or 
> practical.
> 
> 7) In CRIU scenarios, it could be beneficial to enforce a policy that 
> does not allow the use of random values or key generation before a 
> snapshot is taken. A snapshot can be taken, for example, running the JDK 
> with the following filter value:
> 
> !*.SecureRandom; !*.KeyPairGenerator; !*.KeyGenerator; *
> 
> In some cases, a system administrator might want to enforce an even more 
> strict policy using an allow-list approach:
> 
> *.MessageDigest.SHA-1; *.CertificateFactory; !*
> 
> When resuming a snapshot, no filter is set.
> 
> This example is based on a real case. To achieve the desired effect 
> without the Security Providers Filter, a system administrator has to 
> create a custom security provider that only implements authorized 
> service types and algorithms. This security provider is the only one 
> installed while taking the snapshot. When resuming snapshots, all 
> security providers are enabled. This solution is hard to implement and 
> not easily extensible to other service types and algorithms. With the 
> Security Providers Filter it is easy to decide what is available while 
> taking a snapshot, and what is available while resuming it.
> 
> This type of policy falls into the category of those that may benefit 
> the security of a deployment. The reuse of random seeds or keys in 
> different executions of the same snapshot may weaken or compromise the 
> security of a system.
> 
> 8) A policy that allows the use of a 3rd party security provider for a 
> specific purpose but not for anything else:
> 
> 3rdPartyProvider.AllowedService; !3rdPartyProvider; *
> 
> In this case, a system administrator has concerns of applications 
> depending on a specific security provider for more service types or 
> algorithms than what is authorized (AllowedService).
> 
> This type of policy is difficult to implement without the Security 
> Provider Filter because there is no granularity when installing a 
> security provider: it's an all or nothing decision. Thus, the only way 
> around to enforce compliance is to check applications or libraries 
> source code, configurations or logs and understand what they are 
> depending on.
> 
> Examples Summary
> 
> Throughout the previous scenarios, we have discussed security, 
> interoperability and performance concerns that may be addressed by the 
> Security Providers Filter. What all these cases have in common is policy 
> enforcement at provider, service type or algorithm level. We think that 
> the existing providers or algorithms preference configurations miss the 
> partial or total closure that the Filter offers. In addition, the lack 
> of granularity makes the installation of a security provider an all or 
> nothing decision. Thus, policy enforcement can only be applied by 
> auditing applications or libraries source code, configuration or logs. 
> This type of enforcement is not always possible or practical: a new 
> deployment or update of an existing one requires a check. The existing 
> functionality to block the use of algorithms does not extend to all 
> security APIs and it's, thus, not enough from a policy enforcement and 
> compliance perspective. While we have showcased fabricated system 
> administration scenarios in some cases, others are of general interest, 
> can be used more widely or represent real cases. On a final note, we 
> have intentionally left the FIPS use-case out of this Appendix as it has 
> been discussed in previous comments.
> 
> -- 
> [1] - https://bugs.openjdk.org/browse/JDK-8315487
> [2] - 
> https://urldefense.com/v3/__https://access.redhat.com/articles/3666211__;!!ACWV5N9M2RV99hQ!Po2RuiDeYlR92dfYip2ezt4Rm3LYPgRNL7QyeHqnNxFwSisPcez2ySr3eFLgt2vLeJhwN2qZKwcedWuMlYnq$
> 
> 
> On 9/19/23 16:42, Anthony Scarpino wrote:
>> Hi Martin,
>>
>> Thanks for the proposal. Your documents mostly describe the solution. 
>> Can you provide more of the motivations and use-cases for the change? 
>> Do you see non FIPS-140 applications using this feature?
>>
>> The feature does provide a comprehensive filtering system for JCA. The 
>> syntax, while powerful, seems like it would be somewhat error-prone 
>> and hard to use. We are also concerned that using the filter requires 
>> the sysadmin or developer to know about the service and algorithm 
>> details of every provider and which is required and which is not, all 
>> of which is not easily determined.
>>
>> thanks
>>
>> Tony
> 

From aturbanov at openjdk.org  Thu Oct 26 11:02:33 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 26 Oct 2023 11:02:33 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError [v2]
In-Reply-To: <cx9pgdiMSuOQWVFVl8bG-xmqHpKRtT5AxIgQvxcJgNA=.d09c998d-52ab-4fa1-b280-c8fc64afdbe2@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
 <cx9pgdiMSuOQWVFVl8bG-xmqHpKRtT5AxIgQvxcJgNA=.d09c998d-52ab-4fa1-b280-c8fc64afdbe2@github.com>
Message-ID: <1z46SNEeQcxuR4i--NzIoXuqkTybtusqo88Vwfkaz6Q=.a004a3f5-ccac-45ff-a377-cc49a03febc9@github.com>

On Fri, 20 Oct 2023 02:29:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review a patch that renames `JavaLangAccess::xxNoRepl` to `xxReportError` to explicitly indicate these APIs report encoding errors.
>> 
>> The old "NoRepl" suffix presumably means "No Replacement", but it has been misunderstood as "No Replication" (#16209) and misused as an array sharing API in performance optimization patches.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoRepl -> ReportError

src/java.base/share/classes/java/lang/System.java line 2476:

> 2474:                 return StringCoding.countPositives(bytes, offset, length);
> 2475:             }
> 2476:             public String newStringReportError(byte[] bytes, Charset cs) throws CharacterCodingException  {

Suggestion:

            public String newStringReportError(byte[] bytes, Charset cs) throws CharacterCodingException {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16260#discussion_r1372975296

From andrew at openjdk.org  Thu Oct 26 14:22:35 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 26 Oct 2023 14:22:35 GMT
Subject: RFR: 8009550: PlatformPCSC should load versioned so [v2]
In-Reply-To: <L2ioCo2Ws3Fe5KkDeEoilmI9ovXqp45gUqusTa1nnrg=.24788918-3e94-4f6a-bdae-cb04aed9f94d@github.com>
References: <RTKWEF6u5gjRIn77MGeEO6ZE56DyD1J8bChHNej48IU=.b8c6d676-340e-4555-a4c2-2d04d5b97590@github.com>
 <e5fcJlIAjfuqoDDV2xBujV1-EBquZBuRinX-rIzCdoM=.90c7fcbd-1d78-4887-a6c9-302db26c5156@github.com>
 <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com>
 <L2ioCo2Ws3Fe5KkDeEoilmI9ovXqp45gUqusTa1nnrg=.24788918-3e94-4f6a-bdae-cb04aed9f94d@github.com>
Message-ID: <UMBQfVzN8J-_UjBi20Itz-p2-6VFy-QAtaNppegV52M=.7c645aab-fca0-4b74-b3d4-e25c75d2bf9a@github.com>

On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. BTW, I added a noreg-other label since there is no regression test for this change.
>> 
>> Thanks. Yes, I don't see how we can have a regression test for this one. My own testing was manual and involved moving the system library around as root...
>
>> > Hi @gnu-andrew,
>> > in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why?
>> > I would expect it only to attempt and pick up the architecture and OS the VM was built for.
>> 
>> Good question.
>> 
>> Because they don't fit the template `$ARCH-linux-gnu/libpcsclite.so` which would expand to `arm-linux-gnu/libpcsclite.so`.
>> 
>> I don't know of a way off-hand to get the ABI or the kernel in use (`kfreebsd` is not a BSD variant, but the usual GNU userland paired with the FreeBSD kernel rather than Linux). The [Wikipedia page](https://en.wikipedia.org/wiki/Debian#Derivatives_and_flavors) actually says it's now discontinued, so maybe we can just drop that one. It probably shows how long ago I [originally wrote and tested these paths](https://icedtea.wildebeest.org/hg/release/icedtea7-forest-2.6/jdk/rev/ae5765c7b8e2)... :)
>> 
>> In short, that was my lazy option for catching those cases that won't fit the common one. I'm open to suggestions. We could skip any template with `'arm'` in, I guess, if the architecture doesn't match. It is worth noting though, that this file is already common to all the UNIX platforms and doesn't do any OS checks, despite the last check being a MacOS framework. That also presumably means MacOS doesn't have any of the `/usr` libraries in turn .
> 
> Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong library on a mulitarch system, since having multiple  of these directories is the point of multiarch.
> 
> But maybe its fine. The difference between the arm variants is that the float mode (soft vs hard) and I believe the former should always work, so if we accidentally pick it up, it should be no problem.
> 
> The kfreebsd one I'd just drop.

@tstuefe can I get a final ok on this one to push? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1781228578

From stuefe at openjdk.org  Thu Oct 26 14:28:35 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 26 Oct 2023 14:28:35 GMT
Subject: RFR: 8009550: PlatformPCSC should load versioned so [v2]
In-Reply-To: <UMBQfVzN8J-_UjBi20Itz-p2-6VFy-QAtaNppegV52M=.7c645aab-fca0-4b74-b3d4-e25c75d2bf9a@github.com>
References: <RTKWEF6u5gjRIn77MGeEO6ZE56DyD1J8bChHNej48IU=.b8c6d676-340e-4555-a4c2-2d04d5b97590@github.com>
 <e5fcJlIAjfuqoDDV2xBujV1-EBquZBuRinX-rIzCdoM=.90c7fcbd-1d78-4887-a6c9-302db26c5156@github.com>
 <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com>
 <L2ioCo2Ws3Fe5KkDeEoilmI9ovXqp45gUqusTa1nnrg=.24788918-3e94-4f6a-bdae-cb04aed9f94d@github.com>
 <UMBQfVzN8J-_UjBi20Itz-p2-6VFy-QAtaNppegV52M=.7c645aab-fca0-4b74-b3d4-e25c75d2bf9a@github.com>
Message-ID: <qbrCs1bQ4Z36G-MXRbEt2f4EFdZ7ryh_-TS2niJxSPM=.19b55c04-6160-4386-a885-80a8277cab31@github.com>

On Thu, 26 Oct 2023 14:19:32 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>>> > Hi @gnu-andrew,
>>> > in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why?
>>> > I would expect it only to attempt and pick up the architecture and OS the VM was built for.
>>> 
>>> Good question.
>>> 
>>> Because they don't fit the template `$ARCH-linux-gnu/libpcsclite.so` which would expand to `arm-linux-gnu/libpcsclite.so`.
>>> 
>>> I don't know of a way off-hand to get the ABI or the kernel in use (`kfreebsd` is not a BSD variant, but the usual GNU userland paired with the FreeBSD kernel rather than Linux). The [Wikipedia page](https://en.wikipedia.org/wiki/Debian#Derivatives_and_flavors) actually says it's now discontinued, so maybe we can just drop that one. It probably shows how long ago I [originally wrote and tested these paths](https://icedtea.wildebeest.org/hg/release/icedtea7-forest-2.6/jdk/rev/ae5765c7b8e2)... :)
>>> 
>>> In short, that was my lazy option for catching those cases that won't fit the common one. I'm open to suggestions. We could skip any template with `'arm'` in, I guess, if the architecture doesn't match. It is worth noting though, that this file is already common to all the UNIX platforms and doesn't do any OS checks, despite the last check being a MacOS framework. That also presumably means MacOS doesn't have any of the `/usr` libraries in turn .
>> 
>> Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong library on a mulitarch system, since having multiple  of these directories is the point of multiarch.
>> 
>> But maybe its fine. The difference between the arm variants is that the float mode (soft vs hard) and I believe the former should always work, so if we accidentally pick it up, it should be no problem.
>> 
>> The kfreebsd one I'd just drop.
>
> @tstuefe can I get a final ok on this one to push? Thanks.

@gnu-andrew still looks okay to me. Thanks for taking my suggestion. Sorry for overlooking this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1781240845

From lkorinth at openjdk.org  Thu Oct 26 15:33:38 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 26 Oct 2023 15:33:38 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <CZyt2tGATgYnxwwXcRUx-f2W4UTwCRouztmSTtinrTw=.6dc482ad-77ad-4d75-94ab-0ae273d0a2a8@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Would it be okay if we handle the new method documentation in a separate pull request? 

After applying your changes, I also noted that the existing description `The command line will be like: {test.jdk}/bin/java {test.vm.opts} {test.java.opts} cmds` is not only incorrect (or at least incomplete), but now also clashes with the added description. I then removed the sentence, but after I did that I also found out that similar wording exist in `executeTestJvm` and I fear that if I continue to pull strings, I will create more and more changes that you will have opinions on.

Is it all right if we push what we have now, and that I create a new pull requests with these improvements in documentation that are actually not related to the changes in this pull request?

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1781359450

From rriggs at openjdk.org  Thu Oct 26 16:29:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Oct 2023 16:29:40 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <Yx-2Zuy3fBrCV9jiHIiGJSLOBBy7Hv9BVRBeB1ytvLk=.e3026827-3141-4ee4-b8ea-2d459d42eabf@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

ok, to correct the javadoc in a subsequent PR.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1700061972

From mullan at openjdk.org  Thu Oct 26 16:39:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 26 Oct 2023 16:39:32 GMT
Subject: RFR: 8318689: jtreg is confused when folder name is the same as
 the test name
In-Reply-To: <UZ505yWfItHh_nFHorv9cW20a1MdmvZWP5kYMbfXaQw=.08ff7d64-cb37-4c33-8d4c-091be65e4df2@github.com>
References: <UZ505yWfItHh_nFHorv9cW20a1MdmvZWP5kYMbfXaQw=.08ff7d64-cb37-4c33-8d4c-091be65e4df2@github.com>
Message-ID: <Rkp2Y_2_0BCnF53HaT_vtGCIxaDfXIRWQPMSxE2MuIE=.b7a36665-9055-4558-b0c6-014fff155418@github.com>

On Mon, 23 Oct 2023 21:07:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Rename the test.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16323#pullrequestreview-1700078879

From weijun at openjdk.org  Thu Oct 26 16:43:47 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Oct 2023 16:43:47 GMT
Subject: Integrated: 8318689: jtreg is confused when folder name is the same as
 the test name
In-Reply-To: <UZ505yWfItHh_nFHorv9cW20a1MdmvZWP5kYMbfXaQw=.08ff7d64-cb37-4c33-8d4c-091be65e4df2@github.com>
References: <UZ505yWfItHh_nFHorv9cW20a1MdmvZWP5kYMbfXaQw=.08ff7d64-cb37-4c33-8d4c-091be65e4df2@github.com>
Message-ID: <YY1i-VhSCliSnVAao3vsMmKW4DyjDRExcF-t4oxQs30=.83683bed-f1e2-4816-b900-b064ca17c9cb@github.com>

On Mon, 23 Oct 2023 21:07:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Rename the test.

This pull request has now been integrated.

Changeset: a9b31b58
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9b31b587c7487b2222773debde1ce2227884959
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8318689: jtreg is confused when folder name is the same as the test name

Reviewed-by: mullan

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

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

From mullan at openjdk.org  Thu Oct 26 17:15:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 26 Oct 2023 17:15:36 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v5]
In-Reply-To: <nQ-RZxXcZHn7M10UYq-sdkZNE6OXgq-OFlCtPcy0Has=.8abdaa0e-d59e-4990-9844-d8013e79d406@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <nQ-RZxXcZHn7M10UYq-sdkZNE6OXgq-OFlCtPcy0Has=.8abdaa0e-d59e-4990-9844-d8013e79d406@github.com>
Message-ID: <wdaChZhG2qun2RIOhIlE6JEViWhDYP9cvFpr1bV-TUc=.89bc9a9d-36b4-49ff-bea7-c932bcd6c099@github.com>

On Thu, 26 Oct 2023 02:43:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
>> 
>> No test. Might add one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use @inheritDoc

src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line 74:

> 72:      */
> 73:     @Override
> 74:     default AlgorithmParameterSpec getParams() {

What is the benefit of overriding this method if it returns the same type?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 902:

> 900:         }
> 901: 
> 902:         public DSAParams getParams() {

Suggest adding an `@Override` annotation here and below to make it more clear this is an overridden method.

test/jdk/java/security/Signature/GetParams.java line 1:

> 1: /*

Why is this test in the Signature directory? Should it just be in the java/security dir?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373486381
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373475664
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373490613

From weijun at openjdk.org  Thu Oct 26 17:37:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Oct 2023 17:37:01 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v6]
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <4ew8o3Qip-K3iwtirvJigIJGr9AIOJ3MM0spMnUPQXA=.e5a6b31d-90d3-478b-b067-c81c14a47615@github.com>

> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
> 
> No test. Might add one.

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

  move the test, add annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16222/files
  - new: https://git.openjdk.org/jdk/pull/16222/files/319eaa54..578c5f26

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

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

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

From weijun at openjdk.org  Thu Oct 26 17:37:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Oct 2023 17:37:04 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v5]
In-Reply-To: <wdaChZhG2qun2RIOhIlE6JEViWhDYP9cvFpr1bV-TUc=.89bc9a9d-36b4-49ff-bea7-c932bcd6c099@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <nQ-RZxXcZHn7M10UYq-sdkZNE6OXgq-OFlCtPcy0Has=.8abdaa0e-d59e-4990-9844-d8013e79d406@github.com>
 <wdaChZhG2qun2RIOhIlE6JEViWhDYP9cvFpr1bV-TUc=.89bc9a9d-36b4-49ff-bea7-c932bcd6c099@github.com>
Message-ID: <QLexRqH_e1P-zrykG1O6QHenjPwaJa7aMGIxeU6Zu9g=.0bc12bbf-5ff0-4f10-abbc-58a7b20f488f@github.com>

On Thu, 26 Oct 2023 17:08:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use @inheritDoc
>
> src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line 74:
> 
>> 72:      */
>> 73:     @Override
>> 74:     default AlgorithmParameterSpec getParams() {
> 
> What is the benefit of overriding this method if it returns the same type?

Otherwise, there will be an error `interface RSAPrivateKey inherits unrelated defaults for getParams() from types AsymmetricKey and RSAKey`. I think this is because `RSAKey` is not a `Key`.

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 902:
> 
>> 900:         }
>> 901: 
>> 902:         public DSAParams getParams() {
> 
> Suggest adding an `@Override` annotation here and below to make it more clear this is an overridden method.

There are a lot of places in this class without `@Override`. Shall I add all of them or just the 2 places I touched this time?

> test/jdk/java/security/Signature/GetParams.java line 1:
> 
>> 1: /*
> 
> Why is this test in the Signature directory? Should it just be in the java/security dir?

It should not be in Signature. The java/security dir has only subdirs and no test. Maybe I create a new AsymmetricKey dir and move it there?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373502707
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373500436
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373505291

From mullan at openjdk.org  Thu Oct 26 17:37:05 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 26 Oct 2023 17:37:05 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v5]
In-Reply-To: <QLexRqH_e1P-zrykG1O6QHenjPwaJa7aMGIxeU6Zu9g=.0bc12bbf-5ff0-4f10-abbc-58a7b20f488f@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <nQ-RZxXcZHn7M10UYq-sdkZNE6OXgq-OFlCtPcy0Has=.8abdaa0e-d59e-4990-9844-d8013e79d406@github.com>
 <wdaChZhG2qun2RIOhIlE6JEViWhDYP9cvFpr1bV-TUc=.89bc9a9d-36b4-49ff-bea7-c932bcd6c099@github.com>
 <QLexRqH_e1P-zrykG1O6QHenjPwaJa7aMGIxeU6Zu9g=.0bc12bbf-5ff0-4f10-abbc-58a7b20f488f@github.com>
Message-ID: <TopEvci8FVFL7fhaOb_nW83ljIJX5oTukDq07e-xtj4=.70a85ec9-ffb8-4509-9a62-d43f8c2fcaa4@github.com>

On Thu, 26 Oct 2023 17:23:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line 74:
>> 
>>> 72:      */
>>> 73:     @Override
>>> 74:     default AlgorithmParameterSpec getParams() {
>> 
>> What is the benefit of overriding this method if it returns the same type?
>
> Otherwise, there will be an error `interface RSAPrivateKey inherits unrelated defaults for getParams() from types AsymmetricKey and RSAKey`. I think this is because `RSAKey` is not a `Key`.

I see. Ok.

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 902:
>> 
>>> 900:         }
>>> 901: 
>>> 902:         public DSAParams getParams() {
>> 
>> Suggest adding an `@Override` annotation here and below to make it more clear this is an overridden method.
>
> There are a lot of places in this class without `@Override`. Shall I add all of them or just the 2 places I touched this time?

Probably just these 2 static classes to keep the changes focused.

>> test/jdk/java/security/Signature/GetParams.java line 1:
>> 
>>> 1: /*
>> 
>> Why is this test in the Signature directory? Should it just be in the java/security dir?
>
> It should not be in Signature. The java/security dir has only subdirs and no test. Maybe I create a new AsymmetricKey dir and move it there?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373512090
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373509228
PR Review Comment: https://git.openjdk.org/jdk/pull/16222#discussion_r1373506051

From mullan at openjdk.org  Thu Oct 26 17:41:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 26 Oct 2023 17:41:32 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v6]
In-Reply-To: <4ew8o3Qip-K3iwtirvJigIJGr9AIOJ3MM0spMnUPQXA=.e5a6b31d-90d3-478b-b067-c81c14a47615@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <4ew8o3Qip-K3iwtirvJigIJGr9AIOJ3MM0spMnUPQXA=.e5a6b31d-90d3-478b-b067-c81c14a47615@github.com>
Message-ID: <AAOYBlQfKU1iEBkNoO7l4_pK9guQJN1MtbnKbTayyJg=.c89c9cca-1372-4e6e-b7b1-9fd03a618282@github.com>

On Thu, 26 Oct 2023 17:37:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
>> 
>> No test. Might add one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test, add annotations

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16222#pullrequestreview-1700180209

From hchao at openjdk.org  Thu Oct 26 20:44:45 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 26 Oct 2023 20:44:45 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Change property names to clearly indicate client side and server side

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/aca5841a..b351b418

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

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

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

From kdriver at openjdk.org  Thu Oct 26 22:09:53 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 26 Oct 2023 22:09:53 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v6]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <QvUWupWmG7rGYdbIwdLpRyEjMJSfoF2Hi30MEQQaXgw=.6902c29d-7cdf-4403-834d-d431da36ea64@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  additional updates to explicitly use PKCS12

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/e104fb92..3666328b

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

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

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

From ascarpino at openjdk.org  Thu Oct 26 22:31:32 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 26 Oct 2023 22:31:32 GMT
Subject: RFR: 8318096: Introduce AsymmetricKey interface with a getParams
 method [v6]
In-Reply-To: <4ew8o3Qip-K3iwtirvJigIJGr9AIOJ3MM0spMnUPQXA=.e5a6b31d-90d3-478b-b067-c81c14a47615@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
 <4ew8o3Qip-K3iwtirvJigIJGr9AIOJ3MM0spMnUPQXA=.e5a6b31d-90d3-478b-b067-c81c14a47615@github.com>
Message-ID: <dSqOyuSZ1RXu9SjRZ7krcBmLLXN8wqPdynKBOn-LS3Q=.f0c7f15b-657b-4d6d-b3eb-c8c2f05bdb86@github.com>

On Thu, 26 Oct 2023 17:37:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
>> 
>> No test. Might add one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test, add annotations

I agree with the changes

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16222#pullrequestreview-1700731380

From weijun at openjdk.org  Thu Oct 26 22:45:43 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Oct 2023 22:45:43 GMT
Subject: Integrated: 8318096: Introduce AsymmetricKey interface with a
 getParams method
In-Reply-To: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
References: <6XfwH29KQKaXWIO2iJaEmcf4EGNG6warU6Pq1RKRO2Q=.cfc9b941-292c-485b-a130-c8a1c30ceff0@github.com>
Message-ID: <OaY2aw7DrDWwqz8sPqDi1NBBS9aI4nojIU6D-jI8RgM=.b9d14dbe-5ad7-4927-8222-c11ee6dbfb98@github.com>

On Tue, 17 Oct 2023 15:30:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Create a parent interface `AsymmetricKey` for `PublicKey` and `PrivateKey` and add a `getParams` method there. This makes it available to all current and future public and private keys.
> 
> No test. Might add one.

This pull request has now been integrated.

Changeset: 9123961a
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9123961aaa47aa58ec436640590d2cceedb8cbb1
Stats:     313 lines in 18 files changed: 293 ins; 0 del; 20 mod

8318096: Introduce AsymmetricKey interface with a getParams method

Reviewed-by: darcy, mullan, ascarpino

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

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

From kdriver at openjdk.org  Fri Oct 27 04:21:01 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 27 Oct 2023 04:21:01 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v7]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <PDqrzklQt-p_wRXIIkzHX8wY5j_0Td3vel25gejGH9A=.35dca0ec-30c8-4a8d-b877-0cdd9eb8d290@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  Security Manager won't let you explicitly set the type here for some
  reason

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/3666328b..206e5b9c

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

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

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

From lkorinth at openjdk.org  Fri Oct 27 08:50:47 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 08:50:47 GMT
Subject: Integrated: 8315097: Rename createJavaProcessBuilder
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <n5Oky40OR8ZXdkJbSQiivcZCzZ6XP12wnJEWzcY4xYw=.d997c70c-cae2-4bf3-9d83-2f24d1cbcb22@github.com>

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

This pull request has now been integrated.

Changeset: d52a995f
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d52a995f35de26c2cc4074297a75141e4a363e1b
Stats:     1574 lines in 560 files changed: 44 ins; 10 del; 1520 mod

8315097: Rename createJavaProcessBuilder

Reviewed-by: lmesnik, dholmes, rriggs, stefank

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

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

From lkorinth at openjdk.org  Fri Oct 27 09:00:48 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:00:48 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <b2XfkO_Ez_LuJQZffSPp63wciX1NImzAD5l3Xy1elOU=.48bdc440-238c-4a86-b8b8-c2f37e2277a7@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Thanks, see:
https://bugs.openjdk.org/browse/JDK-8318962

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1782552641

From mullan at openjdk.org  Fri Oct 27 12:40:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 27 Oct 2023 12:40:32 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period
In-Reply-To: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
Message-ID: <IAGrqc7tyBt86KpmxW3yOv7F02WvEgyp6ucecp4yO_k=.99e0e6d0-39c4-4afc-a4b0-c8ecc8f27843@github.com>

On Fri, 20 Oct 2023 20:52:13 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

src/java.base/share/classes/sun/security/x509/DNSName.java line 1:

> 1: /*

On line 203, can you modify the comment to:

* RFC 5280: For DNS names, restrictions MUST use the dNSName syntax in
   Section 4.2.1.6.
   
   This matches the new text in the errata (https://www.rfc-editor.org/errata/eid5997).
   
   Also, you can remove the comments on lines 208-213 as they are duplicates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374517701

From mullan at openjdk.org  Fri Oct 27 13:04:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 27 Oct 2023 13:04:32 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period
In-Reply-To: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
Message-ID: <s2kz7DaOb-pJC3D68uryJcipxkucMf2_D8kjgGjYd14=.bf407976-bd28-4a7e-bed0-5e7e3ee58bb9@github.com>

On Fri, 20 Oct 2023 20:52:13 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 24:

> 22:  */
> 23: 
> 24: /* @test

Nit, change to:


/*
 * @test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374544912

From weijun at openjdk.org  Fri Oct 27 13:54:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Oct 2023 13:54:36 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v7]
In-Reply-To: <PDqrzklQt-p_wRXIIkzHX8wY5j_0Td3vel25gejGH9A=.35dca0ec-30c8-4a8d-b877-0cdd9eb8d290@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <PDqrzklQt-p_wRXIIkzHX8wY5j_0Td3vel25gejGH9A=.35dca0ec-30c8-4a8d-b877-0cdd9eb8d290@github.com>
Message-ID: <RRfo34QBDSa-VYluRZM-xixYY0daPFCrE9lN3WzDCFA=.9a08c834-dfd4-489c-8922-eb2dfecabc38@github.com>

On Fri, 27 Oct 2023 04:21:01 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Security Manager won't let you explicitly set the type here for some
>   reason

I have 2 comments:
1. For those system properties. If you don't set them explicitly to `pkcs12`, will there by any failure? In my understanding, the default type is already pkcs12 now.
2. For those `getInstance("JKS")` calls. Is it possible to rewrite them with `getInstance(File)`?

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

PR Comment: https://git.openjdk.org/jdk/pull/16159#issuecomment-1782957361

From duke at openjdk.org  Fri Oct 27 14:51:41 2023
From: duke at openjdk.org (Ben Perez)
Date: Fri, 27 Oct 2023 14:51:41 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
Message-ID: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>

Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance

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

Commit messages:
 - changed ServiceKey initialization to prevent caching

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

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

From mullan at openjdk.org  Fri Oct 27 15:15:35 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 27 Oct 2023 15:15:35 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period
In-Reply-To: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
Message-ID: <ios38bULFk6LchsKPXpZWhRxo7AoPyZkYOsHMeh4wh8=.72319ecd-e65d-4596-9def-cc3acf296af7@github.com>

On Fri, 20 Oct 2023 20:52:13 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 54:

> 52: 
> 53:         // generate certification path
> 54:         List<Certificate> list = Arrays.asList(targetCert, ca);

Probably simpler to use `List.of(targetCert, ca)` here.

test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 68:

> 66:         // generate a trust anchor
> 67:         TrustAnchor anchor;
> 68:         anchor = new TrustAnchor((X509Certificate) selfSignedCert, null);

You can combine these two lines.

test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 78:

> 76: 
> 77:         // disable OCSP checker
> 78:         Security.setProperty("ocsp.enable", "false");

You should not need to set this property if revocation is disabled.

test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 82:

> 80:         // disable CRL checker
> 81:         System.setProperty("com.sun.security.enableCRLDP", "false");
> 82: 

You should not need to set this property if revocation is disabled.

test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 104:

> 102:         try {
> 103:             validator.validate(pathWithoutLeadingPeriod, paramsForCAWithoutLeadingPeriod);
> 104:         } catch (CertPathValidatorException uoe) {

You don't need try/catch here since main throws Exception this will just get propagated upwards. Same comment on line 122.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374716446
PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374711648
PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374712279
PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374712640
PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1374713948

From mullan at openjdk.org  Fri Oct 27 15:36:35 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 27 Oct 2023 15:36:35 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v7]
In-Reply-To: <PDqrzklQt-p_wRXIIkzHX8wY5j_0Td3vel25gejGH9A=.35dca0ec-30c8-4a8d-b877-0cdd9eb8d290@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <PDqrzklQt-p_wRXIIkzHX8wY5j_0Td3vel25gejGH9A=.35dca0ec-30c8-4a8d-b877-0cdd9eb8d290@github.com>
Message-ID: <l2rVBsjo_la4LLgSEPG2Ws5QEAhn_XEVKnI3DbnuQU0=.2a32d557-f861-41b4-8cb3-bdf7792828b8@github.com>

On Fri, 27 Oct 2023 04:21:01 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Security Manager won't let you explicitly set the type here for some
>   reason

test/jdk/sun/security/ssl/SSLSocketImpl/NotifyHandshakeTest.java line 1:

> 1: /*

>Security Manager won't let you explicitly set the type here for some
reason

This is because `NotifyHandshakeTest.policy` (in the same directory as this test) does not grant permission to set those properties. But as noted earlier, you don't need to set these properties as they default to PKCS12.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1374746877

From ascarpino at openjdk.org  Fri Oct 27 17:08:31 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 27 Oct 2023 17:08:31 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
In-Reply-To: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
Message-ID: <EM87eJWUf36DP8bSqDpXOMM6l0q_TUq6O6W44TErBn8=.26f0dcd7-3859-49d6-91f4-458c6992a702@github.com>

On Fri, 27 Oct 2023 14:43:56 GMT, Ben Perez <duke at openjdk.org> wrote:

> Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance

I have a few questions:
- The change listed in the bug is not the same as this PR.  The bug removes the section and leaves only the new ServiceKey().  The condition statement left will always be false.
- This seems like a large performance difference for just removing a condition for the existing key.  Is the problem that is volatile?  Might removing volatile help?
- This change is done for vCPU machines.  What is the impact on non vCPU?  The reason for the caches was most likely to help single threaded performance.  How have those been situations been effected?

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

PR Comment: https://git.openjdk.org/jdk/pull/16403#issuecomment-1783239321

From mullan at openjdk.org  Fri Oct 27 19:51:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 27 Oct 2023 19:51:34 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
Message-ID: <SDhb3ejaTTDvWNPOngChFc5BaRMNTfAtr8-TBRgiHrg=.1f8ef80b-d610-4915-89d3-b3c5b69220a6@github.com>

On Thu, 26 Oct 2023 20:44:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change property names to clearly indicate client side and server side

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 112:

> 110: 
> 111:     // Maximum allowed certificate chain length
> 112:     static final int maxCertificateChainLength;

I think this can just be a local variable now inside the static block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1374983734

From hchao at openjdk.org  Fri Oct 27 20:12:44 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 27 Oct 2023 20:12:44 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Change maxCertificateChainLength to be a local variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/b351b418..d9f669f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=06-07

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

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

From hchao at openjdk.org  Fri Oct 27 20:12:48 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 27 Oct 2023 20:12:48 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <SDhb3ejaTTDvWNPOngChFc5BaRMNTfAtr8-TBRgiHrg=.1f8ef80b-d610-4915-89d3-b3c5b69220a6@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
 <SDhb3ejaTTDvWNPOngChFc5BaRMNTfAtr8-TBRgiHrg=.1f8ef80b-d610-4915-89d3-b3c5b69220a6@github.com>
Message-ID: <8o8wnBLca2Ie5qNQJjIH9vg571DR8MOXt5guCSHLkPc=.070da2c0-5819-4db1-b8ba-1ad493bec44d@github.com>

On Fri, 27 Oct 2023 19:45:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change property names to clearly indicate client side and server side
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 112:
> 
>> 110: 
>> 111:     // Maximum allowed certificate chain length
>> 112:     static final int maxCertificateChainLength;
> 
> I think this can just be a local variable now inside the static block.

Good catch. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375001603

From weijun at openjdk.org  Fri Oct 27 20:12:50 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Oct 2023 20:12:50 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
Message-ID: <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>

On Thu, 26 Oct 2023 20:44:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change property names to clearly indicate client side and server side

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 154:

> 152:             globalPropSet = true;
> 153:         }
> 154:         maxCertificateChainLength = certLen;

There is no need to set `certLen` or `maxCertificateChainLength` when `globalPropSet` is false.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 160:

> 158:                 "jdk.tls.server.maxInboundCertificateChainLength");
> 159:         if (inboundClientLen == null || inboundClientLen < 0) {
> 160:             inboundClientLen = 8;

The logic is little too long for me to digest. I wonder if we can just rewrite the line above to

inboundClientLen = globalPropSet ? maxCertificateChainLength : 8;

then there is no need for `serverPropSet` and `clientPropSet`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375001797
PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375000423

From mullan at openjdk.org  Fri Oct 27 20:21:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 27 Oct 2023 20:21:34 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
 <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
Message-ID: <aAbaVWeFCf47JW9egN3gRcS0drsgt-9cJpSIeJBFbY8=.f4279c99-9321-4599-b299-429ba129d5b2@github.com>

On Fri, 27 Oct 2023 20:07:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change property names to clearly indicate client side and server side
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 160:
> 
>> 158:                 "jdk.tls.server.maxInboundCertificateChainLength");
>> 159:         if (inboundClientLen == null || inboundClientLen < 0) {
>> 160:             inboundClientLen = 8;
> 
> The logic is little too long for me to digest. I wonder if we can just rewrite the line above to
> 
> inboundClientLen = globalPropSet ? maxCertificateChainLength : 8;
> 
> then there is no need for `serverPropSet` and `clientPropSet`.

Hmm, but how does this work? The inbound properties override the global property if both are set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375007615

From weijun at openjdk.org  Fri Oct 27 20:21:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Oct 2023 20:21:35 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <aAbaVWeFCf47JW9egN3gRcS0drsgt-9cJpSIeJBFbY8=.f4279c99-9321-4599-b299-429ba129d5b2@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
 <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
 <aAbaVWeFCf47JW9egN3gRcS0drsgt-9cJpSIeJBFbY8=.f4279c99-9321-4599-b299-429ba129d5b2@github.com>
Message-ID: <ZpaqAGux1R1OM3k4YQUKqcv_H0UZsLT4OmokDM9rQPQ=.41856cd4-8f7d-4a2b-8bda-756149809d77@github.com>

On Fri, 27 Oct 2023 20:15:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 160:
>> 
>>> 158:                 "jdk.tls.server.maxInboundCertificateChainLength");
>>> 159:         if (inboundClientLen == null || inboundClientLen < 0) {
>>> 160:             inboundClientLen = 8;
>> 
>> The logic is little too long for me to digest. I wonder if we can just rewrite the line above to
>> 
>> inboundClientLen = globalPropSet ? maxCertificateChainLength : 8;
>> 
>> then there is no need for `serverPropSet` and `clientPropSet`.
>
> Hmm, but how does this work? The inbound properties override the global property if both are set.

This belongs to the `if (inboundClientLen == null || inboundClientLen < 0)` side. The else side stays the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375009903

From weijun at openjdk.org  Fri Oct 27 20:21:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Oct 2023 20:21:38 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
Message-ID: <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>

On Fri, 27 Oct 2023 20:12:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change maxCertificateChainLength to be a local variable

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 178:

> 176:          * the jdk.tls.maxCertificateChainLength property will not override
> 177:          * the values.
> 178:          */

English is not my native language, but I have some comment on the wording. Normally we don't say `maxCertificateChainLength` overrides `maxInboundCertificateChainLength`. In fact, it is `maxInboundCertificateChainLength` that _overrides_ `maxCertificateChainLength`. When `maxInboundCertificateChainLength` is not set, it _fallbacks_ to `maxCertificateChainLength` (if set) or a _default_ value (8).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375008699

From weijun at openjdk.org  Fri Oct 27 20:27:33 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Oct 2023 20:27:33 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <ZpaqAGux1R1OM3k4YQUKqcv_H0UZsLT4OmokDM9rQPQ=.41856cd4-8f7d-4a2b-8bda-756149809d77@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
 <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
 <aAbaVWeFCf47JW9egN3gRcS0drsgt-9cJpSIeJBFbY8=.f4279c99-9321-4599-b299-429ba129d5b2@github.com>
 <ZpaqAGux1R1OM3k4YQUKqcv_H0UZsLT4OmokDM9rQPQ=.41856cd4-8f7d-4a2b-8bda-756149809d77@github.com>
Message-ID: <b90orJf4inXXSEhNc6avgEOKjC9i59LlFtvjLU2Z_z4=.8b0bac1c-a188-4711-9cf9-fe2fa9f70e45@github.com>

On Fri, 27 Oct 2023 20:19:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hmm, but how does this work? The inbound properties override the global property if both are set.
>
> This belongs to the `if (inboundClientLen == null || inboundClientLen < 0)` side. The else side stays the same.

Precisely, it's

        if (inboundServerLen == null || inboundServerLen < 0) {
            maxInboundClientCertChainLen = globalPropSet ? maxCertificateChainLength : 8;;
        } else {
            maxInboundClientCertChainLen = inboundServerLen;
        }

and nothing else is needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1375011896

From duke at openjdk.org  Fri Oct 27 22:22:46 2023
From: duke at openjdk.org (Ben Perez)
Date: Fri, 27 Oct 2023 22:22:46 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
 [v2]
In-Reply-To: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
Message-ID: <rWs8ZoxaYfF-ic7_DXmVpnbX7XMPCtYskTOZiuZebh0=.c990a69c-ca57-49f7-a531-c3ec890797e1@github.com>

> Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  changed fix to align with bug report

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16403/files
  - new: https://git.openjdk.org/jdk/pull/16403/files/123ce021..c33e1cd9

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

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

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

From duke at openjdk.org  Fri Oct 27 22:22:47 2023
From: duke at openjdk.org (Ben Perez)
Date: Fri, 27 Oct 2023 22:22:47 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
In-Reply-To: <EM87eJWUf36DP8bSqDpXOMM6l0q_TUq6O6W44TErBn8=.26f0dcd7-3859-49d6-91f4-458c6992a702@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
 <EM87eJWUf36DP8bSqDpXOMM6l0q_TUq6O6W44TErBn8=.26f0dcd7-3859-49d6-91f4-458c6992a702@github.com>
Message-ID: <fkIbXM-Mhi2v6PRakolGhaWVZitZ4mSCj3WpR-YLXOA=.003a0999-ac61-4c63-8a15-d06561b54c7c@github.com>

On Fri, 27 Oct 2023 17:05:36 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I have a few questions:
> 
> * The change listed in the bug is not the same as this PR.  The bug removes the section and leaves only the new ServiceKey().  The condition statement left will always be false.
> * This seems like a large performance difference for just removing a condition for the existing key.  Is the problem that is volatile?  Might removing volatile help?
> * This change is done for vCPU machines.  What is the impact on non vCPU?  The reason for the caches was most likely to help single threaded performance.  How have those been situations been effected?

Just fixed the first bullet. I'll investigate the latter two points and see if just removing volatile is sufficient and what the impact is on non vCPUs

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

PR Comment: https://git.openjdk.org/jdk/pull/16403#issuecomment-1783570774

From shade at openjdk.org  Mon Oct 30 11:13:32 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Oct 2023 11:13:32 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
 [v2]
In-Reply-To: <rWs8ZoxaYfF-ic7_DXmVpnbX7XMPCtYskTOZiuZebh0=.c990a69c-ca57-49f7-a531-c3ec890797e1@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
 <rWs8ZoxaYfF-ic7_DXmVpnbX7XMPCtYskTOZiuZebh0=.c990a69c-ca57-49f7-a531-c3ec890797e1@github.com>
Message-ID: <ldKf5qYv81uLkI-1RwV2chyc-6JO7qbZqMmC9dxD3XA=.15d9bde4-e003-4ea9-96c4-f4981fc01d1e@github.com>

On Fri, 27 Oct 2023 22:22:46 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed fix to align with bug report

The problem with not caching the `ServiceKey`, AFAICS, is that we are going to do `toUpperCase` and `intern` in `ServiceKey` constructor. 

The problem *with* caching the key comes from the contention on a single variable, if we ping-pong different `ServiceKey`-s through that single-slot cache. Dropping `volatile` should not help much, because the first-order effect is contention, not additional synchronization. The easy mitigation would be updating `previousKey` conditionally. For example, when the cache is `null` and have not been initialized.

Single-slot caches are problematic like that. Something like `ConcurrentMap<Pair<String,String>, WeakReference<ServiceKey>>` would mitigate update-side problems with single-slot cache. But it remains to be seen if it is better than accepting `toUpperCase` and `intern`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16403#issuecomment-1784965220

From mullan at openjdk.org  Mon Oct 30 14:17:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 30 Oct 2023 14:17:36 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
Message-ID: <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>

On Fri, 27 Oct 2023 20:17:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change maxCertificateChainLength to be a local variable
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 178:
> 
>> 176:          * the jdk.tls.maxCertificateChainLength property will not override
>> 177:          * the values.
>> 178:          */
> 
> English is not my native language, but I have some comment on the wording. Normally we don't say `maxCertificateChainLength` overrides `maxInboundCertificateChainLength`. In fact, it is `maxInboundCertificateChainLength` that _overrides_ `maxCertificateChainLength`. When `maxInboundCertificateChainLength` is not set, it _fallbacks_ to `maxCertificateChainLength` (if set) or a _default_ value (8).

I agree that wording is more clear. We should also update the RN with that wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1376291645

From duke at openjdk.org  Mon Oct 30 14:57:34 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 30 Oct 2023 14:57:34 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
 [v2]
In-Reply-To: <rWs8ZoxaYfF-ic7_DXmVpnbX7XMPCtYskTOZiuZebh0=.c990a69c-ca57-49f7-a531-c3ec890797e1@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
 <rWs8ZoxaYfF-ic7_DXmVpnbX7XMPCtYskTOZiuZebh0=.c990a69c-ca57-49f7-a531-c3ec890797e1@github.com>
Message-ID: <xLFQUVftOE2VO5Oalrkp4YQaPGHYqoe7GWSDhk500EE=.201fa071-292a-4425-8ae9-43a71e13d3a4@github.com>

On Fri, 27 Oct 2023 22:22:46 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed fix to align with bug report

I think the best way to fix this would be what is suggested in the bug: add a new property threadId to the ServiceKey class, save the thread id (currentThread.getId())  in it in the constructor and add checking it (along with the key.matches() check) in the getService() method.

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

PR Comment: https://git.openjdk.org/jdk/pull/16403#issuecomment-1785395463

From duke at openjdk.org  Mon Oct 30 18:24:48 2023
From: duke at openjdk.org (Ben Perez)
Date: Mon, 30 Oct 2023 18:24:48 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period [v2]
In-Reply-To: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
Message-ID: <ScBZk-ZNBDBdxmyDCsflud9p6_FzTr6JOgYH4OvsLFw=.d02ce318-7541-4c81-bfe3-713b6398e0d5@github.com>

> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  Updated documentation, minor fixes in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16295/files
  - new: https://git.openjdk.org/jdk/pull/16295/files/cffa7b99..6db8c331

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

  Stats: 27 lines in 2 files changed: 1 ins; 18 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16295.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16295/head:pull/16295

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

From mdonovan at openjdk.org  Mon Oct 30 20:03:00 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 30 Oct 2023 20:03:00 GMT
Subject: RFR: 8319136: Skip pkcs11 tests on linux-aarch64
Message-ID: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>

Due to test failures on OL 7.9 aarch64, this PR skips tests for LInux aarch64. The MultipleLogin.sh script had to be added to the ProblemList because it reported error when the Java component threw the skipped exception.

Tests will be fixed in JDK-8319128.

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

Commit messages:
 - 8319136: Skip pkcs11 tests on linux-aarch64

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

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

From kdriver at openjdk.org  Mon Oct 30 20:59:52 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 30 Oct 2023 20:59:52 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v8]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <o8aepjQXwG6OckSmSYXBv4ckSutUvEe-nmwwMYyIeH4=.5a74f536-678c-4a5d-8159-2770ea952a83@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  revert files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/206e5b9c..d309acdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=06-07

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

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

From hchao at openjdk.org  Mon Oct 30 22:01:01 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 30 Oct 2023 22:01:01 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v9]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <3XgzIfRjrKWFu700l92OcOHHzQs6MeT6Ug_p87g2L_c=.e1e11aae-7e22-4e2d-b5cc-baf16d8aae43@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update comments and property process code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/d9f669f0..31668bee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=07-08

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

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

From hchao at openjdk.org  Mon Oct 30 22:01:02 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 30 Oct 2023 22:01:02 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
 <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
Message-ID: <V6MKLSeRqDcXAK69SwhLo1X-4slT_LVqPAsz7Pgg9Ks=.6d6993fe-110d-4447-9157-fc74915c2fe3@github.com>

On Fri, 27 Oct 2023 20:08:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change property names to clearly indicate client side and server side
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 154:
> 
>> 152:             globalPropSet = true;
>> 153:         }
>> 154:         maxCertificateChainLength = certLen;
> 
> There is no need to set `certLen` or `maxCertificateChainLength` when `globalPropSet` is false.

Removed them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1376841208

From hchao at openjdk.org  Mon Oct 30 22:01:03 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 30 Oct 2023 22:01:03 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v7]
In-Reply-To: <b90orJf4inXXSEhNc6avgEOKjC9i59LlFtvjLU2Z_z4=.8b0bac1c-a188-4711-9cf9-fe2fa9f70e45@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <U-5Sm74ceYy8bxbGOxkUSrim0W9cq4h7RH9Zx9BsBr8=.66deef23-f9d1-434f-a450-4a72c91d2cc2@github.com>
 <itccKC8CdCbNhjlNY4sj6L0SeV37NhjJUtwCRiuthqs=.3d0d54ac-3e07-42a8-bddb-818593270361@github.com>
 <aAbaVWeFCf47JW9egN3gRcS0drsgt-9cJpSIeJBFbY8=.f4279c99-9321-4599-b299-429ba129d5b2@github.com>
 <ZpaqAGux1R1OM3k4YQUKqcv_H0UZsLT4OmokDM9rQPQ=.41856cd4-8f7d-4a2b-8bda-756149809d77@github.com>
 <b90orJf4inXXSEhNc6avgEOKjC9i59LlFtvjLU2Z_z4=.8b0bac1c-a188-4711-9cf9-fe2fa9f70e45@github.com>
Message-ID: <O77XhDZyhnYx4OYRfR_zfGC3YB8Ra1dYtVwlaWNby70=.951bbc73-0b56-4b4b-b9a1-e401b808fbc5@github.com>

On Fri, 27 Oct 2023 20:22:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This belongs to the `if (inboundClientLen == null || inboundClientLen < 0)` side. The else side stays the same.
>
> Precisely, it's
> 
>         if (inboundServerLen == null || inboundServerLen < 0) {
>             maxInboundClientCertChainLen = globalPropSet ? maxCertificateChainLength : 8;;
>         } else {
>             maxInboundClientCertChainLen = inboundServerLen;
>         }
> 
> and nothing else is needed.

Updated as suggested. Changed code to:

        if (inboundServerLen == null || inboundServerLen < 0) {
            maxInboundServerCertChainLen = globalPropSet ? maxCertificateChainLength : 10;
        } else {
            maxInboundServerCertChainLen = inboundServerLen;
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1376841191

From hchao at openjdk.org  Mon Oct 30 22:01:04 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 30 Oct 2023 22:01:04 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
Message-ID: <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>

On Mon, 30 Oct 2023 14:14:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 178:
>> 
>>> 176:          * the jdk.tls.maxCertificateChainLength property will not override
>>> 177:          * the values.
>>> 178:          */
>> 
>> English is not my native language, but I have some comment on the wording. Normally we don't say `maxCertificateChainLength` overrides `maxInboundCertificateChainLength`. In fact, it is `maxInboundCertificateChainLength` that _overrides_ `maxCertificateChainLength`. When `maxInboundCertificateChainLength` is not set, it _fallbacks_ to `maxCertificateChainLength` (if set) or a _default_ value (8).
>
> I agree that wording is more clear. We should also update the RN with that wording.

This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!

        /*
         * If either jdk.tls.server.maxInboundCertificateChainLength or
         * jdk.tls.client.maxInboundCertificateChainLength is set, it will
         * override jdk.tls.maxCertificateChainLength, regardless of whether
         * jdk.tls.maxCertificateChainLength is set or not.
         * If neither jdk.tls.server.maxInboundCertificateChainLength nor
         * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior
         * depends on the setting of jdk.tls.maxCertificateChainLength. If
         * jdk.tls.maxCertificateChainLength is set, it falls back to that
         * value; otherwise, it defaults to 8 for
         * jdk.tls.server.maxInboundCertificateChainLength
         * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
         * Usesrs can independently set either
         * jdk.tls.server.maxInboundCertificateChainLength or
         * jdk.tls.client.maxInboundCertificateChainLength.
         */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1376841239

From hchao at openjdk.org  Mon Oct 30 22:08:44 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 30 Oct 2023 22:08:44 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v10]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updated to not longer than 80-chars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/31668bee..b3192df3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=08-09

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

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

From weijun at openjdk.org  Mon Oct 30 23:42:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 30 Oct 2023 23:42:34 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v10]
In-Reply-To: <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>
Message-ID: <47XNFb-6qLF6YOHYdcoLjvWCdFwBd0faj7gwdObmpXY=.3f458c48-f627-49c2-b71e-9515954f33da@github.com>

On Mon, 30 Oct 2023 22:08:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to not longer than 80-chars

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15163#pullrequestreview-1705232636

From andrew at openjdk.org  Tue Oct 31 02:09:42 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 31 Oct 2023 02:09:42 GMT
Subject: Integrated: 8009550: PlatformPCSC should load versioned so
In-Reply-To: <RTKWEF6u5gjRIn77MGeEO6ZE56DyD1J8bChHNej48IU=.b8c6d676-340e-4555-a4c2-2d04d5b97590@github.com>
References: <RTKWEF6u5gjRIn77MGeEO6ZE56DyD1J8bChHNej48IU=.b8c6d676-340e-4555-a4c2-2d04d5b97590@github.com>
Message-ID: <z2ThCcuBEqFsLzy-OqNHWieQk6zGoh_nxI_U5OMgLLc=.15854e62-8388-45e8-ba3c-46fa6541d878@github.com>

On Thu, 24 Aug 2023 00:53:03 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library.
> 
> On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843)
> 
> On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`.  So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so`
> 
> This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with.  All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems.
> 
> A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream.
> 
> Testing:
> 
> Test case:
> ~~~
> import java.lang.reflect.Method;
> 
> public class TestPlatformPCSC {
>     public static void main(String[] args)
>     throws Exception {
>         Class<?> cls = Class.forName("sun.security.smartcardio.PlatformPCSC");
>         Method m = cls.getDeclaredMethod("getLibraryName");
>         m.setAccessible(true);
>         System.err.println(m.invoke(null));
>     }
> }
> ~~~
> 
> 1. With `libpcsclite.so.1` available:
> ~~~
> $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.d...

This pull request has now been integrated.

Changeset: 328b3810
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/328b381075ab81fd3f899e49e4d71ef19ea28862
Stats:     54 lines in 2 files changed: 30 ins; 4 del; 20 mod

8009550: PlatformPCSC should load versioned so

Reviewed-by: valeriep, stuefe

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

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

From andrew at openjdk.org  Tue Oct 31 02:09:41 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 31 Oct 2023 02:09:41 GMT
Subject: RFR: 8009550: PlatformPCSC should load versioned so [v2]
In-Reply-To: <809XWPj9BRMFRwTOLV6G6hXeFaZVp9KWYNr8FiWx9o4=.61c031f7-04f7-4a45-9f8b-5501bb682e26@github.com>
References: <RTKWEF6u5gjRIn77MGeEO6ZE56DyD1J8bChHNej48IU=.b8c6d676-340e-4555-a4c2-2d04d5b97590@github.com>
 <809XWPj9BRMFRwTOLV6G6hXeFaZVp9KWYNr8FiWx9o4=.61c031f7-04f7-4a45-9f8b-5501bb682e26@github.com>
Message-ID: <2xqjy9Xa-R1zuxmfnp0Npl6VMqhcg0nZdwmtwe_4G9c=.89d4f5b3-fddc-43d9-a95d-e67686e6be69@github.com>

On Tue, 5 Sep 2023 10:17:31 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library.
>> 
>> On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843)
>> 
>> On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`.  So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so`
>> 
>> This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with.  All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems.
>> 
>> A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream.
>> 
>> Testing:
>> 
>> Test case:
>> ~~~
>> import java.lang.reflect.Method;
>> 
>> public class TestPlatformPCSC {
>>     public static void main(String[] args)
>>     throws Exception {
>>         Class<?> cls = Class.forName("sun.security.smartcardio.PlatformPCSC");
>>         Method m = cls.getDeclaredMethod("getLibraryName");
>>         m.setAccessible(true);
>>         System.err.println(m.invoke(null));
>>     }
>> }
>> ~~~
>> 
>> 1. With `libpcsclite.so.1` available:
>> ~~~
>> $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartc...
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop outdated kfreebsd case and document arch template and arm

No problem. I know you were away for a while.

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

PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1786320964

From rhalade at openjdk.org  Tue Oct 31 04:30:30 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 31 Oct 2023 04:30:30 GMT
Subject: RFR: 8319136: Skip pkcs11 tests on linux-aarch64
In-Reply-To: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>
References: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>
Message-ID: <D0imnsNgaqtFNpVBpEOcqRWuolA9KgrFbNCPp5JcQjI=.0b5b49b0-36ac-48ce-b2d5-14343e8bf86b@github.com>

On Mon, 30 Oct 2023 19:57:02 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> Due to test failures on OL 7.9 aarch64, this PR skips tests for LInux aarch64. The MultipleLogin.sh script had to be added to the ProblemList because it reported error when the Java component threw the skipped exception.
> 
> Tests will be fixed in JDK-8319128.

Marked as reviewed by rhalade (Reviewer).

test/jdk/sun/security/pkcs11/PKCS11Test.java line 828:

> 826: 
> 827:             case "Linux-aarch64-64":
> 828:                 throw new SkippedException("Skipping Linux aarch64 platforms.");

please add JDK-8319128 either in exception message or as a comment here. My preference would be to add it to the exception message since this is temporary.

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

PR Review: https://git.openjdk.org/jdk/pull/16427#pullrequestreview-1705426282
PR Review Comment: https://git.openjdk.org/jdk/pull/16427#discussion_r1377040133

From mdonovan at openjdk.org  Tue Oct 31 11:10:54 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 31 Oct 2023 11:10:54 GMT
Subject: RFR: 8319136: Skip pkcs11 tests on linux-aarch64 [v2]
In-Reply-To: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>
References: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>
Message-ID: <FGiiPnCVVZnnzNe1mdJvju_uv1KArZ29jhsjzAuQciA=.5cf5bc62-bd4c-443e-9204-45b18cc31617@github.com>

> Due to test failures on OL 7.9 aarch64, this PR skips tests for LInux aarch64. The MultipleLogin.sh script had to be added to the ProblemList because it reported error when the Java component threw the skipped exception.
> 
> Tests will be fixed in JDK-8319128.

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

  added JDK-8319128 to SkippedException message.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16427/files
  - new: https://git.openjdk.org/jdk/pull/16427/files/486d1010..828d3d3a

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

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

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

From mullan at openjdk.org  Tue Oct 31 13:31:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 31 Oct 2023 13:31:44 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v9]
In-Reply-To: <3XgzIfRjrKWFu700l92OcOHHzQs6MeT6Ug_p87g2L_c=.e1e11aae-7e22-4e2d-b5cc-baf16d8aae43@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <3XgzIfRjrKWFu700l92OcOHHzQs6MeT6Ug_p87g2L_c=.e1e11aae-7e22-4e2d-b5cc-baf16d8aae43@github.com>
Message-ID: <bM3VXPJezA382igIJGHTJ5qWzGjn19yrS0tAszx4p9Y=.a3054a3f-6f0c-49c0-88b0-1df0ea96b9a3@github.com>

On Mon, 30 Oct 2023 22:01:01 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments and property process code

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 160:

> 158:          * jdk.tls.server.maxInboundCertificateChainLength
> 159:          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
> 160:          * Usesrs can independently set either

Typo: s/Usesrs/Users

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1377584926

From mullan at openjdk.org  Tue Oct 31 13:31:41 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 31 Oct 2023 13:31:41 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v10]
In-Reply-To: <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>
Message-ID: <YAgZbQue8LMQOdbCSJVz7n6o_k0JiFArXm1IGBxSYbI=.96c32ce0-96ca-40ea-8516-24d6643ac950@github.com>

On Mon, 30 Oct 2023 22:08:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to not longer than 80-chars

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15163#pullrequestreview-1706301215

From mdonovan at openjdk.org  Tue Oct 31 13:31:41 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 31 Oct 2023 13:31:41 GMT
Subject: Integrated: 8319136: Skip pkcs11 tests on linux-aarch64
In-Reply-To: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>
References: <8i5G_K3_5-UgHHAUDhK7Z5yLFQs9IfGNP007xu2z32Q=.44559ad7-2e07-41eb-ac10-e3e3525659c3@github.com>
Message-ID: <kEMuZgc6FUhuXPM_hMRn-HidHFLHzc8Lm0xGv82r0CE=.201daf2e-44ba-468c-909d-4ee369efd3d7@github.com>

On Mon, 30 Oct 2023 19:57:02 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> Due to test failures on OL 7.9 aarch64, this PR skips tests for LInux aarch64. The MultipleLogin.sh script had to be added to the ProblemList because it reported error when the Java component threw the skipped exception.
> 
> Tests will be fixed in JDK-8319128.

This pull request has now been integrated.

Changeset: 3e39d7b3
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e39d7b34cb310343a34adddc06bf1aaf4cacfb1
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8319136: Skip pkcs11 tests on linux-aarch64

Reviewed-by: rhalade

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

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

From mullan at openjdk.org  Tue Oct 31 14:15:41 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 31 Oct 2023 14:15:41 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period [v2]
In-Reply-To: <ios38bULFk6LchsKPXpZWhRxo7AoPyZkYOsHMeh4wh8=.72319ecd-e65d-4596-9def-cc3acf296af7@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
 <ios38bULFk6LchsKPXpZWhRxo7AoPyZkYOsHMeh4wh8=.72319ecd-e65d-4596-9def-cc3acf296af7@github.com>
Message-ID: <IZxU5TogAJFS5mbblZVDO2G18zTxzkZhsWNk7Vu-yKE=.2e7c78ed-7aff-4428-a395-cddc1dcb6a0d@github.com>

On Fri, 27 Oct 2023 15:07:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated documentation, minor fixes in test
>
> test/jdk/sun/security/x509/DNSName/LeadingPeriod.java line 82:
> 
>> 80:         // disable CRL checker
>> 81:         System.setProperty("com.sun.security.enableCRLDP", "false");
>> 82: 
> 
> You should not need to set this property if revocation is disabled.

You may have missed this comment, you can also remove lines 77-78.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16295#discussion_r1377647382

From hchao at openjdk.org  Tue Oct 31 15:18:58 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 31 Oct 2023 15:18:58 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v11]
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <gXbUpiL10QDS03uwYLJh7wDeWm7MOWSIy06fJ18pW0Y=.fcdabe9b-5653-4504-90b6-601839ad12aa@github.com>

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  typo fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15163/files
  - new: https://git.openjdk.org/jdk/pull/15163/files/b3192df3..83b489b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=09-10

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

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

From hchao at openjdk.org  Tue Oct 31 15:19:00 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 31 Oct 2023 15:19:00 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v10]
In-Reply-To: <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <caVXl26K11UXpPW-gAlUVz40U1ipQUqmoyi8RTv-2-4=.9ffdc219-007d-4a84-8d39-f8da6d28f1d5@github.com>
Message-ID: <6UtFH_FqpcQVfVLOiIe7BFtcqbnNufcxzaN1ARm4oUk=.ef4026b9-1d01-450f-a1d8-b2439b92b0bd@github.com>

On Mon, 30 Oct 2023 22:08:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to not longer than 80-chars

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15163#issuecomment-1787425211

From hchao at openjdk.org  Tue Oct 31 15:19:02 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 31 Oct 2023 15:19:02 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v9]
In-Reply-To: <bM3VXPJezA382igIJGHTJ5qWzGjn19yrS0tAszx4p9Y=.a3054a3f-6f0c-49c0-88b0-1df0ea96b9a3@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <3XgzIfRjrKWFu700l92OcOHHzQs6MeT6Ug_p87g2L_c=.e1e11aae-7e22-4e2d-b5cc-baf16d8aae43@github.com>
 <bM3VXPJezA382igIJGHTJ5qWzGjn19yrS0tAszx4p9Y=.a3054a3f-6f0c-49c0-88b0-1df0ea96b9a3@github.com>
Message-ID: <M1QqfU1NkigRYTKHz1Cytfa7Za3VOcZ3KF70VkcyPLs=.3e9e8198-4c81-4196-b12b-39f7769e9c5d@github.com>

On Tue, 31 Oct 2023 13:26:47 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments and property process code
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 160:
> 
>> 158:          * jdk.tls.server.maxInboundCertificateChainLength
>> 159:          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
>> 160:          * Usesrs can independently set either
> 
> Typo: s/Usesrs/Users

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1377756932

From hchao at openjdk.org  Tue Oct 31 15:25:45 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 31 Oct 2023 15:25:45 GMT
Subject: Integrated: 8311596: Add separate system properties for TLS server and
 client for maximum chain length
In-Reply-To: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
Message-ID: <KBdaf-gHfbY0aeiyfR8Tg5JpxnGnEPCIpWCAKGShFOE=.4364b05a-8704-4833-b1c2-876b3fbb3eef@github.com>

On Fri, 4 Aug 2023 17:30:06 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

This pull request has now been integrated.

Changeset: 0064cf90
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0064cf90ff7d575f3500a05e234dd795b15240b2
Stats:     68 lines in 2 files changed: 59 ins; 0 del; 9 mod

8311596: Add separate system properties for TLS server and client for maximum chain length

Reviewed-by: jnimeh, weijun, mullan

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

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

From mbalao at redhat.com  Tue Oct 31 17:25:27 2023
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 31 Oct 2023 13:25:27 -0400
Subject: [External] : Re: RFD: Services lockdown for security providers
In-Reply-To: <d8a80c8c-70ad-4284-88a5-8d8d6f8a97da@oracle.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
 <4b159d35-ee2e-952d-8e22-c035e5ed17ea@oracle.com>
 <1a0ad927-2da8-c881-a80f-b4928341375f@redhat.com>
 <d7a607e0-7acc-1929-7464-a70ceb6d7c91@oracle.com>
 <7c07a7b1-6c68-9534-59e1-1813439d7f47@redhat.com>
 <85e89abd-eac3-87df-9e4b-1fa2c36a6286@oracle.com>
 <CAKZz+geGA3Hs4jV8AFTKPrehiquXWbiA9BvPVFPSaWzLVsn6Rw@mail.gmail.com>
 <dc1c22ab-b130-364f-d7d2-880d899a5184@oracle.com>
 <9c212429-6045-5b0a-c6b0-6370488039b1@redhat.com>
 <d8a80c8c-70ad-4284-88a5-8d8d6f8a97da@oracle.com>
Message-ID: <e5372bab-6667-40dc-874d-995dd6bb3ece@redhat.com>

Hi Tony,

Thanks for pointing this out. Your observation is right.

We looked at this problem from a different angle, when defining internal 
consistency of a filter value as out of scope [1]. Our concern was that 
a filter value may render services unusable because of dependencies 
(e.g. Signature.SHA1withECDSA depends on MessageDigest.SHA-1, and 
filtering out the latter would render the former unusable). Your point 
of view is also valid: there could be a difference in behavior when 
comparing the effects of a filter value on services of the same type and 
algorithm but implemented by different security providers.

Tracking dependencies between services or providers transparently 
?without an explicit declaration or API? is a hard problem in our view. 
Even without the Security Providers Filter, a security provider may 
depend on others to work, and 3rd party providers are not necessarily an 
exception. For example, SunEC depends on a provider implementing 
MessageDigest.SHA-1, such as SUN, for SHA1withECDSA to work. These 
dependencies are not always explicit by JCA API calls: a service may use 
other services directly linking their classes. OpenJDK is agnostic when 
it comes to configuration consistency and requires users to make an 
informed decision when installing security providers.

The Security Providers Filter is not different in this regard. The 
Signature.SHA1withECDSA service may use a MessageDigest.SHA-1 
underneath, or Cipher.AES an AlgorithmParameters.AES one, but we don't 
know upfront as it depends on each implementation. Other relationships 
such as KeyStore.PKCS12 depending on Mac.PBE and Cipher.PBE services are 
more complex and less obvious. Even beyond security providers, the 
application itself may be unusable for a filter value. It's difficult to 
reason or make assumptions about the interaction between services of 
different types, or between services and the application itself, and 
this is why we proposed to leave filter consistency on the user side.

 From the four allow and block combinations of Signature.SHA1withECDSA 
and MessageDigest.SHA-1, we see three as clearly motivated: allow both, 
block both and allow SHA-1 for MessageDigest but not for Signature. The 
combination of blocking SHA-1 for MessageDigest but allowing it for 
Signature does not seem to reflect a real case. In general, our 
impression is that combinations in which a building block is blocked but 
a related higher-level service is allowed do not reflect real cases.

With that said, we also considered temporarily bypassing the filter 
inside each service implementation. In this scenario, allowing 
Signature.SHA1withECDSA in the filter would be enough for the service to 
work, irrespective of MessageDigest.SHA-1 being blocked. We can think of 
this as a specific instance of filtering by use or caller, as Sean 
suggested some time ago [2]. From a technical point of view, this idea 
might be feasible but we have more general concerns that are worth 
discussing.

One relatively efficient way to implement this bypassing concept is to 
have a thread-local value or a ThreadTracker instance that is set while 
executing inside a service instance method or constructor. This value 
would be checked at the time of getting a service and, if set, the 
service is allowed without any filter check. For example, a 
Signature.getInstance() call would return a Signature instance such 
that, for each of its instance methods and SPI constructor, the 
thread-local value or the ThreadTracker is set and temporarily 
guarantees access to all MessageDigest services. Thus, you have a 
working Signature.SHA1withECDSA service even if MessageDigest.SHA-1 is 
blocked. Other (more sophisticated) approaches such as performing stack 
walks would imply a higher performance penalty.

However, we are concerned about the consistency and security 
implications of this concept:

1) What does it mean for a KeyStore or an SSLContext service to ignore 
the filter internally? This could be a complete bypass of the filter in 
practical terms. On the other hand, if we treat some service types 
differently in terms of bypassing the filter, how confusing would it be 
for the user? For example, Signature services use the filter bypass 
concept but KeyStores or 3rd party service types do not.

2) How do we enforce filters across all JCA APIs and what guarantees do 
we have? There will be open doors in each security provider to use 
algorithms, service types or even security providers that should not be 
used. For example, in a FIPS scenario we prefer a failure rather than a 
non-FIPS crypto. In a CRIU-snapshot scenario we prefer a failure rather 
than the use of a SecureRandom.

3) What are the run time costs that we add? Not a Security Manager stack 
walk but still some overhead.

4) What would happen if a security provider ?possibly from a 3rd party? 
implements services in a parallel way? The thread-local mechanisms might 
not be enough for these cases.

We are open to having this discussion but, based on the elements 
previously described, we lean more towards keeping the filter plain and 
simple. Adding a bypassing mechanism or checking internal consistency 
only addresses a portion of the problem at the cost of an increased 
complexity.

Regards,
Martin.-

--
[1] - 
https://mail.openjdk.org/pipermail/security-dev/2023-February/034554.html
[2] - https://mail.openjdk.org/pipermail/security-dev/2023-July/036540.html


On 10/26/23 01:33, Anthony Scarpino wrote:
> Hi Martin,
> 
> Thanks for the additional motivation.
> 
> While thinking about this PR, I found that the filter can be 
> inconsistently applied between JDK and 3rd party providers.? The java 
> providers use the JCA to build combined algorithms. For example, the 
> ECDSAwithSHA1 that comes from SunEC uses getInstance() for 
> MessageDigest.SHA-1.? HmacSHA1 and PBEWithHmacSHA1AndAES_128 do the same.
> 
> If a filter only contains "*.MessageDigest.SHA-1", it will disable all 
> the combined algorithms for JDK providers that use SHA1.? For 3rd party 
> providers, these algorithms would likely be enabled.? A PKCS11 provider 
> that supports ECDSAwithSHA1 would use its internal SHA1 that the filter 
> would not effect.
> 
> I think the filters should be consistently applied to all providers. JDK 
> providers and any 3rd party providers that uses this pluggable design, 
> should not be more restricted.? This inconsistency could lead to an 
> incorrect configuration.? Have you noticed this in your testing?? Can 
> you think of a way to avoid the inconsistency without changing all these 
> combined getInstance() calls?
> 
> thanks
> 
> Tony
> 
> 
> On 10/6/23 9:55 AM, Martin Balao wrote:
>> Hi Tony,
>>
>> Thanks for having a look at our proposal.
>>
>> The main motivation for this enhancement is related to cryptographic 
>> policy enforcement and, in particular, the following capabilities: 1) 
>> enforcing that cryptographic services are provided by chosen security 
>> providers only, and 2) allowing or disallowing selected algorithms or 
>> service types across all Java Security APIs.
>>
>> None of this is entirely new. In regards to capability #1, users can 
>> install or uninstall security providers already, or rely on priorities 
>> and algorithms shadowing. However, we deem this insufficient for the 
>> purposes of policy enforcement, lacking in flexibility, and at risk of 
>> introducing dependencies on implementation details. Some more details 
>> are provided under the section "What is the current limitation?" of 
>> the 8315487 ticket [1]. As for capability #2, there is partial support 
>> currently: algorithms can be blocked from TLS or certificate paths 
>> validation uses but not across all JCA APIs. Thus, we share some of 
>> the motivations that led to existing features but intend to have a 
>> more powerful, comprehensive and flexible solution. As documented in 
>> our proposal, both solutions were combined in a multi-layer model.
>>
>> The FIPS case is interesting because it requires a combination of 
>> capabilities #1 and #2. However, there are other cases that could 
>> benefit from different policies. I have described some of them below, 
>> providing a summary rationale for why a user might want to adopt the 
>> given policy, a filter conforming to the proposal that would achieve 
>> the desired outcome, and a comparison with how the same outcome might 
>> be met (or potentially be hard/impossible to meet) with the status 
>> quo. See Appendix #1.
>>
>> As with most security properties, a specific configuration may render 
>> an application completely or partially unusable, and require a 
>> sysadmin/developer/security-expert to perform an assessment. This 
>> effect may be a desired outcome and trigger a remediation action. 
>> Other applications may react in a more resilient way and smoothly 
>> adapt to the policy enforced: use cryptography from an allowed 
>> security provider, skip the use of algorithms that are not allowed, 
>> ask the user to take action, etc. Our concern is that the lack of 
>> strong policy enforcement capabilities may lead to non-compliance 
>> issues going unnoticed.
>>
>> Existing security capabilities such as the one to install or uninstall 
>> security providers, or even the one that allows to select preference 
>> per algorithm, require the knowledge of what these security providers 
>> implement and what applications require to use. Our proposal allows 
>> better granularity but is not different in terms of relying on public 
>> documentation or sysadmin/developer/security-expert knowledge.
>>
>> While we don't necessarily share the view of the syntax as hard to use 
>> or error-prone, we concede that it leans more towards the expert UI 
>> side of all security properties. We designed the syntax with the ideas 
>> of consistency, similarity to the serialization filter ?to the extent 
>> possible?, simplicity for trivial cases and powerfulness for complex 
>> ones. We want to make sure that it's not only tailored to our needs 
>> today but generic enough for other current or future uses. We tried to 
>> explain the use cases and desirable properties underneath the proposed 
>> design, but at the same time we would like to know if there is any 
>> aspect in particular that is of your concern and if you have any 
>> improvements to suggest so it's more accessible to less experienced 
>> users. We are open to considering specification, implementation and/or 
>> documentation changes.
>>
>> Thanks,
>> Martin.-
>>
>> -- 
>>
>> Appendix #1
>>
>> 1) A policy that only authorizes the storage of certificates and keys 
>> in PKCS #11 devices, or in a specific instance managed by the 
>> CentralKeysProvider security provider:
>>
>> *.KeyStore.PKCS11; !*.KeyStore; *
>>
>> or
>>
>> CentralKeysProvider.KeyStore; !*.KeyStore; *
>>
>> In this scenario, a system administrator is concerned about how 
>> applications store sensitive cryptographic keys and intends to enforce 
>> a centralized or more restricted management. This policy aims to 
>> mitigate security risks and drawbacks associated with local file-based 
>> key storage. In the event of a key update, if centralized management 
>> is applied, applications have access to the latest key without any key 
>> population hassle. While this policy imposes restrictions on key 
>> storage, any security provider (including OpenJDK default ones) can 
>> use these keys after retrieval. This latter observation is relevant 
>> when, for example, PKCS #11 token devices with limited performance or 
>> algorithms availability are used.
>>
>> We deem this type of policy useful for scenarios where centralized key 
>> management is feasible and desirable, or scenarios where keys are 
>> stored in hardware devices.
>>
>> Enforcing this policy without the Security Provider Filter would be 
>> hard. While changing the default key store type by means of the 
>> keystore.type security property is possible, that configuration does 
>> not make other key store types unavailable. In addition, this security 
>> property lets users choose a key store algorithm but not its provider. 
>> Uninstalling security providers that offer unwanted KeyStore service 
>> types is not always an option because other service types they offer 
>> might be legitimately required. In other words, this option lacks 
>> granularity. The only way to enforce a policy such as the one 
>> described in this case is to audit the application and library 
>> sources, configurations or logs and check how keys are managed. This 
>> approach would require manual actions and rechecks after each 
>> application or library change.
>>
>> The Security Provider Filter makes the enforcement of this policy 
>> easy, even under the circumstances of an application or library 
>> update, or after the deployment of a new application. The policy can 
>> also be updated to include other key store algorithms, security 
>> providers or combinations of both.
>>
>> 2) A policy that enforces the use of PKCS #12 key stores only:
>>
>> *.KeyStore.PKCS12; !*.KeyStore; *
>>
>> In this scenario, a system administrator is concerned about 
>> applications using key stores with non-standard formats such as JKS, 
>> JCEKS, BKS (Bouncy Castle) or BCFKS (Bouncy Castle) among others. 
>> These key store algorithms may introduce interoperability issues and 
>> require unwanted file conversions at some point. Thus, the system 
>> administrator enforces a policy that only authorizes the PKCS #12 
>> standard for key storage.
>>
>> As in case #1, the security property for controlling the default key 
>> store type is not enough to prevent applications from using other 
>> formats; uninstalling security providers is not always an option; and 
>> auditing application or libraries source code, configurations or logs 
>> to check how key storage is done could be inconvenient or unfeasible.
>>
>> The Security Provider Filter provides flexibility to change the 
>> approved key store type or authorize more than one. Third-party 
>> security providers may refer to the PKCS #12 standard by different 
>> algorithm names but that should not be a problem either. For example, 
>> the filter may authorize algorithm name variations such as PKCS12, 
>> BCPKCS12 (Bouncy Castle) and PKCS12-3DES-3DES (Bouncy Castle): 
>> "*.KeyStore.PKCS12; *.KeyStore.BCPKCS12; *.KeyStore.PKCS12-3DES-3DES; 
>> ...", or more simply "*.KeyStore.*PKCS12*; ...".
>>
>> 3) A policy that does not allow algorithms considered insecure:
>>
>> !*.*.MD5; !*.*.MD2; !*.*.SHA-1; *
>>
>> Security concerns are the motivation behind this type of policy. A 
>> system administrator may enforce it with a deny-list ?as done in the 
>> example? or even with a more strict allow-list one. This type of 
>> policy can be applied with algorithms considered secure today or 
>> algorithms that will be required in the future. The latter serves for 
>> the purpose of identifying potential compatibility issues and 
>> providing applications advanced notice to adapt.
>>
>> While the Security Provider Filter is platform-independent, Linux 
>> crypto-policies is one of the motivations related to this case. Many 
>> Linux distributions, such as RHEL [2], have system-wide 
>> crypto-policies enabled by default. Different crypto-policies profiles 
>> (LEGACY, DEFAULT, FIPS, FUTURE, etc.) define sets of algorithms 
>> authorized for different software packages, including OpenJDK. Our 
>> intention is that crypto-policies for OpenJDK define, according to 
>> each profile, the set of algorithms allowed for all security APIs.
>>
>> Before the Security Provider Filter, algorithms can be restricted for 
>> some uses with a deny-list type of configuration. However, not all 
>> uses are under scope and applications may use unauthorized algorithms 
>> by calling, for example, 
>> Signature.getInstance("<unauthorized-algorithm>") and using the 
>> service directly. Other approaches such as auditing application and 
>> libraries source code, configurations or logs to check which 
>> algorithms are used may not be practical, as pointed out in case #1.
>>
>> The Security Provider Filter allows a system administrator to keep 
>> sets of authorized algorithms updated and apply its policy widely to 
>> all JCA service types.
>>
>> 4) A policy in which some uses of MD5 are acceptable (e.g. 
>> MessageDigest) but others are not:
>>
>> !*.Signature.MD5*; !*.Mac.*MD5; !*.Cipher.*MD5*; *
>>
>> or
>>
>> *.MessageDigest.MD5; !*.*.*MD5*; *
>>
>> Some algorithms may be secure for some uses but not for others. In 
>> this case, a system administrator authorizes MD5 for UUIDs, 
>> redundancy-check codes or other hashes, but prohibits its use for 
>> signatures, message authentication, and for deriving encryption keys 
>> (PBE).
>>
>> This type of policy enforcement is possible because the Security 
>> Provider Filter lets users specify the service type, in addition to 
>> the algorithm. A system administrator can easily adjust the algorithms 
>> and service types that are allowed or disallowed.
>>
>> For the same reasons explained in case #3, implementing this policy 
>> without the Security Provider Filter would not be possible or practical.
>>
>> 5) A policy in which only algorithms implemented by the FastProvider 
>> security provider are authorized for encryption:
>>
>> FastProvider.Cipher; !*.Cipher; *
>>
>> In this case, a system administrator is concerned about performance 
>> and wants applications to only do cipher operations in FastProvider.
>>
>> While it is possible to insert FastProvider in the first place of the 
>> security providers list, or even use the preferred algorithms security 
>> property, an application that is using an algorithm not available in 
>> FastProvider will silently slide to a slower implementation. As 
>> described for other cases, removing slower security providers may not 
>> be an option, and auditing applications or libraries source code, 
>> configurations or logs may not be practical.
>>
>> 6) A policy that only allows a specific source of randomness, 
>> irrespective of the algorithm:
>>
>> SunPKCS11-HSM.SecureRandom; !*.SecureRandom; *
>>
>> A system administrator has security concerns about sources of 
>> randomness and decides to authorize only one of them, irrespective of 
>> the algorithm. In this case, the prioritized list of security 
>> providers is not enough to use SunPKCS11-HSM because applications may 
>> try to use algorithms not implemented there and silently slide into 
>> other security providers.
>>
>> Enforcing this type of policy without the Security Provider Filter may 
>> require actions such as uninstalling security providers or auditing 
>> source code, configurations or logs that is not always possible or 
>> practical.
>>
>> 7) In CRIU scenarios, it could be beneficial to enforce a policy that 
>> does not allow the use of random values or key generation before a 
>> snapshot is taken. A snapshot can be taken, for example, running the 
>> JDK with the following filter value:
>>
>> !*.SecureRandom; !*.KeyPairGenerator; !*.KeyGenerator; *
>>
>> In some cases, a system administrator might want to enforce an even 
>> more strict policy using an allow-list approach:
>>
>> *.MessageDigest.SHA-1; *.CertificateFactory; !*
>>
>> When resuming a snapshot, no filter is set.
>>
>> This example is based on a real case. To achieve the desired effect 
>> without the Security Providers Filter, a system administrator has to 
>> create a custom security provider that only implements authorized 
>> service types and algorithms. This security provider is the only one 
>> installed while taking the snapshot. When resuming snapshots, all 
>> security providers are enabled. This solution is hard to implement and 
>> not easily extensible to other service types and algorithms. With the 
>> Security Providers Filter it is easy to decide what is available while 
>> taking a snapshot, and what is available while resuming it.
>>
>> This type of policy falls into the category of those that may benefit 
>> the security of a deployment. The reuse of random seeds or keys in 
>> different executions of the same snapshot may weaken or compromise the 
>> security of a system.
>>
>> 8) A policy that allows the use of a 3rd party security provider for a 
>> specific purpose but not for anything else:
>>
>> 3rdPartyProvider.AllowedService; !3rdPartyProvider; *
>>
>> In this case, a system administrator has concerns of applications 
>> depending on a specific security provider for more service types or 
>> algorithms than what is authorized (AllowedService).
>>
>> This type of policy is difficult to implement without the Security 
>> Provider Filter because there is no granularity when installing a 
>> security provider: it's an all or nothing decision. Thus, the only way 
>> around to enforce compliance is to check applications or libraries 
>> source code, configurations or logs and understand what they are 
>> depending on.
>>
>> Examples Summary
>>
>> Throughout the previous scenarios, we have discussed security, 
>> interoperability and performance concerns that may be addressed by the 
>> Security Providers Filter. What all these cases have in common is 
>> policy enforcement at provider, service type or algorithm level. We 
>> think that the existing providers or algorithms preference 
>> configurations miss the partial or total closure that the Filter 
>> offers. In addition, the lack of granularity makes the installation of 
>> a security provider an all or nothing decision. Thus, policy 
>> enforcement can only be applied by auditing applications or libraries 
>> source code, configuration or logs. This type of enforcement is not 
>> always possible or practical: a new deployment or update of an 
>> existing one requires a check. The existing functionality to block the 
>> use of algorithms does not extend to all security APIs and it's, thus, 
>> not enough from a policy enforcement and compliance perspective. While 
>> we have showcased fabricated system administration scenarios in some 
>> cases, others are of general interest, can be used more widely or 
>> represent real cases. On a final note, we have intentionally left the 
>> FIPS use-case out of this Appendix as it has been discussed in 
>> previous comments.
>>
>> -- 
>> [1] - https://bugs.openjdk.org/browse/JDK-8315487
>> [2] - 
>> https://urldefense.com/v3/__https://access.redhat.com/articles/3666211__;!!ACWV5N9M2RV99hQ!Po2RuiDeYlR92dfYip2ezt4Rm3LYPgRNL7QyeHqnNxFwSisPcez2ySr3eFLgt2vLeJhwN2qZKwcedWuMlYnq$
>>
>>
>> On 9/19/23 16:42, Anthony Scarpino wrote:
>>> Hi Martin,
>>>
>>> Thanks for the proposal. Your documents mostly describe the solution. 
>>> Can you provide more of the motivations and use-cases for the change? 
>>> Do you see non FIPS-140 applications using this feature?
>>>
>>> The feature does provide a comprehensive filtering system for JCA. 
>>> The syntax, while powerful, seems like it would be somewhat 
>>> error-prone and hard to use. We are also concerned that using the 
>>> filter requires the sysadmin or developer to know about the service 
>>> and algorithm details of every provider and which is required and 
>>> which is not, all of which is not easily determined.
>>>
>>> thanks
>>>
>>> Tony
>>
> 


From mpowers at openjdk.org  Tue Oct 31 18:23:56 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 31 Oct 2023 18:23:56 GMT
Subject: RFR: JDK-8318105 [jmh] the test java.security.HSS failed with 2 active
 threads
Message-ID: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>

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

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

Commit messages:
 - @State(Scope.Thread) preference
 - first iteration

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

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

From duke at openjdk.org  Tue Oct 31 19:47:48 2023
From: duke at openjdk.org (Ben Perez)
Date: Tue, 31 Oct 2023 19:47:48 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period [v3]
In-Reply-To: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
Message-ID: <BjXrdO-vVe3dr_4VKkCKTLDRIEzEaTh7ukL14O6wPpQ=.85eed308-26d7-49f6-b135-ba6d8ee4d8af@github.com>

> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  removed set property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16295/files
  - new: https://git.openjdk.org/jdk/pull/16295/files/6db8c331..7cf1628c

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

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

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

From kdriver at openjdk.org  Tue Oct 31 20:17:59 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 31 Oct 2023 20:17:59 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v9]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <DsKRg_1UYcrq2Pr-58d4fObERyNGAi0137Tfh-oCIRQ=.52c210eb-1a75-46a6-ad9a-ded7d21930c0@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  change getInstance to not require keystore type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/d309acdb..253ee1e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=07-08

  Stats: 74 lines in 19 files changed: 4 ins; 34 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/16159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16159/head:pull/16159

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

From kdriver at openjdk.org  Tue Oct 31 20:26:50 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 31 Oct 2023 20:26:50 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v10]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <NSAg9RLa5Gmhdh-quk5G-z5N6R0eGXuYCFaoNHIy6c4=.d698403a-9b24-4394-86b1-a65ab1537c61@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  fix indenting and wildcard imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/253ee1e1..a35fa4cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=08-09

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

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

From kdriver at openjdk.org  Tue Oct 31 20:26:55 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 31 Oct 2023 20:26:55 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v9]
In-Reply-To: <DsKRg_1UYcrq2Pr-58d4fObERyNGAi0137Tfh-oCIRQ=.52c210eb-1a75-46a6-ad9a-ded7d21930c0@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <DsKRg_1UYcrq2Pr-58d4fObERyNGAi0137Tfh-oCIRQ=.52c210eb-1a75-46a6-ad9a-ded7d21930c0@github.com>
Message-ID: <bAUlGH8AcndAYS5SSiTfLe5t8lLAstvHYpJxKahD0ac=.5f426ebc-ad93-444c-9f95-e7f3ebd82df5@github.com>

On Tue, 31 Oct 2023 20:17:59 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change getInstance to not require keystore type

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 108:

> 106: 
> 107:         KeyStore ks = KeyStore.getInstance(new File(keyStoreFile), passphrase);
> 108:         KeyStore ts = KeyStore.getInstance(new File(keyStoreFile), passphrase);

deliberate

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 131:

> 129: 
> 130:         KeyStore ks = KeyStore.getInstance(new File(keyStoreFile), passphrase);
> 131:         KeyStore ts = KeyStore.getInstance(new File(keyStoreFile), passphrase);

deliberate

test/jdk/sun/security/ssl/ServerHandshaker/GetPeerHost.java line 44:

> 42:         System.setProperty("javax.net.ssl.trustStore", testRoot
> 43:                             + "/../../../../javax/net/ssl/etc/truststore");
> 44:         System.setProperty("javax.net.ssl.trustStoreType", "PKCS12");

deliberate

test/jdk/sun/security/ssl/ServerHandshaker/GetPeerHost.java line 45:

> 43:                             + "/../../../../javax/net/ssl/etc/truststore");
> 44:         System.setProperty("javax.net.ssl.trustStoreType", "PKCS12");
> 45:         System.setProperty("javax.net.ssl.trustStorePassword", "passphrase");

deliberate

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378125630
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378125765
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378126246
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378126354

From weijun at openjdk.org  Tue Oct 31 20:41:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 31 Oct 2023 20:41:38 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v10]
In-Reply-To: <NSAg9RLa5Gmhdh-quk5G-z5N6R0eGXuYCFaoNHIy6c4=.d698403a-9b24-4394-86b1-a65ab1537c61@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <NSAg9RLa5Gmhdh-quk5G-z5N6R0eGXuYCFaoNHIy6c4=.d698403a-9b24-4394-86b1-a65ab1537c61@github.com>
Message-ID: <48P6KXIy_I7APATEpCYhYcKMuQk8cYu4RtRK_d-ch3w=.c5aad70e-3007-466c-ae48-64a701f71c2b@github.com>

On Tue, 31 Oct 2023 20:26:50 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indenting and wildcard imports

test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java line 442:

> 440:         TrustManagerFactory tmf;
> 441: 
> 442:         try (FileInputStream fsIn = new FileInputStream(tsPath)) {

No need for this `FileInputStream`.

test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java line 466:

> 464:         KeyManagerFactory kmf;
> 465: 
> 466:         try (FileInputStream fsIn = new FileInputStream(ksPath)) {

No need for this `FileInputStream`.

test/jdk/javax/net/ssl/SSLSession/SessionCacheSizeTests.java line 319:

> 317:         KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
> 318:         KeyStore ks;
> 319:         try (FileInputStream fis = new FileInputStream(keyFilename)) {

No need for this `FileInputStream`.

test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 182:

> 180: 
> 181:         try (FileInputStream keyFile = new FileInputStream(keyFilename);
> 182:                 FileInputStream trustFile = new FileInputStream(trustFilename)) {

No need for these `FileInputStream`s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378138741
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378138890
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378139194
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378140089

From mullan at openjdk.org  Tue Oct 31 20:44:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 31 Oct 2023 20:44:32 GMT
Subject: RFR: 8311546: Certificate name constraints improperly validated
 with leading period [v3]
In-Reply-To: <BjXrdO-vVe3dr_4VKkCKTLDRIEzEaTh7ukL14O6wPpQ=.85eed308-26d7-49f6-b135-ba6d8ee4d8af@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
 <BjXrdO-vVe3dr_4VKkCKTLDRIEzEaTh7ukL14O6wPpQ=.85eed308-26d7-49f6-b135-ba6d8ee4d8af@github.com>
Message-ID: <Z4iS70P6ZTkHUVo7R0twMzm8R-22QX2JtWVbLvJAGzc=.6baf6375-d666-4aa9-a1ed-c1b3243da6dc@github.com>

On Tue, 31 Oct 2023 19:47:48 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed set property

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16295#pullrequestreview-1707206993