From mpowers at openjdk.org  Thu Sep  1 02:26:48 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 02:26:48 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>

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

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

  comments from Sean and Max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9972/files
  - new: https://git.openjdk.org/jdk/pull/9972/files/4157f2a9..5e354828

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

  Stats: 56 lines in 11 files changed: 7 ins; 12 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/9972.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9972/head:pull/9972

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

From weijun at openjdk.org  Thu Sep  1 02:54:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 02:54:31 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3]
In-Reply-To: <d9q4-GCiiu01LK6Q386hJjOU_uaAjz-pnKFUSgNhS0E=.99415721-f9d1-4ecd-aeda-597ddc04abe3@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <zXY8JZO6XVPCLsw6gLZJSL15qjV-m8yAtbeRYTWMhWo=.fbd4a637-17d4-4a5d-839c-ed9e6bad053a@github.com>
 <r-AFQVADs47v39Hto-psizyCHryeOy9GBXXJe4uOFGo=.ad265467-dbc0-4a4d-9502-0637790d4307@github.com>
 <XIIFHNz6yLhNAlhDLAOjN7OjEpQ24H6ZE4GUdHKTdgg=.192fdf42-b4d7-42b4-9813-7cf4ba75658a@github.com>
 <H0V30d2MHrKpj7SqDqd07PG5YSjW25cK-imHou03EaI=.b10777a4-8c2a-430a-9254-97dfedbea2d9@github.com>
 <d9q4-GCiiu01LK6Q386hJjOU_uaAjz-pnKFUSgNhS0E=.99415721-f9d1-4ecd-aeda-597ddc04abe3@github.com>
Message-ID: <G85g-tzLnRT_2hms4YuR44qdYFbcmPatGdDUa54qyWI=.d99a665a-7527-495a-b70c-911822826a77@github.com>

On Tue, 30 Aug 2022 22:53:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-constants
>
> Can't argue with that.

Normally we use `SHA2_GROUP`. There are underscores between the words.

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

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

From weijun at openjdk.org  Thu Sep  1 02:54:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 02:54:31 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <keTtqxkXD8uwHKIOltsCqmKr98EboPOydGEIjF3HxcU=.00ba7511-ea65-4c59-b1e2-cb9dd2a9ad78@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <zXY8JZO6XVPCLsw6gLZJSL15qjV-m8yAtbeRYTWMhWo=.fbd4a637-17d4-4a5d-839c-ed9e6bad053a@github.com>
 <r-AFQVADs47v39Hto-psizyCHryeOy9GBXXJe4uOFGo=.ad265467-dbc0-4a4d-9502-0637790d4307@github.com>
 <keTtqxkXD8uwHKIOltsCqmKr98EboPOydGEIjF3HxcU=.00ba7511-ea65-4c59-b1e2-cb9dd2a9ad78@github.com>
Message-ID: <K5zaJyCeLLt-rXhuSfgXC616XWxYIbWo6jknIApZQNI=.66806747-16cc-4813-9bbb-3bcf202387f5@github.com>

On Wed, 31 Aug 2022 04:22:15 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 47:
>> 
>>> 45: 
>>> 46:     private String digestAlgorithmName;
>>> 47:     private AlgorithmParameters digestAlgorithmParams;
>> 
>> Yes, this field is not used now. But one day we might see one that has parameters. I'd rather keep them and maybe fix `getEncoded` by then.
>
> I put the field back.

There are altogether 3 places where this field was assigned. Make sure to add back all of them.

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

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

From weijun at openjdk.org  Thu Sep  1 03:29:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 03:29:22 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
Message-ID: <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>

On Thu, 1 Sep 2022 02:26:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This includes all in `sun.security.provider.certpath`.

BTW, sometimes some fields are final and some are not, is it better to put the final ones together?

src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java line 105:

> 103:             prevPubKey = trustedPubKey;
> 104:             if (PKIX.isDSAPublicKeyWithoutParams(prevPubKey)) {
> 105:                 // If TrustAnchor is a DSA public key, and it has no params, it

Not a native English speaker, but I found the sentence more fluent without the comma.

src/java.base/share/classes/sun/security/provider/certpath/BuildStep.java line 192:

> 190:         String resultString;
> 191:         switch (res) {
> 192:         case POSSIBLE:

`case` should be indented here. See http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation.

That said, I think this is a good chance to use the switch expressions syntax, i.e `return switch (res)...`.

src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 339:

> 337:                 idpExt.get
> 338:                     (IssuingDistributionPointExtension.INDIRECT_CRL).equals
> 339:                         (Boolean.FALSE)) {

There are only 2 `Boolean` values, so it's safe to use `==`. Also, I'd like

idpExt.get(IssuingDistributionPointExtension.INDIRECT_CRL)
        == Boolean.FALSE

src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 572:

> 570:             if (interimReasonsMask[i] &&
> 571:                     !(i < reasonsMask.length && reasonsMask[i]))
> 572:             {

More brace to previous line.

src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 544:

> 542:                     if (distanceTto1 == distanceTto2) {
> 543:                         return -1;
> 544:                     } else if (distanceTto1 > 0 && distanceTto2 <= 0) {

I feel there is no need for `distanceTto1 > 0 &&` in the above line.

src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java line 703:

> 701:      *
> 702:      * @return the {@code ResponderId} from this response or {@code null}
> 703:      *      if no responder ID is in the body of the response e.g. a

I'd rather add a closed parenthesis at the end, or at least add a comma before `e.g.`

src/java.base/share/classes/sun/security/provider/certpath/PolicyNodeImpl.java line 95:

> 93:         mChildren = new HashSet<>();
> 94: 
> 95:         mValidPolicy = Objects.requireNonNullElse(validPolicy, "");

I prefer `?:`.

src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 479:

> 477: 
> 478:         switch (type) {
> 479:         case "LDAP":

`case` lines should be indented.

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

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

From weijun at openjdk.org  Thu Sep  1 03:47:16 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 03:47:16 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
Message-ID: <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>

On Thu, 1 Sep 2022 02:26:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

More comments. Haven't read `ssl`, `util`, and `x509` yet.

src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 335:

> 333:     private byte[] unpadV15(byte[] padded) throws BadPaddingException {
> 334:         int k = 0;
> 335:         boolean bp = padded[k++] != 0;

The original code looks more clear.

src/java.base/share/classes/sun/security/tools/PathList.java line 69:

> 67:         while (st.hasMoreTokens()) {
> 68:             URL url = fileToURL(new File(st.nextToken()));
> 69:             urls[count++] = url;

Please update the javadoc of `fileToURL` to remove `or null if unknown` in `@return`.

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

> 181:     private List<String> weakWarnings = new ArrayList<>();
> 182: 
> 183:     private Set<X509Certificate> trustedCerts = new HashSet<>();

Put all these `final`s in one group.

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

> 3532:             Object[] source = {alias};
> 3533:             if (otherKeyPass != null) {
> 3534:                 System.err.println(form.format(source));

You can move the line above out as well. It's also the same.

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

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

From aturbanov at openjdk.org  Thu Sep  1 06:24:58 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 1 Sep 2022 06:24:58 GMT
Subject: RFR: 8293197: Avoid double racy reads from non-volatile fields in
 SharedSecrets
Message-ID: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>

After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

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

Commit messages:
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields

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

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

From ecki at zusammenkunft.net  Thu Sep  1 09:54:46 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 1 Sep 2022 09:54:46 +0000
Subject: RFR: 8293197: Avoid double racy reads from non-volatile fields in
 SharedSecrets
In-Reply-To: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
References: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
Message-ID: <AM9P193MB1142E189FA92CDF9D05982D6FF7B9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

BTW, after then ensures it looks like a good candidate for a system-assert for not-null for all of those fields, right?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.org> im Auftrag von Andrey Turbanov <aturbanov at openjdk.org>
Gesendet: Thursday, September 1, 2022 8:24:58 AM
An: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; security-dev at openjdk.org <security-dev at openjdk.org>
Betreff: RFR: 8293197: Avoid double racy reads from non-volatile fields in SharedSecrets

After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

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

Commit messages:
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields

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

PR: https://git.openjdk.org/jdk/pull/10076
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220901/5f8d016f/attachment.htm>

From weijun at openjdk.org  Thu Sep  1 14:28:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 14:28:49 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
Message-ID: <_kZKVYr79h-OFJ9t6NkpGXnGmY4tFyv6GcFxjvWUj0s=.24c1b9d9-1174-4ab0-a0e6-5ae80911c3bd@github.com>

On Thu, 1 Sep 2022 02:26:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

More comments. `x509` and `ssl` not reviewed yet.

src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 110:

> 108:                     !elements.contains(e.getKey())) {
> 109:                 elements.add(e.getKey());
> 110:             } else if (elements.contains(e.getKey())) {

I assume this means that the `add()` method will behave the same anyway, but the original code does seem more clear to me.

src/java.base/share/classes/sun/security/util/DerInputStream.java line 292:

> 290:      * a later call to <code>reset</code> will return here.
> 291:      * The {@code readAheadLimit} is useless here because
> 292:      * all data is available, and we can go to anywhere at will.

I'd rather add a comma before `because`. The sentence means `because (A && B)` and I don't want it look like `because (A) && B`.

src/java.base/share/classes/sun/security/util/HexDumpEncoder.java line 157:

> 155:         int     j;
> 156:         int     numBytes;
> 157:         byte[] tmpbuffer = new byte[bytesPerLine()];

Add one space in between.

src/java.base/share/classes/sun/security/util/HexDumpEncoder.java line 268:

> 266:         int     j;
> 267:         int     numBytes;
> 268:         byte[] tmpbuffer = new byte[bytesPerLine()];

Add one space in between. Or, is my GitHub view distorted?

src/java.base/share/classes/sun/security/validator/PKIXValidator.java line 177:

> 175:     private void setDefaultParameters(String variant) {
> 176:         if ((Objects.equals(variant, Validator.VAR_TLS_SERVER)) ||
> 177:                 (Objects.equals(variant, Validator.VAR_TLS_CLIENT))) {

I think the original code is OK. We only use string literals for variants. That said, maybe it's better to use an enum.

src/java.base/share/classes/sun/security/validator/Validator.java line 268:

> 266:             // redundant.
> 267:             boolean checkUnresolvedCritExts =
> 268:                     !Objects.equals(type, TYPE_PKIX);

Same as above. We only use literals.

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

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

From mpowers at openjdk.org  Thu Sep  1 16:05:36 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 16:05:36 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <_kZKVYr79h-OFJ9t6NkpGXnGmY4tFyv6GcFxjvWUj0s=.24c1b9d9-1174-4ab0-a0e6-5ae80911c3bd@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <_kZKVYr79h-OFJ9t6NkpGXnGmY4tFyv6GcFxjvWUj0s=.24c1b9d9-1174-4ab0-a0e6-5ae80911c3bd@github.com>
Message-ID: <cRhrM9Ph0cdKFF6SSktcckxj-gMEjkT9ON8-KQSY5Kg=.638ea443-fc05-4747-a251-31fcb0eead07@github.com>

On Thu, 1 Sep 2022 13:57:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 110:
> 
>> 108:                     !elements.contains(e.getKey())) {
>> 109:                 elements.add(e.getKey());
>> 110:             } else if (elements.contains(e.getKey())) {
> 
> I assume this means that the `add()` method will behave the same anyway, but the original code does seem more clear to me.

I'll keep the original code.

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

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

From prr at openjdk.org  Thu Sep  1 16:22:19 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Sep 2022 16:22:19 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <xpxCdT38u_gJD8FpwrKs_xFZp6bj6YPjsaYuyqT2poE=.f4dcefea-3da9-4cf4-9113-cffa25068e5a@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

Fixing the compilation is one thing. But did you verify that it actually works as intended ?

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

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

From weijun at openjdk.org  Thu Sep  1 16:34:34 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 16:34:34 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
Message-ID: <pGeGPDfZGRV837iXp3koyRU1-urlPXYtHzYG90_SE6k=.2160e5c3-d4f0-4b0d-bb0d-2f22dba9f09a@github.com>

On Thu, 1 Sep 2022 02:26:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

More comments. `ssl` not read yet.

src/java.base/share/classes/sun/security/x509/AVA.java line 446:

> 444:             if (embeddedHex.size() > 0) {
> 445:                 // add space(s) before embedded hex bytes
> 446:                 temp.append(" ".repeat(Math.max(0, spaceCount)));

`spaceCount` is never negative.

src/java.base/share/classes/sun/security/x509/AVA.java line 462:

> 460:             } else {
> 461:                 // add space(s)
> 462:                 temp.append(" ".repeat(Math.max(0, spaceCount)));

`spaceCount` is never negative.

src/java.base/share/classes/sun/security/x509/AlgIdDSA.java line 50:

> 48:  * operations.  The following is an example of how this may be done assuming
> 49:  * that we have a certificate called <code>currentCert</code> which doesn't
> 50:  * contain DSS/DSA parameters, and we need to derive DSS/DSA parameters

Comma seems misleading. This is all about "an example".

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 311:

> 309:         } else {
> 310:             String n = aliasOidsTable().get(oidStr);
> 311:             return Objects.requireNonNullElseGet(n, () -> algid.toString());

Maybe `?:`.

src/java.base/share/classes/sun/security/x509/CertificateExtensions.java line 266:

> 264:     public Map<String,Extension> getUnparseableExtensions() {
> 265:         return Objects.requireNonNullElse(unparseableExtensions,
> 266:                 Collections.emptyMap());

`?:`

src/java.base/share/classes/sun/security/x509/IPAddressName.java line 214:

> 212: 
> 213:             // copy mask bytes into mask portion of address
> 214:             System.arraycopy(maskArray, 0, address, 16, MASKSIZE);

Please use `MASKSIZE` instead of `16`.

src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java line 143:

> 141: 
> 142:         if (hasOnlyUserCerts && (hasOnlyCACerts || hasOnlyAttributeCerts) ||
> 143:                 hasOnlyCACerts && hasOnlyAttributeCerts) {

Honestly I don't understand the new check. The original one seems more clear.

src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 700:

> 698: 
> 699:         if (id.equalsIgnoreCase(INFO)) {
> 700:             //reset this as certificate data has changed

Duplicated?

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

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

From duke at openjdk.org  Thu Sep  1 17:35:53 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 1 Sep 2022 17:35:53 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
Message-ID: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>

There is a race condition in JDK's SessionManager, which can lead to random exceptions.

**Exception:**

javax.net.ssl.SSLException: Internal error: close session with active objects
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
	at SSLSocketServer$1.run(SSLSocketServer.java:75)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.security.ProviderException: Internal error: close session with active objects
	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
	... 4 more


**Reproducibility:**
I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(

**Problem:**
SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also when 
 counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.

And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 

And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).

There is race condition here. Consider following scenario:

// Thread T1 runs:
Session.removeObject() // [4]
createdObjects.decrementAndGet() // returns zero

// Thread T2 steps in (operating on the same session instance):
Session.addObject() // increases "createdObjects" counter [2]
SessionManager.releaseSession(session) // releases session to objSessions pool

// Thread T1 continues:
SessionManager.demoteObjSession(this) // [6]
objSessions.remove(session) // returns true
opSessions.release(session)  // puts session (with objects!) to opSessions pool
// if opSessions is already full, close of session with objects is attempted throwing Exception..


**Fix:**
SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).

**Testing:**
jdk_security tests passed for me locally with this change.
I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.

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

Commit messages:
 - Fix race condition in pkcs11 SessionManager

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

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

From mpowers at openjdk.org  Thu Sep  1 19:35:50 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 19:35:50 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <_kZKVYr79h-OFJ9t6NkpGXnGmY4tFyv6GcFxjvWUj0s=.24c1b9d9-1174-4ab0-a0e6-5ae80911c3bd@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <_kZKVYr79h-OFJ9t6NkpGXnGmY4tFyv6GcFxjvWUj0s=.24c1b9d9-1174-4ab0-a0e6-5ae80911c3bd@github.com>
Message-ID: <gXJLnmH9vg-5oRs-g2TXOjoZU92GCe0ffnC3sH_FaWY=.cd655af3-956f-4879-be67-3fbcd54f256e@github.com>

On Thu, 1 Sep 2022 14:09: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:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/util/DerInputStream.java line 292:
> 
>> 290:      * a later call to <code>reset</code> will return here.
>> 291:      * The {@code readAheadLimit} is useless here because
>> 292:      * all data is available, and we can go to anywhere at will.
> 
> I'd rather add a comma before `because`. The sentence means `because (A && B)` and I don't want it look like `because (A) && B`.

Added comma.

> src/java.base/share/classes/sun/security/util/HexDumpEncoder.java line 157:
> 
>> 155:         int     j;
>> 156:         int     numBytes;
>> 157:         byte[] tmpbuffer = new byte[bytesPerLine()];
> 
> Add one space in between.

Fixed.

> src/java.base/share/classes/sun/security/util/HexDumpEncoder.java line 268:
> 
>> 266:         int     j;
>> 267:         int     numBytes;
>> 268:         byte[] tmpbuffer = new byte[bytesPerLine()];
> 
> Add one space in between. Or, is my GitHub view distorted?

Fixed.

> src/java.base/share/classes/sun/security/validator/PKIXValidator.java line 177:
> 
>> 175:     private void setDefaultParameters(String variant) {
>> 176:         if ((Objects.equals(variant, Validator.VAR_TLS_SERVER)) ||
>> 177:                 (Objects.equals(variant, Validator.VAR_TLS_CLIENT))) {
> 
> I think the original code is OK. We only use string literals for variants. That said, maybe it's better to use an enum.

I'll revert to the original code. An enum change would affect method definitions wherever `Validator.VAR_:L_SERVER` and friends are used.

> src/java.base/share/classes/sun/security/validator/Validator.java line 268:
> 
>> 266:             // redundant.
>> 267:             boolean checkUnresolvedCritExts =
>> 268:                     !Objects.equals(type, TYPE_PKIX);
> 
> Same as above. We only use literals.

I'll revert to the original code.

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

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

From djelinski at openjdk.org  Thu Sep  1 20:42:11 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 1 Sep 2022 20:42:11 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <N7dMjcy3kc0A4tq5o39qW8ZVp-Q7SzQnJQ-zomAi768=.cab26eb9-a451-435a-9143-e6382eb95c17@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

I verified that client tests still pass. I also verified on a separate project that merging strings with and without ## is equivalent when Zc:preprocessor is absent. When it is present, merging with ## is an error.

I did not verify the output of the changed macros, but I'm pretty confident that their behavior will not change. If you could suggest a test, I'll be happy to perform it.

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

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

From mpowers at openjdk.org  Thu Sep  1 21:38:57 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 21:38:57 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <K5zaJyCeLLt-rXhuSfgXC616XWxYIbWo6jknIApZQNI=.66806747-16cc-4813-9bbb-3bcf202387f5@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <zXY8JZO6XVPCLsw6gLZJSL15qjV-m8yAtbeRYTWMhWo=.fbd4a637-17d4-4a5d-839c-ed9e6bad053a@github.com>
 <r-AFQVADs47v39Hto-psizyCHryeOy9GBXXJe4uOFGo=.ad265467-dbc0-4a4d-9502-0637790d4307@github.com>
 <keTtqxkXD8uwHKIOltsCqmKr98EboPOydGEIjF3HxcU=.00ba7511-ea65-4c59-b1e2-cb9dd2a9ad78@github.com>
 <K5zaJyCeLLt-rXhuSfgXC616XWxYIbWo6jknIApZQNI=.66806747-16cc-4813-9bbb-3bcf202387f5@github.com>
Message-ID: <INRuBbZGcwK0p6M6PtN4AvVJQmbbNGySDGuy0ZmCRKs=.f04a429f-a7b1-417f-b592-2bb08121c00f@github.com>

On Thu, 1 Sep 2022 02:50:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I put the field back.
>
> There are altogether 3 places where this field was assigned. Make sure to add back all of them.

Got 'em all.

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

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

From mpowers at openjdk.org  Thu Sep  1 21:49:15 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 21:49:15 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>
Message-ID: <RDclPksnFlVro_zRhIUfekbN7ugPQ0-lq8msfOO_5iY=.d519f0df-28d1-4353-853c-f2c470583e56@github.com>

On Thu, 1 Sep 2022 02:55:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java line 105:
> 
>> 103:             prevPubKey = trustedPubKey;
>> 104:             if (PKIX.isDSAPublicKeyWithoutParams(prevPubKey)) {
>> 105:                 // If TrustAnchor is a DSA public key, and it has no params, it
> 
> Not a native English speaker, but I found the sentence more fluent without the comma.

Removing the comma.

> src/java.base/share/classes/sun/security/provider/certpath/BuildStep.java line 192:
> 
>> 190:         String resultString;
>> 191:         switch (res) {
>> 192:         case POSSIBLE:
> 
> `case` should be indented here. See http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation.
> 
> That said, I think this is a good chance to use the switch expressions syntax, i.e `return switch (res)...`.

Brad pointed me to this:
https://www.oracle.com/technetwork/java/codeconventions-150003.pdf

I think your reference is better since we're working on OpenJDK.

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

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

From mpowers at openjdk.org  Thu Sep  1 22:12:57 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 22:12:57 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <RDclPksnFlVro_zRhIUfekbN7ugPQ0-lq8msfOO_5iY=.d519f0df-28d1-4353-853c-f2c470583e56@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>
 <RDclPksnFlVro_zRhIUfekbN7ugPQ0-lq8msfOO_5iY=.d519f0df-28d1-4353-853c-f2c470583e56@github.com>
Message-ID: <7hjEYjNVTJXf5RpSUb4V73Vu_-WXriHV_qNV6vj-mmw=.16f8e900-0ad4-4ec7-bd56-803bec600cbf@github.com>

On Thu, 1 Sep 2022 21:46:38 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/BuildStep.java line 192:
>> 
>>> 190:         String resultString;
>>> 191:         switch (res) {
>>> 192:         case POSSIBLE:
>> 
>> `case` should be indented here. See http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation.
>> 
>> That said, I think this is a good chance to use the switch expressions syntax, i.e `return switch (res)...`.
>
> Brad pointed me to this:
> https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
> 
> I think your reference is better since we're working on OpenJDK.

Regarding your `return switch (res)...` comment:
You're suggesting to eliminate `resultString` and `return` after each `case`?

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

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

From mpowers at openjdk.org  Thu Sep  1 22:24:10 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 1 Sep 2022 22:24:10 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <7hjEYjNVTJXf5RpSUb4V73Vu_-WXriHV_qNV6vj-mmw=.16f8e900-0ad4-4ec7-bd56-803bec600cbf@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>
 <RDclPksnFlVro_zRhIUfekbN7ugPQ0-lq8msfOO_5iY=.d519f0df-28d1-4353-853c-f2c470583e56@github.com>
 <7hjEYjNVTJXf5RpSUb4V73Vu_-WXriHV_qNV6vj-mmw=.16f8e900-0ad4-4ec7-bd56-803bec600cbf@github.com>
Message-ID: <m0e4yTGcZvra_ycsP-F-GLQGc-hkQB3Qc5XOTsE0fMQ=.ad37d989-40a9-4826-bed4-178757a0d039@github.com>

On Thu, 1 Sep 2022 22:10:54 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Brad pointed me to this:
>> https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
>> 
>> I think your reference is better since we're working on OpenJDK.
>
> Regarding your `return switch (res)...` comment:
> You're suggesting to eliminate `resultString` and `return` after each `case`?

Never mind. I see what you're suggesting.

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

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

From weijun at openjdk.org  Thu Sep  1 23:37:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 23:37:31 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
Message-ID: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>

Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.

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

Commit messages:
 - api change

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

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

From weijun at openjdk.org  Thu Sep  1 23:37:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 23:37:31 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
In-Reply-To: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
Message-ID: <MDzKb0Q3iJ3j1QPDvhF-bjNSct7gcrr94R3iObFPLcw=.f72abe42-16e5-4b7d-8996-cf5e32222306@github.com>

On Thu, 1 Sep 2022 23:25:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.

The first commit only contains API change. Implementation will be provided in later commit(s).

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

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

From ascarpino at openjdk.org  Thu Sep  1 23:37:33 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 1 Sep 2022 23:37:33 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
In-Reply-To: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
Message-ID: <qfdUu8qLxA0Xc7BeZiH2lkFaj22z4hb2KPECD1LRatM=.e5cd258f-ecc7-4f03-969c-bd775e5e7290@github.com>

On Thu, 1 Sep 2022 23:25:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.

src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 109:

> 107:      * If this object is created with {@link #EncodedKeySpec(byte[])}, this method in
> 108:      * this base class returns {@code null}. A child class may parse the content of the encoded
> 109:      * key and return its algorithm name if one can be recovered.

Personally I think it sounds better to say "key and return its algorithm name if it can be determined.

src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 73:

> 71:      * it will be returned. Otherwise, the object identifier inside the `privateKeyAlgorithm`
> 72:      * field is returned in its string format (For example, "1.3.14.7.2.1.1").
> 73:      * If the encoded key cannot be parsed correctly, the algorithm will be null.

Is this that OID format last week we talked about with passing algorithms we don't know to another provider?

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

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

From weijun at openjdk.org  Thu Sep  1 23:37:34 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 23:37:34 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
In-Reply-To: <qfdUu8qLxA0Xc7BeZiH2lkFaj22z4hb2KPECD1LRatM=.e5cd258f-ecc7-4f03-969c-bd775e5e7290@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <qfdUu8qLxA0Xc7BeZiH2lkFaj22z4hb2KPECD1LRatM=.e5cd258f-ecc7-4f03-969c-bd775e5e7290@github.com>
Message-ID: <-uRuftcWDp8Eu4QE0YWFIwcRCmoKlCg6CYTGp00nA2k=.8182e4f8-e134-4c69-918f-49c2ecbfddd5@github.com>

On Thu, 1 Sep 2022 23:30:40 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.
>
> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 73:
> 
>> 71:      * it will be returned. Otherwise, the object identifier inside the `privateKeyAlgorithm`
>> 72:      * field is returned in its string format (For example, "1.3.14.7.2.1.1").
>> 73:      * If the encoded key cannot be parsed correctly, the algorithm will be null.
> 
> Is this that OID format last week we talked about with passing algorithms we don't know to another provider?

Yes, if it's unknown. I plan to implement this with `AlgorithmId.parse(privateKeyAlgorithm).getName()`.

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

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

From weijun at openjdk.org  Thu Sep  1 23:50:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Sep 2022 23:50:47 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
Message-ID: <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>

> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.

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

  fine tune spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10131/files
  - new: https://git.openjdk.org/jdk/pull/10131/files/ecd2e839..57e2315b

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

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

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

From valeriep at openjdk.org  Thu Sep  1 23:50:49 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Sep 2022 23:50:49 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
In-Reply-To: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
Message-ID: <qCz6_ObcMq8feFEEhPedwhfeA973jwuIPKBdaxcbIMQ=.8851ea57-461f-42b0-a4bd-fbd0890aea0b@github.com>

On Thu, 1 Sep 2022 23:25:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.

I assume there will be regression test?

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

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

From valeriep at openjdk.org  Thu Sep  1 23:50:50 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Sep 2022 23:50:50 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
Message-ID: <-A4R9l6pS4wdGmqVSoBOzEQRI4IDTER2Y2ddd4HXU_Q=.de5f64ba-ebfb-4a4a-b864-042deae17f58@github.com>

On Thu, 1 Sep 2022 23:45:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tune spec

src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 75:

> 73:      * field is returned in its string format as a series of nonnegative
> 74:      * integers separated by periods (For example, "1.3.14.7.2.1.1").
> 75:      * If the encoded key cannot be parsed correctly, the algorithm is {@code null}.

Should these be under @implNote? Same question for the X509EncodedKeySpec also.

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

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

From weijun at openjdk.org  Fri Sep  2 00:01:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Sep 2022 00:01:44 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
In-Reply-To: <qCz6_ObcMq8feFEEhPedwhfeA973jwuIPKBdaxcbIMQ=.8851ea57-461f-42b0-a4bd-fbd0890aea0b@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <qCz6_ObcMq8feFEEhPedwhfeA973jwuIPKBdaxcbIMQ=.8851ea57-461f-42b0-a4bd-fbd0890aea0b@github.com>
Message-ID: <2O9lwHFFPLkKHEEApvLZiujnCq7AZP5PmhLt-taNgeA=.778c5167-d11f-4e5e-8272-7d0e5f0454c1@github.com>

On Thu, 1 Sep 2022 23:45:30 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> I assume there will be regression test?

Yes. I am only proposing spec change at the moment. Once we reach an agreement I'll fix a CSR and start coding on implementation and tests.

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

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

From weijun at openjdk.org  Fri Sep  2 00:01:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Sep 2022 00:01:47 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <qfdUu8qLxA0Xc7BeZiH2lkFaj22z4hb2KPECD1LRatM=.e5cd258f-ecc7-4f03-969c-bd775e5e7290@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <qfdUu8qLxA0Xc7BeZiH2lkFaj22z4hb2KPECD1LRatM=.e5cd258f-ecc7-4f03-969c-bd775e5e7290@github.com>
Message-ID: <_GLF4zDfOFBYH54mP0KpLQpf5m0oUEByKplf7xE1af4=.9fdc4caa-a745-46d5-8acd-7b2aa8d3bd02@github.com>

On Thu, 1 Sep 2022 23:28:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tune spec
>
> src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 109:
> 
>> 107:      * If this object is created with {@link #EncodedKeySpec(byte[])}, this method in
>> 108:      * this base class returns {@code null}. A child class may parse the content of the encoded
>> 109:      * key and return its algorithm name if one can be recovered.
> 
> Personally I think it sounds better to say "key and return its algorithm name if it can be determined.

OK.

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

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

From weijun at openjdk.org  Fri Sep  2 00:01:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Sep 2022 00:01:49 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <-A4R9l6pS4wdGmqVSoBOzEQRI4IDTER2Y2ddd4HXU_Q=.de5f64ba-ebfb-4a4a-b864-042deae17f58@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
 <-A4R9l6pS4wdGmqVSoBOzEQRI4IDTER2Y2ddd4HXU_Q=.de5f64ba-ebfb-4a4a-b864-042deae17f58@github.com>
Message-ID: <pWpva2q5Z4y754gjDLovBVE4RdqS2Ri3lx6wh0pWy_4=.62f22f9f-1102-4800-a1be-050652e00706@github.com>

On Thu, 1 Sep 2022 23:44:02 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tune spec
>
> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 75:
> 
>> 73:      * field is returned in its string format as a series of nonnegative
>> 74:      * integers separated by periods (For example, "1.3.14.7.2.1.1").
>> 75:      * If the encoded key cannot be parsed correctly, the algorithm is {@code null}.
> 
> Should these be under @implNote? Same question for the X509EncodedKeySpec also.

I want this to be spec from now on. If we want to backport this to older releases, then the paragraph above can be @implNote.

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

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

From ascarpino at openjdk.org  Fri Sep  2 00:05:49 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 2 Sep 2022 00:05:49 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
Message-ID: <pc6D6bcQyN_k13fLxo-0_BFzNwbJ8BJykVQrSJsMXqQ=.3205269f-fccb-4f19-a659-c35d69b16639@github.com>

On Thu, 1 Sep 2022 23:50:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tune spec

Marked as reviewed by ascarpino (Reviewer).

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

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

From mpowers at openjdk.org  Fri Sep  2 00:41:22 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 00:41:22 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <ufsqPlkXptGb82TGvtIrPQfPVTick9aDTOxrPvnp59E=.825a1c3d-e977-4ff7-82f2-594215e9ae48@github.com>
Message-ID: <yA1Qqlp_FW1Z6vVrtxA8z5MfFuaBdVDVxu-0DHvv6RQ=.7ed6ccf4-ea88-4604-85cb-bef1cbeb4011@github.com>

On Thu, 1 Sep 2022 03:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 339:
> 
>> 337:                 idpExt.get
>> 338:                     (IssuingDistributionPointExtension.INDIRECT_CRL).equals
>> 339:                         (Boolean.FALSE)) {
> 
> There are only 2 `Boolean` values, so it's safe to use `==`. Also, I'd like
> 
> idpExt.get(IssuingDistributionPointExtension.INDIRECT_CRL)
>         == Boolean.FALSE

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 572:
> 
>> 570:             if (interimReasonsMask[i] &&
>> 571:                     !(i < reasonsMask.length && reasonsMask[i]))
>> 572:             {
> 
> More brace to previous line.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 544:
> 
>> 542:                     if (distanceTto1 == distanceTto2) {
>> 543:                         return -1;
>> 544:                     } else if (distanceTto1 > 0 && distanceTto2 <= 0) {
> 
> I feel there is no need for `distanceTto1 > 0 &&` in the above line.

You need it if `distanceTto1 `is 0 on line 541.

> src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java line 703:
> 
>> 701:      *
>> 702:      * @return the {@code ResponderId} from this response or {@code null}
>> 703:      *      if no responder ID is in the body of the response e.g. a
> 
> I'd rather add a closed parenthesis at the end, or at least add a comma before `e.g.`

Adding a comma.

> src/java.base/share/classes/sun/security/provider/certpath/PolicyNodeImpl.java line 95:
> 
>> 93:         mChildren = new HashSet<>();
>> 94: 
>> 95:         mValidPolicy = Objects.requireNonNullElse(validPolicy, "");
> 
> I prefer `?:`.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 479:
> 
>> 477: 
>> 478:         switch (type) {
>> 479:         case "LDAP":
> 
> `case` lines should be indented.

Fixed.

> src/java.base/share/classes/sun/security/tools/PathList.java line 69:
> 
>> 67:         while (st.hasMoreTokens()) {
>> 68:             URL url = fileToURL(new File(st.nextToken()));
>> 69:             urls[count++] = url;
> 
> Please update the javadoc of `fileToURL` to remove `or null if unknown` in `@return`.

Fixed.

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

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

From mpowers at openjdk.org  Fri Sep  2 01:04:57 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 01:04:57 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>
Message-ID: <baUbARJPxEbhWhAoSzMhwAzPRKrqa2SafjwJXXXNkmc=.742b380c-431f-4646-803a-5b06ff86c1b4@github.com>

On Thu, 1 Sep 2022 03:31:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 183:
> 
>> 181:     private List<String> weakWarnings = new ArrayList<>();
>> 182: 
>> 183:     private Set<X509Certificate> trustedCerts = new HashSet<>();
> 
> Put all these `final`s in one group.

If I do that, it will mess up existing groups, e.g. `// Warnings on weak algorithms etc`. I was able to move a few files around, but not many.

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

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

From mpowers at openjdk.org  Fri Sep  2 04:20:00 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 04:20:00 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>
Message-ID: <kNv4pRxGXA2k2d_0tkgWwye9N7mmq2mYMC9WDMFVCOg=.bdff734e-b6e3-46b1-a795-d3c60094d25e@github.com>

On Thu, 1 Sep 2022 03:40:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 335:
> 
>> 333:     private byte[] unpadV15(byte[] padded) throws BadPaddingException {
>> 334:         int k = 0;
>> 335:         boolean bp = padded[k++] != 0;
> 
> The original code looks more clear.

I'll keep the original code.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 3534:
> 
>> 3532:             Object[] source = {alias};
>> 3533:             if (otherKeyPass != null) {
>> 3534:                 System.err.println(form.format(source));
> 
> You can move the line above out as well. It's also the same.

I can't factor them out because one is `println` and the other is `print`.

> src/java.base/share/classes/sun/security/x509/AVA.java line 446:
> 
>> 444:             if (embeddedHex.size() > 0) {
>> 445:                 // add space(s) before embedded hex bytes
>> 446:                 temp.append(" ".repeat(Math.max(0, spaceCount)));
> 
> `spaceCount` is never negative.

Changed to `repeat(spaceCount)`.

> src/java.base/share/classes/sun/security/x509/AVA.java line 462:
> 
>> 460:             } else {
>> 461:                 // add space(s)
>> 462:                 temp.append(" ".repeat(Math.max(0, spaceCount)));
> 
> `spaceCount` is never negative.

Changed to `repeat(spaceCount)`.

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

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

From djelinski at openjdk.org  Fri Sep  2 05:55:43 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 2 Sep 2022 05:55:43 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <x-L4S9dK3F9qy_KiAyfhEFAPkPaOz08sdO2uP5CRPis=.51b3a808-3b39-42eb-80ac-e23cc4a65ca1@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

FWIW, here's the test that I used:


#include <stdio.h>

#define PRINTERR(res) \
  PRINT(res, " " ## #res ## " in file " __FILE__);
  
#define PRINT(res, msg) \
  printf("- " ## msg ## " val=%d\n", res);
  
int main() {
	for (int i = 0; i < 2; i++) {
		PRINTERR(i);
	}
}

Output:

-  i in file test.c val=0
-  i in file test.c val=1

removing `##` does not change the output.

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

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

From duke at openjdk.org  Fri Sep  2 09:15:40 2022
From: duke at openjdk.org (Bernd)
Date: Fri, 2 Sep 2022 09:15:40 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
Message-ID: <pZsYPPK2evRHsewWcBhoakHcCFqGJVAtxMsNHtIGX2E=.677fd75a-9f53-47db-9c89-5f9f7e20a5a6@github.com>

On Thu, 1 Sep 2022 23:50:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tune spec

Should this also be aligned with EncryptedPrivateKeyInfo? https://github.com/openjdk/jdk/blob/57e2315bbc3ad4f0d1b96fb5944f7799b78a1630/src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java#L211

See also my PBES2 discussion on secure-dev last month.

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

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

From duke at openjdk.org  Fri Sep  2 09:15:41 2022
From: duke at openjdk.org (Bernd)
Date: Fri, 2 Sep 2022 09:15:41 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <pWpva2q5Z4y754gjDLovBVE4RdqS2Ri3lx6wh0pWy_4=.62f22f9f-1102-4800-a1be-050652e00706@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
 <-A4R9l6pS4wdGmqVSoBOzEQRI4IDTER2Y2ddd4HXU_Q=.de5f64ba-ebfb-4a4a-b864-042deae17f58@github.com>
 <pWpva2q5Z4y754gjDLovBVE4RdqS2Ri3lx6wh0pWy_4=.62f22f9f-1102-4800-a1be-050652e00706@github.com>
Message-ID: <US-UVF82zLqb9HEtYblLbKm9YACgdg0poar7kx_-QFo=.873a0d62-641c-4221-ab46-0e78f9b734c7@github.com>

On Thu, 1 Sep 2022 23:55:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 75:
>> 
>>> 73:      * field is returned in its string format as a series of nonnegative
>>> 74:      * integers separated by periods (For example, "1.3.14.7.2.1.1").
>>> 75:      * If the encoded key cannot be parsed correctly, the algorithm is {@code null}.
>> 
>> Should these be under @implNote? Same question for the X509EncodedKeySpec also.
>
> I want this to be spec from now on. If we want to backport this to older releases, then the paragraph above can be @implNote.

I agree that this should be in the API spec.

Does the ?return null? case for invalid encodings need to mention any exceptions triggered by the actual key instantion to make clear the Spec is only a container?

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

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

From mpowers at openjdk.org  Fri Sep  2 15:50:51 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 15:50:51 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <pGeGPDfZGRV837iXp3koyRU1-urlPXYtHzYG90_SE6k=.2160e5c3-d4f0-4b0d-bb0d-2f22dba9f09a@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <pGeGPDfZGRV837iXp3koyRU1-urlPXYtHzYG90_SE6k=.2160e5c3-d4f0-4b0d-bb0d-2f22dba9f09a@github.com>
Message-ID: <1w3vBCANGlM2K3nAbOdIOMfGe31JA3CBFfg_usQds9w=.6e16924f-f49c-4f0e-891d-5d99e4a25a67@github.com>

On Thu, 1 Sep 2022 14:31:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sean and Max
>
> src/java.base/share/classes/sun/security/x509/AlgIdDSA.java line 50:
> 
>> 48:  * operations.  The following is an example of how this may be done assuming
>> 49:  * that we have a certificate called <code>currentCert</code> which doesn't
>> 50:  * contain DSS/DSA parameters, and we need to derive DSS/DSA parameters
> 
> Comma seems misleading. This is all about "an example".

Removing the comma.

> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 311:
> 
>> 309:         } else {
>> 310:             String n = aliasOidsTable().get(oidStr);
>> 311:             return Objects.requireNonNullElseGet(n, () -> algid.toString());
> 
> Maybe `?:`.

Fixed.

> src/java.base/share/classes/sun/security/x509/CertificateExtensions.java line 266:
> 
>> 264:     public Map<String,Extension> getUnparseableExtensions() {
>> 265:         return Objects.requireNonNullElse(unparseableExtensions,
>> 266:                 Collections.emptyMap());
> 
> `?:`

Fixed.

> src/java.base/share/classes/sun/security/x509/IPAddressName.java line 214:
> 
>> 212: 
>> 213:             // copy mask bytes into mask portion of address
>> 214:             System.arraycopy(maskArray, 0, address, 16, MASKSIZE);
> 
> Please use `MASKSIZE` instead of `16`.

Fixed.

> src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java line 143:
> 
>> 141: 
>> 142:         if (hasOnlyUserCerts && (hasOnlyCACerts || hasOnlyAttributeCerts) ||
>> 143:                 hasOnlyCACerts && hasOnlyAttributeCerts) {
> 
> Honestly I don't understand the new check. The original one seems more clear.

Using original check.

> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 700:
> 
>> 698: 
>> 699:         if (id.equalsIgnoreCase(INFO)) {
>> 700:             //reset this as certificate data has changed
> 
> Duplicated?

Line has been removed.

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

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

From mpowers at openjdk.org  Fri Sep  2 16:47:56 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 16:47:56 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3]
In-Reply-To: <G85g-tzLnRT_2hms4YuR44qdYFbcmPatGdDUa54qyWI=.d99a665a-7527-495a-b70c-911822826a77@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <zXY8JZO6XVPCLsw6gLZJSL15qjV-m8yAtbeRYTWMhWo=.fbd4a637-17d4-4a5d-839c-ed9e6bad053a@github.com>
 <r-AFQVADs47v39Hto-psizyCHryeOy9GBXXJe4uOFGo=.ad265467-dbc0-4a4d-9502-0637790d4307@github.com>
 <XIIFHNz6yLhNAlhDLAOjN7OjEpQ24H6ZE4GUdHKTdgg=.192fdf42-b4d7-42b4-9813-7cf4ba75658a@github.com>
 <H0V30d2MHrKpj7SqDqd07PG5YSjW25cK-imHou03EaI=.b10777a4-8c2a-430a-9254-97dfedbea2d9@github.com>
 <d9q4-GCiiu01LK6Q386hJjOU_uaAjz-pnKFUSgNhS0E=.99415721-f9d1-4ecd-aeda-597ddc04abe3@github.com>
 <G85g-tzLnRT_2hms4YuR44qdYFbcmPatGdDUa54qyWI=.d99a665a-7527-495a-b70c-911822826a77@github.com>
Message-ID: <JKP6sgZPEBqhuUV07xiifkuAjTOL0Z_AUTvhaUxUHSs=.e919cb29-40b4-4d7c-8eb1-7192dd6d77c6@github.com>

On Thu, 1 Sep 2022 02:49:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Can't argue with that.
>
> Normally we use `SHA2_GROUP`. There are underscores between the words.

Added underscores.

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

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

From mpowers at openjdk.org  Fri Sep  2 18:33:22 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 18:33:22 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v5]
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <wDKEXTYICebwiwap1U0hy1CTaYsoBwnBdeS2O6VAiAs=.473b2b2f-7855-4820-b27f-2848c0a262c8@github.com>

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

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

  comments from Max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9972/files
  - new: https://git.openjdk.org/jdk/pull/9972/files/5e354828..8ad0aa97

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

  Stats: 94 lines in 23 files changed: 10 ins; 19 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/9972.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9972/head:pull/9972

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

From mpowers at openjdk.org  Fri Sep  2 18:48:32 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Sep 2022 18:48:32 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>

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

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

  white space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9972/files
  - new: https://git.openjdk.org/jdk/pull/9972/files/8ad0aa97..366b957a

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

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

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

From duke at openjdk.org  Sat Sep  3 01:46:52 2022
From: duke at openjdk.org (duke)
Date: Sat, 3 Sep 2022 01:46:52 GMT
Subject: Withdrawn: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
Message-ID: <5E69596JrwUNhWVdpkH8UDPUo0ltn6bYjZXi9p6dYCI=.c731e9cf-4081-4077-a085-edc263fba7da@github.com>

On Tue, 14 Jun 2022 17:57:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Clearing buffers and temporary arrays to avoid data leaks in cipher operations.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Sat Sep  3 07:26:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Sep 2022 07:26:47 GMT
Subject: RFR: 8293197: Avoid double racy reads from non-volatile fields in
 SharedSecrets
In-Reply-To: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
References: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
Message-ID: <lLWJU_xZvo7T9tHiWPgB36H7jToE4jRrNNmcbIkZ7JA=.b054bd0f-92e1-4649-9948-ba3011815a11@github.com>

On Tue, 30 Aug 2022 07:10:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

Surprising that the additions since JDK-8259021 didn't follow the same pattern but I think some of these were in other repos at the time.

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

Marked as reviewed by alanb (Reviewer).

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

From djelinski at openjdk.org  Mon Sep  5 07:25:28 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Sep 2022 07:25:28 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <p9GGSes8rI9lo9gU-HAPfXd29oeooC0x_obHGQ7rOkk=.ec08aee6-0772-49ec-a8a2-31a68c0e44dd@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

I verified the preprocessor output on `D3DResourceManager.cpp` file, which uses 3 of the 4 changed macros in `D3DPipeline.h` (`RETURN_STATUS_IF_EXP_FAILED` is not used anywhere). The generated files have only cosmetic differences - `##` removes whitespace between the concatenated string literals, and without `##` the whitespace is preserved. This whitespace is ignored by the compiler.

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

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

From djelinski at openjdk.org  Mon Sep  5 07:25:29 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Sep 2022 07:25:29 GMT
Subject: Integrated: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <8jbP_1Aah3x4T_snhUAcWiN5NsxDJgst1JHiFYOrngY=.fe496f0d-51e9-4e0f-a6f4-c1df98174f4b@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

This pull request has now been integrated.

Changeset: e945619d
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e945619ddd38091eaa010f65472141443b8f214d
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8293088: Fix compilation with the new Visual Studio preprocessor

Reviewed-by: ihse

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

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

From djelinski at openjdk.org  Mon Sep  5 09:42:59 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Sep 2022 09:42:59 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
Message-ID: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>

This patch enables SignTwice test to complete faster on Windows machines.

The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.

The fix removes `java.security.egd` setting on Windows machines.

Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

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

Commit messages:
 - Remove dev/./urandom on Windows

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

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

From weijun at openjdk.org  Mon Sep  5 14:39:38 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Sep 2022 14:39:38 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
Message-ID: <yfdN_dTMa_8DvjP-85uF2SXza6WlbCs5NN_5lXpfCsg=.af4d4f85-0cae-4c63-a115-4dad4d994a81@github.com>

On Mon, 5 Sep 2022 09:29:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch enables SignTwice test to complete faster on Windows machines.
> 
> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
> 
> The fix removes `java.security.egd` setting on Windows machines.
> 
> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

There are helper methods in `jdk.test.lib.SecurityTools` that knows about when to use the EGD property.

@bradfordwetmore, is the `/dev/./urandom` trick not necessary anymore?

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

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

From weijun at openjdk.org  Mon Sep  5 14:43:36 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Sep 2022 14:43:36 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
Message-ID: <v-TVGyBWOGFjrXPTSFKIp_2OTxC97ELhWE26XUaR7Q4=.b55014ab-b8a5-41a5-861d-c0fcc6642daf@github.com>

On Mon, 5 Sep 2022 09:29:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch enables SignTwice test to complete faster on Windows machines.
> 
> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
> 
> The fix removes `java.security.egd` setting on Windows machines.
> 
> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

Marked as reviewed by weijun (Reviewer).

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

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

From wetmore at openjdk.org  Mon Sep  5 15:04:49 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 5 Sep 2022 15:04:49 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <yfdN_dTMa_8DvjP-85uF2SXza6WlbCs5NN_5lXpfCsg=.af4d4f85-0cae-4c63-a115-4dad4d994a81@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
 <yfdN_dTMa_8DvjP-85uF2SXza6WlbCs5NN_5lXpfCsg=.af4d4f85-0cae-4c63-a115-4dad4d994a81@github.com>
Message-ID: <f7CFCFnbmt6g50cVEPDTJjz9qI99ufzHC8GxFksXYLw=.d2cd63db-2b29-48f2-a901-5717104929b3@github.com>

On Mon, 5 Sep 2022 14:37:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> @bradfordwetmore, is the `/dev/./urandom` trick not necessary anymore?

Not necessary in current JDK, but not sure if this was backported to JDK 8u.

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

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

From djelinski at openjdk.org  Mon Sep  5 17:07:51 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Sep 2022 17:07:51 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
Message-ID: <9vbupTndc439SsbM1-Z6Oi75XgdViNSlyIj85OLZp9M=.0f000557-c843-4534-a81e-46cfba56eb6b@github.com>

On Mon, 5 Sep 2022 09:29:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch enables SignTwice test to complete faster on Windows machines.
> 
> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
> 
> The fix removes `java.security.egd` setting on Windows machines.
> 
> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

as far as I can tell, the `dev/./urandom` trick was only needed before 63a6638ebfe5b492d3156694024b37fa7a229a86, which was shipped in JDK8. 
`jdk.test.lib.SecurityTools` is also using `dev/./urandom`, so I'll leave the dot here for now.

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

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

From wetmore at openjdk.org  Mon Sep  5 17:29:39 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 5 Sep 2022 17:29:39 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
Message-ID: <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>

On Mon, 5 Sep 2022 09:29:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch enables SignTwice test to complete faster on Windows machines.
> 
> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
> 
> The fix removes `java.security.egd` setting on Windows machines.
> 
> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 1044:

> 1042:             } else {
> 1043:                 cmd = new String[args.length + 4];
> 1044:                 cmd[3] = "-J-Djava.security.egd=file:/dev/./urandom";

IIRC, this is a workaround for an old issue which no longer applies after JDK-6425477.  By default NativePRNG generates from /dev/urandom, only grabbing seed data from /dev/random.

I believe the egd workaround can be completely removed unless there's something that asks for NativePRNGBlocking.

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

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

From weijun at openjdk.org  Mon Sep  5 18:55:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Sep 2022 18:55:43 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
 <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>
Message-ID: <316-Xmp8hJW9ErsLfyvCgPRTbTwV0OcfySypJs7Immw=.3044a3e8-9300-43e1-b521-e2f1ba3bc739@github.com>

On Mon, 5 Sep 2022 17:25:48 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> This patch enables SignTwice test to complete faster on Windows machines.
>> 
>> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
>> 
>> The fix removes `java.security.egd` setting on Windows machines.
>> 
>> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.
>
> test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 1044:
> 
>> 1042:             } else {
>> 1043:                 cmd = new String[args.length + 4];
>> 1044:                 cmd[3] = "-J-Djava.security.egd=file:/dev/./urandom";
> 
> IIRC, this is a workaround for an old issue which no longer applies after JDK-6425477.  By default NativePRNG generates from /dev/urandom, only grabbing seed data from /dev/random.
> 
> I believe the egd workaround can be completely removed unless there's something that asks for NativePRNGBlocking.

I remember the major problem was the auto-seeding before the first `nextBytes` is called, and it could read `/dev/random`. Not sure it's for SHA1PRNG or NativeRandom.

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

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

From wetmore at openjdk.org  Tue Sep  6 01:28:43 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 6 Sep 2022 01:28:43 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <316-Xmp8hJW9ErsLfyvCgPRTbTwV0OcfySypJs7Immw=.3044a3e8-9300-43e1-b521-e2f1ba3bc739@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
 <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>
 <316-Xmp8hJW9ErsLfyvCgPRTbTwV0OcfySypJs7Immw=.3044a3e8-9300-43e1-b521-e2f1ba3bc739@github.com>
Message-ID: <am53FvYWBK7HJaI0gPih1Qf8mZWm9rVbPZjKL1uZK3A=.35c3f12c-50a4-4b98-adcc-c7e4761efc49@github.com>

On Mon, 5 Sep 2022 18:52:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 1044:
>> 
>>> 1042:             } else {
>>> 1043:                 cmd = new String[args.length + 4];
>>> 1044:                 cmd[3] = "-J-Djava.security.egd=file:/dev/./urandom";
>> 
>> IIRC, this is a workaround for an old issue which no longer applies after JDK-6425477.  By default NativePRNG generates from /dev/urandom, only grabbing seed data from /dev/random.
>> 
>> I believe the egd workaround can be completely removed unless there's something that asks for NativePRNGBlocking.
>
> I remember the major problem was the auto-seeding before the first `nextBytes` is called, and it could read `/dev/random`. Not sure it's for SHA1PRNG or NativeRandom.

SHA1PRNG, which is no longer the default on Linux.  But some apps are still asking for SHA1PRNG instead of using the default NativePRNG on Linux.

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

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

From djelinski at openjdk.org  Tue Sep  6 09:23:43 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 6 Sep 2022 09:23:43 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <am53FvYWBK7HJaI0gPih1Qf8mZWm9rVbPZjKL1uZK3A=.35c3f12c-50a4-4b98-adcc-c7e4761efc49@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
 <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>
 <316-Xmp8hJW9ErsLfyvCgPRTbTwV0OcfySypJs7Immw=.3044a3e8-9300-43e1-b521-e2f1ba3bc739@github.com>
 <am53FvYWBK7HJaI0gPih1Qf8mZWm9rVbPZjKL1uZK3A=.35c3f12c-50a4-4b98-adcc-c7e4761efc49@github.com>
Message-ID: <DOOiP8zfZR-iTz3PlDJzs6OTImT0qvZJExjkEdI7N_I=.8ca50711-7a80-4084-91f3-92e3e9025b1e@github.com>

On Tue, 6 Sep 2022 01:26:34 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> I remember the major problem was the auto-seeding before the first `nextBytes` is called, and it could read `/dev/random`. Not sure it's for SHA1PRNG or NativeRandom.
>
> SHA1PRNG, which is no longer the default on Linux.  But some apps are still asking for SHA1PRNG instead of using the default NativePRNG on Linux.

FWIW, NativePRNGBlocking ignores java.security.egd and always uses `/dev/random`.

I'd rather not clean up all references to EGD here. Filed [JDK-8293412](https://bugs.openjdk.org/browse/JDK-8293412) as a follow up.

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

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

From weijun at openjdk.org  Tue Sep  6 14:13:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:13:44 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
Message-ID: <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>

On Thu, 25 Aug 2022 19:59:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 599:
>> 
>>> 597:         // Returns all installed providers
>>> 598:         // if the selection criteria is null.
>>> 599:         if ((keySet == null) || (allProviders == null)) {
>> 
>> I'm not sure, but can `keySet` or `allProviders` be null? Or you meant `isEmpty()`?
>
> Both may be null as their javadoc didn't state explicitly what is returned.
> This is existing code and it returns null upon empty keySet which I keep the same behavior. 
> Perhaps for consistency sake, it should also check for the empty keySet condition and return allProviders.

Sorry, I re-read and maybe the original check is better. If both `keySet` and `allProviders` are empty, then empty is returned. According to the spec, it should be null.

I still don't think either of them can be null, but adding the `isEmpty` check is probably wrong.

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

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

From weijun at openjdk.org  Tue Sep  6 14:23:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:23:49 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
Message-ID: <GiXZ021GWrGphL4PVH-ShkhyyoT4LzOnGlACEYM2mZQ=.a23ebd45-0253-46f0-8894-1869c0ac9521@github.com>

On Mon, 29 Aug 2022 20:13:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more refactoring.

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

> 611:         // For each selection criterion, remove providers
> 612:         // which don't satisfy the criterion from the candidate set.
> 613:         Iterator<Map.Entry<String, String>> iter = entries.iterator();

`for (var e : entries)` is simpler.

Inside the loop, you can also directly return `null` is it's empty. Then there is no need to check for `isEmpty` again outside.

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

> 822:         private String algName;
> 823:         private String attrName = null;
> 824:         private String attrValue;

Make these `final`.

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

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

From weijun at openjdk.org  Tue Sep  6 14:30:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:30:04 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
Message-ID: <5iw0bxqsKeBzSBFrz9b_xaPm1GIg5E3k7vsjklUgGu0=.a7bcbb0a-5d44-46a1-b1c1-e2687d2941dd@github.com>

On Mon, 29 Aug 2022 20:13:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more refactoring.

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

> 859:             // check required values
> 860:             if (serviceName.isEmpty() || algName.isEmpty() ||
> 861:                     (!attrValue.isEmpty() && attrName.isEmpty())) {

Can we move the `attrName.isEmpty()` check inside the `else` block above? I find it easier to understand.

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

> 862:                 throw new InvalidParameterException("Invalid filter");
> 863:             }
> 864:         }

Add an empty line here.

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

> 863:             }
> 864:         }
> 865:         void apply(LinkedList<Provider> candidates) {

`candidates.removeIf(p -> !isCriterionSatisfied(p));`

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

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

From weijun at openjdk.org  Tue Sep  6 14:33:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:33:07 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
Message-ID: <B7uS1SRgWsMVLiDL20Evjh2PI1yuyKe5_RPrXKuZ1-s=.0b9eceda-c22f-43f3-9986-252b4f129cef@github.com>

On Mon, 29 Aug 2022 20:13:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more refactoring.

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

> 893:                 if (standardName != null) {
> 894:                     key = serviceName + "." + standardName +
> 895:                             (attrName != null ? ' ' + attrName : "");

I'd rather use `(' ' + attrName)`. Always not sure about operation precedence when `?:` is used.

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

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

From weijun at openjdk.org  Tue Sep  6 14:40:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:40:04 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
Message-ID: <MrbJqNhhwACR_divLD5TEgrf7qYsfsKcuvhabG3CcOU=.e69da658-cc14-47ed-b30f-b347c58b89c5@github.com>

On Mon, 29 Aug 2022 20:13:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more refactoring.

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

> 917:     }
> 918: 
> 919:     private static boolean isKnownComposite(String attr) {

You can move this method and the next method inside the `Criteria` class. In fact, I think the `isConstraintSatisfied` method can be combined into the `isCriterionSatisfied` method.

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

> 945:         if (isKnownComposite(attribute)) {
> 946:             value = value.toUpperCase();
> 947:             prop = prop.toUpperCase();

Use `toUpperCase(Locale.ENGLISH)`.

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

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

From weijun at openjdk.org  Tue Sep  6 14:42:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:42:46 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
Message-ID: <82Vq_JxEHTGCSfDDNAldQXJYN8A_9aHkwS1AGS8I8AY=.87411310-3092-45d7-ab7c-d7f9d0fcf216@github.com>

On Mon, 29 Aug 2022 20:13:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more refactoring.

test/jdk/java/security/Security/ProviderFiltering.java line 108:

> 106:         doit(key + ":" + valComp1, p);
> 107:         doit(key + ":" + valComp2, p);
> 108:         doit(key + ":" + valComp2CN);

Please provide a comment on `valComp2CN`.

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

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

From weijun at openjdk.org  Tue Sep  6 14:47:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 14:47:47 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
Message-ID: <JWIhU0fNDQyqaJhZG6CJpEN7ffhd1t42IY_st2ynep4=.b09be991-960e-409a-9a5a-23f901ff93b7@github.com>

On Mon, 29 Aug 2022 20:13:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more refactoring.

test/jdk/java/security/Security/ProviderFiltering.java line 145:

> 143:         doit(filters, pName);
> 144: 
> 145:         // should find no proviser now that TestProv is removed

Typo, `s/proviser/provider/`.

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

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

From mullan at openjdk.org  Tue Sep  6 17:09:54 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Sep 2022 17:09:54 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
Message-ID: <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>

On Fri, 2 Sep 2022 18:48:32 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291509
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   white space

reviewed up to certpath dir.

src/java.base/share/classes/sun/security/provider/AbstractDrbg.java line 81:

> 79:      * does <em>not</em> need to compare it to {@link #reseedInterval}.
> 80:      *
> 81:      * Volatile, will be used in a double-checked locking.

Also, remove "a" as it reads more correctly w/o it.

src/java.base/share/classes/sun/security/provider/ConfigFile.java line 167:

> 165:             // call in a doPrivileged
> 166:             //
> 167:             // we have already passed the Configuration.getInstance

s/we/We/

src/java.base/share/classes/sun/security/provider/ConfigFile.java line 168:

> 166:             //
> 167:             // we have already passed the Configuration.getInstance
> 168:             // security check.  also, this class is not freely accessible

s/also/Also/

src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1165:

> 1163:             }
> 1164: 
> 1165:             // everything matched -- the 2 objects are equal

remove the comment as it no longer applies

src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1180:

> 1178:                 // and then in a java string, it's escaped again
> 1179: 
> 1180:                 out.print(name.replaceAll("\\\\", "\\\\\\\\").replaceAll("\"", "\\\\\\\""));

Why does IJ say this is the same? This appears to replace backslash-quote with quote.

src/java.base/share/classes/sun/security/provider/SunEntries.java line 369:

> 367:      * Use a URI to access this File. Previous code used a URL
> 368:      * which is less strict on syntax. If we encounter a
> 369:      * URISyntaxException we make the best efforts for backwards

I'd change this to "a best effort". Same comment on l392.

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

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

From weijun at openjdk.org  Tue Sep  6 17:56:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 17:56:02 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
 <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
Message-ID: <EZbLfP8rYjO8HLYRbzXKshdQxWIR8aNG7LsIsK9bOlU=.c0ab2b88-3720-4fce-ab18-b693d77577c1@github.com>

On Tue, 6 Sep 2022 16:59:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   white space
>
> src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1180:
> 
>> 1178:                 // and then in a java string, it's escaped again
>> 1179: 
>> 1180:                 out.print(name.replaceAll("\\\\", "\\\\\\\\").replaceAll("\"", "\\\\\\\""));
> 
> Why does IJ say this is the same? This appears to replace backslash-quote with quote.

My understanding: In regex, there is no need to escape `"`, so `"` is the same as `"`.

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

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

From weijun at openjdk.org  Tue Sep  6 18:01:06 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 18:01:06 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <baUbARJPxEbhWhAoSzMhwAzPRKrqa2SafjwJXXXNkmc=.742b380c-431f-4646-803a-5b06ff86c1b4@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>
 <baUbARJPxEbhWhAoSzMhwAzPRKrqa2SafjwJXXXNkmc=.742b380c-431f-4646-803a-5b06ff86c1b4@github.com>
Message-ID: <q-tqukH76PJpfphTIkgAJrMdz-g7KuhUXjQl1cn9HpM=.e6fbb120-f3e3-4aba-9a9d-a903a1fa2cf4@github.com>

On Fri, 2 Sep 2022 01:02:26 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 183:
>> 
>>> 181:     private List<String> weakWarnings = new ArrayList<>();
>>> 182: 
>>> 183:     private Set<X509Certificate> trustedCerts = new HashSet<>();
>> 
>> Put all these `final`s in one group.
>
> If I do that, it will mess up existing groups, e.g. `// Warnings on weak algorithms etc`. I was able to move a few files around, but not many.

OK.

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

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

From weijun at openjdk.org  Tue Sep  6 18:01:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 18:01:07 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v4]
In-Reply-To: <kNv4pRxGXA2k2d_0tkgWwye9N7mmq2mYMC9WDMFVCOg=.bdff734e-b6e3-46b1-a795-d3c60094d25e@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <AHa_Jr1lksX7qKLwQID8dFC_QdujiL9vCBPmWlwohxE=.b4252d9e-e6fa-4acb-bd85-d283626f55aa@github.com>
 <neFzTnRn-DbJcGlg81It-9AryMGMi1CCM_mOHj1yiFU=.64e0aae3-7ae2-4a50-923b-fc4ac50905db@github.com>
 <kNv4pRxGXA2k2d_0tkgWwye9N7mmq2mYMC9WDMFVCOg=.bdff734e-b6e3-46b1-a795-d3c60094d25e@github.com>
Message-ID: <n4sK1TIlm9yRcRxGkN50ltLikq9v6sIN3eTGz_fxx0I=.d0aa5784-71e6-425b-b838-e95f5ecae270@github.com>

On Fri, 2 Sep 2022 04:16:04 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 3534:
>> 
>>> 3532:             Object[] source = {alias};
>>> 3533:             if (otherKeyPass != null) {
>>> 3534:                 System.err.println(form.format(source));
>> 
>> You can move the line above out as well. It's also the same.
>
> I can't factor them out because one is `println` and the other is `print`.

OK

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

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

From wetmore at openjdk.org  Tue Sep  6 19:09:13 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 6 Sep 2022 19:09:13 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
Message-ID: <xFC5dnUKZVOadZ3QJMR0orlGoUHNvY-JRzxnwHASy9o=.53580ff5-8866-40dd-a764-1152098c6d81@github.com>

On Mon, 5 Sep 2022 09:29:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch enables SignTwice test to complete faster on Windows machines.
> 
> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
> 
> The fix removes `java.security.egd` setting on Windows machines.
> 
> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

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

From wetmore at openjdk.org  Tue Sep  6 19:09:13 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 6 Sep 2022 19:09:13 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <DOOiP8zfZR-iTz3PlDJzs6OTImT0qvZJExjkEdI7N_I=.8ca50711-7a80-4084-91f3-92e3e9025b1e@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
 <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>
 <316-Xmp8hJW9ErsLfyvCgPRTbTwV0OcfySypJs7Immw=.3044a3e8-9300-43e1-b521-e2f1ba3bc739@github.com>
 <am53FvYWBK7HJaI0gPih1Qf8mZWm9rVbPZjKL1uZK3A=.35c3f12c-50a4-4b98-adcc-c7e4761efc49@github.com>
 <DOOiP8zfZR-iTz3PlDJzs6OTImT0qvZJExjkEdI7N_I=.8ca50711-7a80-4084-91f3-92e3e9025b1e@github.com>
Message-ID: <QgJ2c-rZliagkDn8ljneVufEyrdL4JWgy2X4-l2u0oU=.af1d9374-4973-432d-ada3-e0b63d37f448@github.com>

On Tue, 6 Sep 2022 09:21:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> SHA1PRNG, which is no longer the default on Linux.  But some apps are still asking for SHA1PRNG instead of using the default NativePRNG on Linux.
>
> FWIW, NativePRNGBlocking ignores java.security.egd and always uses `/dev/random`.
> 
> I'd rather not clean up all references to EGD here. Filed [JDK-8293412](https://bugs.openjdk.org/browse/JDK-8293412) as a follow up.

So IIUC, for this PR you're only going to tweak so that egd is not set in Windows, and then JDK-8293412 will address this comment and other instances throughout the base?

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

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

From djelinski at openjdk.org  Tue Sep  6 20:07:47 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 6 Sep 2022 20:07:47 GMT
Subject: RFR: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <QgJ2c-rZliagkDn8ljneVufEyrdL4JWgy2X4-l2u0oU=.af1d9374-4973-432d-ada3-e0b63d37f448@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
 <NOxWeUhQa-luWTekfUo1jiN3Qs1mBGI6qutdXVi19hU=.352b0731-e3e7-47bd-acd1-8dd1229ffb55@github.com>
 <316-Xmp8hJW9ErsLfyvCgPRTbTwV0OcfySypJs7Immw=.3044a3e8-9300-43e1-b521-e2f1ba3bc739@github.com>
 <am53FvYWBK7HJaI0gPih1Qf8mZWm9rVbPZjKL1uZK3A=.35c3f12c-50a4-4b98-adcc-c7e4761efc49@github.com>
 <DOOiP8zfZR-iTz3PlDJzs6OTImT0qvZJExjkEdI7N_I=.8ca50711-7a80-4084-91f3-92e3e9025b1e@github.com>
 <QgJ2c-rZliagkDn8ljneVufEyrdL4JWgy2X4-l2u0oU=.af1d9374-4973-432d-ada3-e0b63d37f448@github.com>
Message-ID: <5vJCvSqw50v2BIcjCiTwrwHz00AmNStOnXJZm2_odyM=.67561bfd-acd2-4e37-bbba-49e870863aec@github.com>

On Tue, 6 Sep 2022 19:05:40 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> FWIW, NativePRNGBlocking ignores java.security.egd and always uses `/dev/random`.
>> 
>> I'd rather not clean up all references to EGD here. Filed [JDK-8293412](https://bugs.openjdk.org/browse/JDK-8293412) as a follow up.
>
> So IIUC, for this PR you're only going to tweak so that egd is not set in Windows, and then JDK-8293412 will address this comment and other instances throughout the base?

Yes, that's the plan.

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

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

From valeriep at openjdk.org  Tue Sep  6 20:28:40 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 20:28:40 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
Message-ID: <TiSVTWfHRqWx-4WQ53ihIV9GnuDS5OOfxMgtCm-fo7k=.33d66b8b-00d7-4da3-b896-6db306a3fc4d@github.com>

On Thu, 1 Sep 2022 17:28:40 GMT, zzambers <duke at openjdk.org> wrote:

> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
> 
> **Exception:**
> 
> javax.net.ssl.SSLException: Internal error: close session with active objects
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.security.ProviderException: Internal error: close session with active objects
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
> 	... 4 more
> 
> 
> **Reproducibility:**
> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
> 
> **Problem:**
> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also whe
 n counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
> 
> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
> 
> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
> 
> There is race condition here. Consider following scenario:
> 
> // Thread T1 runs:
> Session.removeObject() // [4]
> createdObjects.decrementAndGet() // returns zero
> 
> // Thread T2 steps in (operating on the same session instance):
> Session.addObject() // increases "createdObjects" counter [2]
> SessionManager.releaseSession(session) // releases session to objSessions pool
> 
> // Thread T1 continues:
> SessionManager.demoteObjSession(this) // [6]
> objSessions.remove(session) // returns true
> opSessions.release(session)  // puts session (with objects!) to opSessions pool
> // if opSessions is already full, close of session with objects is attempted throwing Exception..
> 
> 
> **Fix:**
> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
> 
> **Testing:**
> jdk_security tests passed for me locally with this change.
> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
> 
> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195

Thanks for the suggested fix. I share your opinion about the potential race condition regarding demoting object session. Will take a look.

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

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

From mullan at openjdk.org  Tue Sep  6 20:38:59 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Sep 2022 20:38:59 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <EZbLfP8rYjO8HLYRbzXKshdQxWIR8aNG7LsIsK9bOlU=.c0ab2b88-3720-4fce-ab18-b693d77577c1@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
 <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
 <EZbLfP8rYjO8HLYRbzXKshdQxWIR8aNG7LsIsK9bOlU=.c0ab2b88-3720-4fce-ab18-b693d77577c1@github.com>
Message-ID: <ORcn2IiD1-GH5uscfCOwBNgqeUmSQGN8TPPoUQJ82gs=.87739a13-37c5-4725-b345-ff014d353ff1@github.com>

On Tue, 6 Sep 2022 17:53:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1180:
>> 
>>> 1178:                 // and then in a java string, it's escaped again
>>> 1179: 
>>> 1180:                 out.print(name.replaceAll("\\\\", "\\\\\\\\").replaceAll("\"", "\\\\\\\""));
>> 
>> Why does IJ say this is the same? This appears to replace backslash-quote with quote.
>
> My understanding: In regex, there is no need to escape `"`, so `"` is the same as `"`.

Ok,but the regex is `"\\""`, so shouldn't it keep the double-backslash at the beginning (`\`)?, i.e.:

`...replaceAll("\"", "\\\\\\""));`

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

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

From valeriep at openjdk.org  Tue Sep  6 21:06:54 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 21:06:54 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
Message-ID: <wXaKtLwbOWpqHPirBktwRJml_GQTyPCzNoj-CQF6vbM=.566be99c-beaf-4084-bfdf-a0f312ef1403@github.com>

On Thu, 1 Sep 2022 17:28:40 GMT, zzambers <duke at openjdk.org> wrote:

> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
> 
> **Exception:**
> 
> javax.net.ssl.SSLException: Internal error: close session with active objects
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.security.ProviderException: Internal error: close session with active objects
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
> 	... 4 more
> 
> 
> **Reproducibility:**
> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
> 
> **Problem:**
> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also whe
 n counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
> 
> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
> 
> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
> 
> There is race condition here. Consider following scenario:
> 
> // Thread T1 runs:
> Session.removeObject() // [4]
> createdObjects.decrementAndGet() // returns zero
> 
> // Thread T2 steps in (operating on the same session instance):
> Session.addObject() // increases "createdObjects" counter [2]
> SessionManager.releaseSession(session) // releases session to objSessions pool
> 
> // Thread T1 continues:
> SessionManager.demoteObjSession(this) // [6]
> objSessions.remove(session) // returns true
> opSessions.release(session)  // puts session (with objects!) to opSessions pool
> // if opSessions is already full, close of session with objects is attempted throwing Exception..
> 
> 
> **Fix:**
> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
> 
> **Testing:**
> jdk_security tests passed for me locally with this change.
> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
> 
> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java line 210:

> 208:             return;
> 209:         }
> 210:         releaseSession(session);

With the described race condition, have you tried fixing it by adding a if-condition check before doing line 204-210, i.e. if (!session.hasObjects()) { .... }?

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

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

From mullan at openjdk.org  Tue Sep  6 21:19:09 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Sep 2022 21:19:09 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
Message-ID: <CZo1-uvdrzdEn1upFJflwozXPqo6giKQTbiGFShWOug=.9da9f770-38fb-4845-821f-9ce17f9fb613@github.com>

On Fri, 2 Sep 2022 18:48:32 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291509
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   white space

some more comments ... mostly minor stuff.

src/java.base/share/classes/sun/security/provider/certpath/BuildStep.java line 245:

> 243:             out = out + vertex.moreToString();
> 244:             break;
> 245:             default:

align this with the "case" statements.

src/java.base/share/classes/sun/security/provider/certpath/Builder.java line 62:

> 60:     /**
> 61:      * Flag indicating whether support for the caIssuers field of the
> 62:      * Authority Information Access extension shall be enabled. Currently,

I think it reads better w/o the comma.

src/java.base/share/classes/sun/security/provider/certpath/CertId.java line 226:

> 224:                 "\nissuerKeyHash: \n" +
> 225:                 encoder.encode(issuerKeyHash) +
> 226:                 "\n" + certSerialNumber.toString();

I believe this creates more `String` objects whereas the previous code used a mutable `StringBuilder` to build up the `String` first. Not sure this code is better, even though this is probably not a commonly called method.

src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 337:

> 335:         if (pointCrlIssuers != null) {
> 336:             if (idpExt == null ||
> 337:                     idpExt.get (IssuingDistributionPointExtension.INDIRECT_CRL)

Nit, remove space after `get`.

src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 338:

> 336:             if (idpExt == null ||
> 337:                     idpExt.get (IssuingDistributionPointExtension.INDIRECT_CRL)
> 338:                     == (Boolean.FALSE)) {

Don't need the parens around `Boolean.FALSE` now.

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

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

From weijun at openjdk.org  Tue Sep  6 22:01:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Sep 2022 22:01:53 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <ORcn2IiD1-GH5uscfCOwBNgqeUmSQGN8TPPoUQJ82gs=.87739a13-37c5-4725-b345-ff014d353ff1@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
 <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
 <EZbLfP8rYjO8HLYRbzXKshdQxWIR8aNG7LsIsK9bOlU=.c0ab2b88-3720-4fce-ab18-b693d77577c1@github.com>
 <ORcn2IiD1-GH5uscfCOwBNgqeUmSQGN8TPPoUQJ82gs=.87739a13-37c5-4725-b345-ff014d353ff1@github.com>
Message-ID: <FKkDHdqelgl7RVHEzSWA4yUGR_8I-vKMfObPI-T1Tfs=.178ee7cf-171c-4bd1-b0ca-4c2d02ba5444@github.com>

On Tue, 6 Sep 2022 20:36:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> My understanding: In regex, there is no need to escape `"`, so `"` is the same as `"`.
>
> Ok,but the regex is `"\\""`, so shouldn't it keep the double-backslash at the beginning (`\`)?, i.e.:
> 
> `...replaceAll("\"", "\\\\\\""));`

The regex `"` is enough, so as a Java string it is `"""`.

Before this code change, we thought the regex should be `"` (not wrong, just wasteful), and we wrote it as `"\\""` in Java.

The replacement string is another thing and the quotation mark is also not special there, but IJ has not given any suggestion.

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

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

From duke at openjdk.org  Tue Sep  6 22:20:42 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 6 Sep 2022 22:20:42 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <wXaKtLwbOWpqHPirBktwRJml_GQTyPCzNoj-CQF6vbM=.566be99c-beaf-4084-bfdf-a0f312ef1403@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
 <wXaKtLwbOWpqHPirBktwRJml_GQTyPCzNoj-CQF6vbM=.566be99c-beaf-4084-bfdf-a0f312ef1403@github.com>
Message-ID: <f6w6TwxQ_CwmTTEqFLNZ9FdnvNmcX77mTAY0l0WVxuA=.ccb969f4-e30c-4f98-bfc3-25397de10e1e@github.com>

On Tue, 6 Sep 2022 21:02:50 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
>> 
>> **Exception:**
>> 
>> javax.net.ssl.SSLException: Internal error: close session with active objects
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
>> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
>> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.security.ProviderException: Internal error: close session with active objects
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
>> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
>> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
>> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
>> 	... 4 more
>> 
>> 
>> **Reproducibility:**
>> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
>> 
>> **Problem:**
>> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also wh
 en counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
>> 
>> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
>> 
>> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
>> 
>> There is race condition here. Consider following scenario:
>> 
>> // Thread T1 runs:
>> Session.removeObject() // [4]
>> createdObjects.decrementAndGet() // returns zero
>> 
>> // Thread T2 steps in (operating on the same session instance):
>> Session.addObject() // increases "createdObjects" counter [2]
>> SessionManager.releaseSession(session) // releases session to objSessions pool
>> 
>> // Thread T1 continues:
>> SessionManager.demoteObjSession(this) // [6]
>> objSessions.remove(session) // returns true
>> opSessions.release(session)  // puts session (with objects!) to opSessions pool
>> // if opSessions is already full, close of session with objects is attempted throwing Exception..
>> 
>> 
>> **Fix:**
>> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
>> 
>> **Testing:**
>> jdk_security tests passed for me locally with this change.
>> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
>> 
>> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
>> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
>> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
>> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
>> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
>> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java line 210:
> 
>> 208:             return;
>> 209:         }
>> 210:         releaseSession(session);
> 
> With the described race condition, have you tried fixing it by adding a if-condition check before doing line 204-210, i.e. if (!session.hasObjects()) { .... }?

I am afraid putting check before line 204 would not solve the issue (just lowered it's likelihood). Problem is, that operation consisting of check for objects on a session and then removing it from objSessions pool is not atomic. Session still could be obtained from objSessions pool by other thread after session.hasObjects() was called, object added to it and released back to objSessions pool before objSessions.remove(session) is called. I think this check for objects can only be trusted after session was successfully removed from objSessions (that is, session was in objSessions pool (no tread "holds" it) and was removed).

Actually whole call of demoteObjSession method is already behind one check for zero objects (but that check cannot be trusted), and needs to be redone after objSessions.remove(session),  because of problem described higher . See:
https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L100

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

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

From mpowers at openjdk.org  Tue Sep  6 22:42:07 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 6 Sep 2022 22:42:07 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
 <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
Message-ID: <tbpOYjq28kxS2S-KA3qkuOaqbdasr0awFf1dlC3ZT4E=.a7ab2752-312f-48d6-8912-88d7445ba33e@github.com>

On Tue, 6 Sep 2022 16:24:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   white space
>
> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java line 81:
> 
>> 79:      * does <em>not</em> need to compare it to {@link #reseedInterval}.
>> 80:      *
>> 81:      * Volatile, will be used in a double-checked locking.
> 
> Also, remove "a" as it reads more correctly w/o it.

Fixed.

> src/java.base/share/classes/sun/security/provider/ConfigFile.java line 167:
> 
>> 165:             // call in a doPrivileged
>> 166:             //
>> 167:             // we have already passed the Configuration.getInstance
> 
> s/we/We/

Fixed.

> src/java.base/share/classes/sun/security/provider/ConfigFile.java line 168:
> 
>> 166:             //
>> 167:             // we have already passed the Configuration.getInstance
>> 168:             // security check.  also, this class is not freely accessible
> 
> s/also/Also/

Fixed.

> src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1165:
> 
>> 1163:             }
>> 1164: 
>> 1165:             // everything matched -- the 2 objects are equal
> 
> remove the comment as it no longer applies

Fixed.

> src/java.base/share/classes/sun/security/provider/SunEntries.java line 369:
> 
>> 367:      * Use a URI to access this File. Previous code used a URL
>> 368:      * which is less strict on syntax. If we encounter a
>> 369:      * URISyntaxException we make the best efforts for backwards
> 
> I'd change this to "a best effort". Same comment on l392.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/BuildStep.java line 245:
> 
>> 243:             out = out + vertex.moreToString();
>> 244:             break;
>> 245:             default:
> 
> align this with the "case" statements.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/Builder.java line 62:
> 
>> 60:     /**
>> 61:      * Flag indicating whether support for the caIssuers field of the
>> 62:      * Authority Information Access extension shall be enabled. Currently,
> 
> I think it reads better w/o the comma.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/CertId.java line 226:
> 
>> 224:                 "\nissuerKeyHash: \n" +
>> 225:                 encoder.encode(issuerKeyHash) +
>> 226:                 "\n" + certSerialNumber.toString();
> 
> I believe this creates more `String` objects whereas the previous code used a mutable `StringBuilder` to build up the `String` first. Not sure this code is better, even though this is probably not a commonly called method.

If the new code requires more work (CPU and memory) then maybe it is not a good idea. I'll try to find out more about this method before I revert the change.

> src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 337:
> 
>> 335:         if (pointCrlIssuers != null) {
>> 336:             if (idpExt == null ||
>> 337:                     idpExt.get (IssuingDistributionPointExtension.INDIRECT_CRL)
> 
> Nit, remove space after `get`.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 338:
> 
>> 336:             if (idpExt == null ||
>> 337:                     idpExt.get (IssuingDistributionPointExtension.INDIRECT_CRL)
>> 338:                     == (Boolean.FALSE)) {
> 
> Don't need the parens around `Boolean.FALSE` now.

Fixed.

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

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

From valeriep at openjdk.org  Tue Sep  6 22:47:47 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 22:47:47 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
Message-ID: <flZ_mMW0JY_nZcZ509GDQ-j572VO5O6EuueYvKNoEUc=.cdd308b4-c451-42a2-b823-4b043095af97@github.com>

On Thu, 1 Sep 2022 17:28:40 GMT, zzambers <duke at openjdk.org> wrote:

> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
> 
> **Exception:**
> 
> javax.net.ssl.SSLException: Internal error: close session with active objects
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.security.ProviderException: Internal error: close session with active objects
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
> 	... 4 more
> 
> 
> **Reproducibility:**
> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
> 
> **Problem:**
> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also whe
 n counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
> 
> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
> 
> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
> 
> There is race condition here. Consider following scenario:
> 
> // Thread T1 runs:
> Session.removeObject() // [4]
> createdObjects.decrementAndGet() // returns zero
> 
> // Thread T2 steps in (operating on the same session instance):
> Session.addObject() // increases "createdObjects" counter [2]
> SessionManager.releaseSession(session) // releases session to objSessions pool
> 
> // Thread T1 continues:
> SessionManager.demoteObjSession(this) // [6]
> objSessions.remove(session) // returns true
> opSessions.release(session)  // puts session (with objects!) to opSessions pool
> // if opSessions is already full, close of session with objects is attempted throwing Exception..
> 
> 
> **Fix:**
> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
> 
> **Testing:**
> jdk_security tests passed for me locally with this change.
> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
> 
> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.org  Tue Sep  6 22:47:49 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 22:47:49 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <f6w6TwxQ_CwmTTEqFLNZ9FdnvNmcX77mTAY0l0WVxuA=.ccb969f4-e30c-4f98-bfc3-25397de10e1e@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
 <wXaKtLwbOWpqHPirBktwRJml_GQTyPCzNoj-CQF6vbM=.566be99c-beaf-4084-bfdf-a0f312ef1403@github.com>
 <f6w6TwxQ_CwmTTEqFLNZ9FdnvNmcX77mTAY0l0WVxuA=.ccb969f4-e30c-4f98-bfc3-25397de10e1e@github.com>
Message-ID: <lvUBZQeiBddlQEF24abP53hQkVn7Xx3jv1ud2BjLE6Y=.03f3013e-c56a-468b-9a5c-e35655202f6b@github.com>

On Tue, 6 Sep 2022 22:16:57 GMT, zzambers <duke at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java line 210:
>> 
>>> 208:             return;
>>> 209:         }
>>> 210:         releaseSession(session);
>> 
>> With the described race condition, have you tried fixing it by adding a if-condition check before doing line 204-210, i.e. if (!session.hasObjects()) { .... }?
>
> I am afraid putting check before line 204 would not solve the issue (just lowered it's likelihood). Problem is, that operation consisting of check for objects on a session and then removing it from objSessions pool is not atomic. Session still could be obtained from objSessions pool by other thread after session.hasObjects() was called, object added to it and released back to objSessions pool before objSessions.remove(session) is called. I think this check for objects can only be trusted after session was successfully removed from objSessions (that is, session was in objSessions pool (no tread "holds" it) and was removed).
> 
> Actually whole call of demoteObjSession method is already behind one check for zero objects (but that check cannot be trusted), and needs to be redone after objSessions.remove(session),  because of problem described higher . See:
> https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L100

I am aware of the zero objects check in the reference above. 
I am fine with the proposed fix then. Perhaps add a comment to this releaseSession() call to warn about this race condition.

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

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

From duke at openjdk.org  Tue Sep  6 22:53:54 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 6 Sep 2022 22:53:54 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <TiSVTWfHRqWx-4WQ53ihIV9GnuDS5OOfxMgtCm-fo7k=.33d66b8b-00d7-4da3-b896-6db306a3fc4d@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
 <TiSVTWfHRqWx-4WQ53ihIV9GnuDS5OOfxMgtCm-fo7k=.33d66b8b-00d7-4da3-b896-6db306a3fc4d@github.com>
Message-ID: <H4pMAI2LRVJdaYoOKHRF6twUldUnFX9c4E-jyCWxlv4=.345cfb6d-6f6f-4d61-ae73-1fbdd5eb1526@github.com>

On Tue, 6 Sep 2022 20:25:13 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
>> 
>> **Exception:**
>> 
>> javax.net.ssl.SSLException: Internal error: close session with active objects
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
>> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
>> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.security.ProviderException: Internal error: close session with active objects
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
>> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
>> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
>> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
>> 	... 4 more
>> 
>> 
>> **Reproducibility:**
>> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
>> 
>> **Problem:**
>> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also wh
 en counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
>> 
>> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
>> 
>> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
>> 
>> There is race condition here. Consider following scenario:
>> 
>> // Thread T1 runs:
>> Session.removeObject() // [4]
>> createdObjects.decrementAndGet() // returns zero
>> 
>> // Thread T2 steps in (operating on the same session instance):
>> Session.addObject() // increases "createdObjects" counter [2]
>> SessionManager.releaseSession(session) // releases session to objSessions pool
>> 
>> // Thread T1 continues:
>> SessionManager.demoteObjSession(this) // [6]
>> objSessions.remove(session) // returns true
>> opSessions.release(session)  // puts session (with objects!) to opSessions pool
>> // if opSessions is already full, close of session with objects is attempted throwing Exception..
>> 
>> 
>> **Fix:**
>> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
>> 
>> **Testing:**
>> jdk_security tests passed for me locally with this change.
>> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
>> 
>> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
>> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
>> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
>> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
>> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
>> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195
>
> Thanks for the suggested fix. I share your opinion about the potential race condition regarding demoting object session. Will take a look.

@valeriepeng, Thank you for your review

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

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

From valeriep at openjdk.org  Tue Sep  6 23:25:51 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 23:25:51 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
Message-ID: <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>

On Tue, 6 Sep 2022 14:10:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Both may be null as their javadoc didn't state explicitly what is returned.
>> This is existing code and it returns null upon empty keySet which I keep the same behavior. 
>> Perhaps for consistency sake, it should also check for the empty keySet condition and return allProviders.
>
> Sorry, I re-read and maybe the original check is better. If both `keySet` and `allProviders` are empty, then empty is returned. According to the spec, it should be null.
> 
> I still don't think either of them can be null, but adding the `isEmpty` check is probably wrong.

Well, it depends on how you interpret an empty filter map. If an empty table is specified, I'd think it means no criteria is set and all providers can be returned as the comment above suggested.
As this is a corner case, I am ok with reverting the isEmpty() check to keep the same behavior as before. However, I don't get which part of spec states about returning null for this case?

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

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

From valeriep at openjdk.org  Tue Sep  6 23:25:55 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 23:25:55 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <GiXZ021GWrGphL4PVH-ShkhyyoT4LzOnGlACEYM2mZQ=.a23ebd45-0253-46f0-8894-1869c0ac9521@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
 <GiXZ021GWrGphL4PVH-ShkhyyoT4LzOnGlACEYM2mZQ=.a23ebd45-0253-46f0-8894-1869c0ac9521@github.com>
Message-ID: <YnDdg8Tpvf8tmSMusUeNMuArHJH6j7GgNlusWSLK7gM=.a22792fc-1f5d-491e-bb2b-5a7b84923a7a@github.com>

On Tue, 6 Sep 2022 14:16:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more refactoring.
>
> src/java.base/share/classes/java/security/Security.java line 613:
> 
>> 611:         // For each selection criterion, remove providers
>> 612:         // which don't satisfy the criterion from the candidate set.
>> 613:         Iterator<Map.Entry<String, String>> iter = entries.iterator();
> 
> `for (var e : entries)` is simpler.
> 
> Inside the loop, you can also directly return `null` is it's empty. Then there is no need to check for `isEmpty` again outside.

Yup, very good idea. I will apply it. Thanks!

> src/java.base/share/classes/java/security/Security.java line 824:
> 
>> 822:         private String algName;
>> 823:         private String attrName = null;
>> 824:         private String attrValue;
> 
> Make these `final`.

Sure~

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

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

From valeriep at openjdk.org  Tue Sep  6 23:41:46 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Sep 2022 23:41:46 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <5iw0bxqsKeBzSBFrz9b_xaPm1GIg5E3k7vsjklUgGu0=.a7bcbb0a-5d44-46a1-b1c1-e2687d2941dd@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
 <5iw0bxqsKeBzSBFrz9b_xaPm1GIg5E3k7vsjklUgGu0=.a7bcbb0a-5d44-46a1-b1c1-e2687d2941dd@github.com>
Message-ID: <ARfbbM5Q2XEizietqFqBz7YNrYER-AlevUpB2hTDzBY=.3afbe57c-b2aa-47ed-b61e-edba06baa569@github.com>

On Tue, 6 Sep 2022 14:24:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more refactoring.
>
> src/java.base/share/classes/java/security/Security.java line 861:
> 
>> 859:             // check required values
>> 860:             if (serviceName.isEmpty() || algName.isEmpty() ||
>> 861:                     (!attrValue.isEmpty() && attrName.isEmpty())) {
> 
> Can we move the `attrName.isEmpty()` check inside the `else` block above? I find it easier to understand.

Sure, makes sense.

> src/java.base/share/classes/java/security/Security.java line 865:
> 
>> 863:             }
>> 864:         }
>> 865:         void apply(LinkedList<Provider> candidates) {
> 
> `candidates.removeIf(p -> !isCriterionSatisfied(p));`

Ok.

> src/java.base/share/classes/java/security/Security.java line 895:
> 
>> 893:                 if (standardName != null) {
>> 894:                     key = serviceName + "." + standardName +
>> 895:                             (attrName != null ? ' ' + attrName : "");
> 
> I'd rather use `(' ' + attrName)`. Always not sure about operation precedence when `?:` is used.

Ok.

> src/java.base/share/classes/java/security/Security.java line 947:
> 
>> 945:         if (isKnownComposite(attribute)) {
>> 946:             value = value.toUpperCase();
>> 947:             prop = prop.toUpperCase();
> 
> Use `toUpperCase(Locale.ENGLISH)`.

Sure~

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

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

From mpowers at openjdk.org  Wed Sep  7 00:00:00 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 7 Sep 2022 00:00:00 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <tbpOYjq28kxS2S-KA3qkuOaqbdasr0awFf1dlC3ZT4E=.a7ab2752-312f-48d6-8912-88d7445ba33e@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
 <iCvaW9XPJmzjiuQHahvD7Tv1BjRWpt6LIBxmRzX3UPM=.dbdb1723-a77b-4b10-b312-2a590e236ee9@github.com>
 <tbpOYjq28kxS2S-KA3qkuOaqbdasr0awFf1dlC3ZT4E=.a7ab2752-312f-48d6-8912-88d7445ba33e@github.com>
Message-ID: <ObN42LNo3nOj6hkVubVUpkMzzxe6l9RXoCXB_gPDm4g=.d3a184db-507b-472d-9dc5-73f85ccb6fd5@github.com>

On Tue, 6 Sep 2022 22:37:21 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/CertId.java line 226:
>> 
>>> 224:                 "\nissuerKeyHash: \n" +
>>> 225:                 encoder.encode(issuerKeyHash) +
>>> 226:                 "\n" + certSerialNumber.toString();
>> 
>> I believe this creates more `String` objects whereas the previous code used a mutable `StringBuilder` to build up the `String` first. Not sure this code is better, even though this is probably not a commonly called method.
>
> If the new code requires more work (CPU and memory) then maybe it is not a good idea. I'll try to find out more about this method before I revert the change.

Under the hood, the java compiler uses `StringBuilder` so the new code is okay. I looked at the byte code.

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

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

From duke at openjdk.org  Wed Sep  7 00:18:00 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 7 Sep 2022 00:18:00 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager [v2]
In-Reply-To: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
Message-ID: <jwT7hrTyO_e56ZqfFSYOJ7ms7lDpB0cm8q-lGoF4_68=.32c08a87-c263-4119-a1f1-a691de64a416@github.com>

> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
> 
> **Exception:**
> 
> javax.net.ssl.SSLException: Internal error: close session with active objects
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.security.ProviderException: Internal error: close session with active objects
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
> 	... 4 more
> 
> 
> **Reproducibility:**
> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
> 
> **Problem:**
> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also whe
 n counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
> 
> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
> 
> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
> 
> There is race condition here. Consider following scenario:
> 
> // Thread T1 runs:
> Session.removeObject() // [4]
> createdObjects.decrementAndGet() // returns zero
> 
> // Thread T2 steps in (operating on the same session instance):
> Session.addObject() // increases "createdObjects" counter [2]
> SessionManager.releaseSession(session) // releases session to objSessions pool
> 
> // Thread T1 continues:
> SessionManager.demoteObjSession(this) // [6]
> objSessions.remove(session) // returns true
> opSessions.release(session)  // puts session (with objects!) to opSessions pool
> // if opSessions is already full, close of session with objects is attempted throwing Exception..
> 
> 
> **Fix:**
> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
> 
> **Testing:**
> jdk_security tests passed for me locally with this change.
> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
> 
> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195

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

  Added comment, updated copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10125/files
  - new: https://git.openjdk.org/jdk/pull/10125/files/713f6176..cf493189

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

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

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

From valeriep at openjdk.org  Wed Sep  7 00:30:44 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 00:30:44 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <MrbJqNhhwACR_divLD5TEgrf7qYsfsKcuvhabG3CcOU=.e69da658-cc14-47ed-b30f-b347c58b89c5@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
 <MrbJqNhhwACR_divLD5TEgrf7qYsfsKcuvhabG3CcOU=.e69da658-cc14-47ed-b30f-b347c58b89c5@github.com>
Message-ID: <0_xp5Nn9yZd2Yis5Njl8BCUDyabUSCNIcZ8Fo8Mnvao=.c256c26a-2dab-4cb3-999b-51a7d8232dd4@github.com>

On Tue, 6 Sep 2022 14:36:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more refactoring.
>
> src/java.base/share/classes/java/security/Security.java line 919:
> 
>> 917:     }
>> 918: 
>> 919:     private static boolean isKnownComposite(String attr) {
> 
> You can move this method and the next method inside the `Criteria` class. In fact, I think the `isConstraintSatisfied` method can be combined into the `isCriterionSatisfied` method.

Yes, good idea.

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

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

From valeriep at openjdk.org  Wed Sep  7 00:50:41 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 00:50:41 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v5]
In-Reply-To: <82Vq_JxEHTGCSfDDNAldQXJYN8A_9aHkwS1AGS8I8AY=.87411310-3092-45d7-ab7c-d7f9d0fcf216@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <vGtTkx966hL2UTzy5DSltSGT0gfSDxtx4pREJ7gweY0=.795241ff-35e3-48a8-a508-575a3b6f0565@github.com>
 <82Vq_JxEHTGCSfDDNAldQXJYN8A_9aHkwS1AGS8I8AY=.87411310-3092-45d7-ab7c-d7f9d0fcf216@github.com>
Message-ID: <ju9BhIc47VXh0BwQexLtdN0BVP1jsa8jefM6t6g1hRk=.a408cd28-f545-4583-960c-9d2328eeefb0@github.com>

On Tue, 6 Sep 2022 14:40:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more refactoring.
>
> test/jdk/java/security/Security/ProviderFiltering.java line 108:
> 
>> 106:         doit(key + ":" + valComp1, p);
>> 107:         doit(key + ":" + valComp2, p);
>> 108:         doit(key + ":" + valComp2CN);
> 
> Please provide a comment on `valComp2CN`.

Ok.

> test/jdk/java/security/Security/ProviderFiltering.java line 145:
> 
>> 143:         doit(filters, pName);
>> 144: 
>> 145:         // should find no proviser now that TestProv is removed
> 
> Typo, `s/proviser/provider/`.

Will fix, thanks~

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

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

From weijun at openjdk.org  Wed Sep  7 01:53:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 01:53:43 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
 <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
Message-ID: <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>

On Tue, 6 Sep 2022 23:17:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Sorry, I re-read and maybe the original check is better. If both `keySet` and `allProviders` are empty, then empty is returned. According to the spec, it should be null.
>> 
>> I still don't think either of them can be null, but adding the `isEmpty` check is probably wrong.
>
> Well, it depends on how you interpret an empty filter map. If an empty table is specified, I'd think it means no criteria is set and all providers can be returned as the comment above suggested.
> As this is a corner case, I am ok with reverting the isEmpty() check to keep the same behavior as before. However, I don't get which part of spec states about returning null for this case?

The spec for this method:

     * @return all the installed providers that satisfy the selection
     * criteria, or {@code null} if no such providers have been installed.

My understanding is that you should not return an empty array.

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

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

From xuelei at openjdk.org  Wed Sep  7 01:56:42 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Sep 2022 01:56:42 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v2]
In-Reply-To: <CpFplI9BTIvRwyqb8hNxy3OF0zVbPU0H23w5AsulOhQ=.f37ca9fb-4747-42ff-bad3-e185ffde932e@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <CpFplI9BTIvRwyqb8hNxy3OF0zVbPU0H23w5AsulOhQ=.f37ca9fb-4747-42ff-bad3-e185ffde932e@github.com>
Message-ID: <k_KuFptwHCGbXhw8FWzXR9nThyXolm47mbkBWkE8_Mw=.761c7c39-fbb4-405a-ae10-0dd3223b49a2@github.com>

On Tue, 9 Aug 2022 15:30:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan 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
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Ping ...

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

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

From djelinski at openjdk.org  Wed Sep  7 05:29:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Sep 2022 05:29:07 GMT
Subject: Integrated: 8293326:
 jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
In-Reply-To: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
References: <33oOqZONiY4_yjFmx1exlPHxuZf75HRKapOX9gC8QPM=.48319976-7687-4af2-a0c4-11634256861f@github.com>
Message-ID: <gHMxGyM0HV_Mj0Hc3rk1ASJcPAOwWF8ReUgvbEkaA-k=.99e258fa-330e-4acb-adb1-1cf4f4b761fb@github.com>

On Mon, 5 Sep 2022 09:29:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch enables SignTwice test to complete faster on Windows machines.
> 
> The test starts `keytool` and `jarsigner` a number of times, passing `-J-Djava.security.egd=file:/dev/./urandom` to the started process, presumably to avoid blocking on VMs with insufficient entropy. This works fine on machines where `/dev/./urandom` is actually present. On Windows it makes the JVM use `ThreadedSeedGenerator`, which is very slow compared to the other options.
> 
> The fix removes `java.security.egd` setting on Windows machines.
> 
> Alternatively we could change the egd to use `file:/dev/urandom` (without the `/./` part); this also fixes the Windows problem. Is the `/./` part still needed? If I understand correctly, it was a workaround for some JDK7 bug.

This pull request has now been integrated.

Changeset: 205f992e
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/205f992e9ecf9f83bb052ee2e2a32e3f532c5ac9
Stats:     13 lines in 1 file changed: 10 ins; 3 del; 0 mod

8293326: jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows

Reviewed-by: weijun, wetmore

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

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

From aturbanov at openjdk.org  Wed Sep  7 06:14:44 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 7 Sep 2022 06:14:44 GMT
Subject: Integrated: 8293197: Avoid double racy reads from non-volatile fields
 in SharedSecrets
In-Reply-To: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
References: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
Message-ID: <EAVsuCQZ0PkCmui5ResmrkoFwiQ_Wj0YDMYVbk16D6M=.ca9b66b0-cd05-4d6e-b62a-0396aeba6c20@github.com>

On Tue, 30 Aug 2022 07:10:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

This pull request has now been integrated.

Changeset: 2259e427
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2259e427a53440da948315db2272396294036051
Stats:     16 lines in 1 file changed: 8 ins; 0 del; 8 mod

8293197: Avoid double racy reads from non-volatile fields in SharedSecrets

Reviewed-by: alanb

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

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

From mpowers at openjdk.org  Wed Sep  7 14:40:23 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 7 Sep 2022 14:40:23 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v7]
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>

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

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

  comments from Max and Sean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9972/files
  - new: https://git.openjdk.org/jdk/pull/9972/files/366b957a..800b100f

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

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

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

From valeriep at openjdk.org  Wed Sep  7 16:43:54 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 16:43:54 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager [v2]
In-Reply-To: <jwT7hrTyO_e56ZqfFSYOJ7ms7lDpB0cm8q-lGoF4_68=.32c08a87-c263-4119-a1f1-a691de64a416@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
 <jwT7hrTyO_e56ZqfFSYOJ7ms7lDpB0cm8q-lGoF4_68=.32c08a87-c263-4119-a1f1-a691de64a416@github.com>
Message-ID: <LI0LJOO6Vr084N8K-WPC0o_Cdr0JS-gprDXU_hgI-aM=.451b11e2-d2f9-4c81-8618-ba28b1092b4d@github.com>

On Wed, 7 Sep 2022 00:18:00 GMT, zzambers <duke at openjdk.org> wrote:

>> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
>> 
>> **Exception:**
>> 
>> javax.net.ssl.SSLException: Internal error: close session with active objects
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
>> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
>> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.security.ProviderException: Internal error: close session with active objects
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
>> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
>> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
>> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
>> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
>> 	... 4 more
>> 
>> 
>> **Reproducibility:**
>> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
>> 
>> **Problem:**
>> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also wh
 en counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
>> 
>> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
>> 
>> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
>> 
>> There is race condition here. Consider following scenario:
>> 
>> // Thread T1 runs:
>> Session.removeObject() // [4]
>> createdObjects.decrementAndGet() // returns zero
>> 
>> // Thread T2 steps in (operating on the same session instance):
>> Session.addObject() // increases "createdObjects" counter [2]
>> SessionManager.releaseSession(session) // releases session to objSessions pool
>> 
>> // Thread T1 continues:
>> SessionManager.demoteObjSession(this) // [6]
>> objSessions.remove(session) // returns true
>> opSessions.release(session)  // puts session (with objects!) to opSessions pool
>> // if opSessions is already full, close of session with objects is attempted throwing Exception..
>> 
>> 
>> **Fix:**
>> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
>> 
>> **Testing:**
>> jdk_security tests passed for me locally with this change.
>> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
>> 
>> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
>> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
>> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
>> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
>> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
>> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment, updated copyright date

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.org  Wed Sep  7 16:43:54 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 16:43:54 GMT
Subject: RFR: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <H4pMAI2LRVJdaYoOKHRF6twUldUnFX9c4E-jyCWxlv4=.345cfb6d-6f6f-4d61-ae73-1fbdd5eb1526@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
 <TiSVTWfHRqWx-4WQ53ihIV9GnuDS5OOfxMgtCm-fo7k=.33d66b8b-00d7-4da3-b896-6db306a3fc4d@github.com>
 <H4pMAI2LRVJdaYoOKHRF6twUldUnFX9c4E-jyCWxlv4=.345cfb6d-6f6f-4d61-ae73-1fbdd5eb1526@github.com>
Message-ID: <Y8aee-fzhAyEhBde9wKw7KZ8sPM6cu1sm-ViVDPhgQ0=.96b960e5-ea4e-4a4c-a5e3-9a0aeabf03d7@github.com>

On Tue, 6 Sep 2022 22:50:47 GMT, zzambers <duke at openjdk.org> wrote:

>> Thanks for the suggested fix. I share your opinion about the potential race condition regarding demoting object session. Will take a look.
>
> @valeriepeng, Thank you for your review

> @zzambers Your change (at version [713f617](https://github.com/openjdk/jdk/commit/713f61760d502890c67bcb44db17d2a33f3bb2fb)) is now ready to be sponsored by a Committer.

The bot says that you need to do "/integrate" command again before I can do "/sponsor".

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

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

From weijun at openjdk.org  Wed Sep  7 16:56:15 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 16:56:15 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint
Message-ID: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>

Provide a new test for an old bug fix.

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

Commit messages:
 - new test

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

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

From valeriep at openjdk.org  Wed Sep  7 17:03:47 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 17:03:47 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
 <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
 <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>
Message-ID: <ZvYdlsPCrJB4gxz4bDccpKfykkwZwLec0MhCzvVCmgQ=.9325383d-586a-4826-b9d2-82e2b6cdd48f@github.com>

On Wed, 7 Sep 2022 01:49:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Well, it depends on how you interpret an empty filter map. If an empty table is specified, I'd think it means no criteria is set and all providers can be returned as the comment above suggested.
>> As this is a corner case, I am ok with reverting the isEmpty() check to keep the same behavior as before. However, I don't get which part of spec states about returning null for this case?
>
> The spec for this method:
> 
>      * @return all the installed providers that satisfy the selection
>      * criteria, or {@code null} if no such providers have been installed.
> 
> My understanding is that you should not return an empty array.

I see that null is returned instead of an empty Provider array. When an empty filter map is specified, I interpret it as no criteria is set and thus it should return all providers (which is often non-empty). The condition on line 599 is OR, but the line on 600 returns the "allProvider" value which may or may not be null. Anyway, I start to get the feeling that we may not be talking about the same stuff...

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

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

From weijun at openjdk.org  Wed Sep  7 17:27:45 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 17:27:45 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <ZvYdlsPCrJB4gxz4bDccpKfykkwZwLec0MhCzvVCmgQ=.9325383d-586a-4826-b9d2-82e2b6cdd48f@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
 <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
 <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>
 <ZvYdlsPCrJB4gxz4bDccpKfykkwZwLec0MhCzvVCmgQ=.9325383d-586a-4826-b9d2-82e2b6cdd48f@github.com>
Message-ID: <0kIJUTRiuqrrnBSD2uJ0eHikgAU94AoycIjFcaiWQ-0=.80e2af9b-2f79-4e89-9280-7b51b8fc8b4c@github.com>

On Wed, 7 Sep 2022 17:01:32 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> The spec for this method:
>> 
>>      * @return all the installed providers that satisfy the selection
>>      * criteria, or {@code null} if no such providers have been installed.
>> 
>> My understanding is that you should not return an empty array.
>
> I see that null is returned instead of an empty Provider array. When an empty filter map is specified, I interpret it as no criteria is set and thus it should return all providers (which is often non-empty). The condition on line 599 is OR, but the line on 600 returns the "allProvider" value which may or may not be null. Anyway, I start to get the feeling that we may not be talking about the same stuff...

Maybe. But, while all providers is usually non-empty, it could be if a user remove all of them. I understand this is a just corner case.

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

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

From valeriep at openjdk.org  Wed Sep  7 17:47:42 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 17:47:42 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <0kIJUTRiuqrrnBSD2uJ0eHikgAU94AoycIjFcaiWQ-0=.80e2af9b-2f79-4e89-9280-7b51b8fc8b4c@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
 <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
 <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>
 <ZvYdlsPCrJB4gxz4bDccpKfykkwZwLec0MhCzvVCmgQ=.9325383d-586a-4826-b9d2-82e2b6cdd48f@github.com>
 <0kIJUTRiuqrrnBSD2uJ0eHikgAU94AoycIjFcaiWQ-0=.80e2af9b-2f79-4e89-9280-7b51b8fc8b4c@github.com>
Message-ID: <-0YJt-4R5uKrkcQvkyITtc2fPefRozm70GT-YmWc73w=.e34db6e2-34d5-47d7-a04c-fe277b7aa97c@github.com>

On Wed, 7 Sep 2022 17:23:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I see that null is returned instead of an empty Provider array. When an empty filter map is specified, I interpret it as no criteria is set and thus it should return all providers (which is often non-empty). The condition on line 599 is OR, but the line on 600 returns the "allProvider" value which may or may not be null. Anyway, I start to get the feeling that we may not be talking about the same stuff...
>
> Maybe. But, while all providers is usually non-empty, it could be if a user remove all of them. I understand this is a just corner case.

So, is it about empty all Providers or empty filter map? I only added the check on latter. Are you suggesting to add a check for the former?

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

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

From weijun at openjdk.org  Wed Sep  7 18:45:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 18:45:42 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <-0YJt-4R5uKrkcQvkyITtc2fPefRozm70GT-YmWc73w=.e34db6e2-34d5-47d7-a04c-fe277b7aa97c@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
 <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
 <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>
 <ZvYdlsPCrJB4gxz4bDccpKfykkwZwLec0MhCzvVCmgQ=.9325383d-586a-4826-b9d2-82e2b6cdd48f@github.com>
 <0kIJUTRiuqrrnBSD2uJ0eHikgAU94AoycIjFcaiWQ-0=.80e2af9b-2f79-4e89-9280-7b51b8fc8b4c@github.com>
 <-0YJt-4R5uKrkcQvkyITtc2fPefRozm70GT-YmWc73w=.e34db6e2-34d5-47d7-a04c-fe277b7aa97c@github.com>
Message-ID: <d-25guxp4eKePAlPv97TGsicikep24ARKaGbGbPRTpk=.e63e45d8-a63d-4c23-a400-653d37024805@github.com>

On Wed, 7 Sep 2022 17:43:52 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Maybe. But, while all providers is usually non-empty, it could be if a user remove all of them. I understand this is a just corner case.
>
> So, is it about empty all Providers or empty filter map? I only added the check on latter. Are you suggesting to add a check for the former?

Maybe the former. I just don't want this method to return an empty array, whatever the reason is.

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

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

From mullan at openjdk.org  Wed Sep  7 19:00:50 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 Sep 2022 19:00:50 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint
In-Reply-To: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
Message-ID: <YSYFc80t4CKQuCWWuD08MKldx19-vckPuDjpsA03x18=.7f86fbce-2de6-4b0f-9f49-f660fd9920a6@github.com>

On Wed, 7 Sep 2022 16:49:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Provide a new test for an old bug fix.

test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java line 48:

> 46: 
> 47:     public static void main(String[] args) throws Exception {
> 48:         Security.setProperty("jdk.certpath.disabledAlgorithms", "");

This doesn't seem necessary as none of the algs used are disabled. Plus, if you remove this I think you don't need to run it in othervm.

test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java line 72:

> 70:         System.out.println("Calling trustmanager...");
> 71: 
> 72:         tm.checkServerTrusted(chain, "RSA");

Maybe add a comment that any authType works because the EE cert allows all key usages (has no KU ext).

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

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

From weijun at openjdk.org  Wed Sep  7 19:59:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 19:59:53 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint
In-Reply-To: <YSYFc80t4CKQuCWWuD08MKldx19-vckPuDjpsA03x18=.7f86fbce-2de6-4b0f-9f49-f660fd9920a6@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
 <YSYFc80t4CKQuCWWuD08MKldx19-vckPuDjpsA03x18=.7f86fbce-2de6-4b0f-9f49-f660fd9920a6@github.com>
Message-ID: <MPXK7oZOFmuFCpvkceGMop8eJyaUp1XpRFVfwiN0FrQ=.1e07938a-1cb8-40b8-867f-ee225ad77cd3@github.com>

On Wed, 7 Sep 2022 18:42:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Provide a new test for an old bug fix.
>
> test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java line 48:
> 
>> 46: 
>> 47:     public static void main(String[] args) throws Exception {
>> 48:         Security.setProperty("jdk.certpath.disabledAlgorithms", "");
> 
> This doesn't seem necessary as none of the algs used are disabled. Plus, if you remove this I think you don't need to run it in othervm.

Ah, I see. It must be because legacy algorithms were hardcoded in the certs. Now that certificates are generated on the fly they are always using strong algorithms.

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

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

From weijun at openjdk.org  Wed Sep  7 20:03:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 20:03:40 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint
In-Reply-To: <YSYFc80t4CKQuCWWuD08MKldx19-vckPuDjpsA03x18=.7f86fbce-2de6-4b0f-9f49-f660fd9920a6@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
 <YSYFc80t4CKQuCWWuD08MKldx19-vckPuDjpsA03x18=.7f86fbce-2de6-4b0f-9f49-f660fd9920a6@github.com>
Message-ID: <zuVMmhwKHCZom46oQDHAs4PdOQ14TixYqz9ZIMB76Jo=.c590b270-ca96-445a-9855-22ce0cc0ffb3@github.com>

On Wed, 7 Sep 2022 18:56:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Provide a new test for an old bug fix.
>
> test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java line 72:
> 
>> 70:         System.out.println("Calling trustmanager...");
>> 71: 
>> 72:         tm.checkServerTrusted(chain, "RSA");
> 
> Maybe add a comment that any authType works because the EE cert allows all key usages (has no KU ext).

I'll change the key to RSA.

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

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

From weijun at openjdk.org  Wed Sep  7 20:06:01 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Sep 2022 20:06:01 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint [v2]
In-Reply-To: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
Message-ID: <tDL-ecYlxGUK3nNU6Cb2tthWOoNiEVee-sn5vWWT9RU=.d4b4f141-64bb-4424-b2d9-47fec4ad4022@github.com>

> Provide a new test for an old bug fix.

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

  use RSA key, no need to clear disabled alg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10203/files
  - new: https://git.openjdk.org/jdk/pull/10203/files/1b05148a..4624fb59

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

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

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

From duke at openjdk.org  Wed Sep  7 20:53:46 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 7 Sep 2022 20:53:46 GMT
Subject: Integrated: 8293232: Fix race condition in pkcs11 SessionManager
In-Reply-To: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
References: <Te-E1Cv7nbPlsRh9VLYqAv48CuLMvXF7KPmqssuQWlk=.ee632bc5-ff89-4219-b497-97453edd0747@github.com>
Message-ID: <dHlX1G_H4nYIyfr56M0gR86PMrbHSs4y-t_-3A4zEr4=.b84712f9-d59b-4fd5-8472-de5b4bd248d2@github.com>

On Thu, 1 Sep 2022 17:28:40 GMT, zzambers <duke at openjdk.org> wrote:

> There is a race condition in JDK's SessionManager, which can lead to random exceptions.
> 
> **Exception:**
> 
> javax.net.ssl.SSLException: Internal error: close session with active objects
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1707)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1080)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:971)
> 	at SSLSocketServer.serverLoop(SSLSocketServer.java:133)
> 	at SSLSocketServer$1.run(SSLSocketServer.java:75)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.security.ProviderException: Internal error: close session with active objects
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:127)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.close(Session.java:114)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.closeSession(SessionManager.java:237)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager$Pool.release(SessionManager.java:270)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionManager.demoteObjSession(SessionManager.java:210)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.Session.removeObject(Session.java:101)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.updateNativeKey(P11Key.java:1396)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.SessionKeyRef.removeNativeKey(P11Key.java:1377)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.NativeKeyHolder.releaseKeyID(P11Key.java:1329)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Key.releaseKeyID(P11Key.java:156)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.reset(P11AEADCipher.java:529)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.ensureInitialized(P11AEADCipher.java:436)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.implDoFinal(P11AEADCipher.java:732)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11AEADCipher.engineDoFinal(P11AEADCipher.java:624)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)
> 	at java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1659)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:260)
> 	at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:181)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1479)
> 	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
> 	... 4 more
> 
> 
> **Reproducibility:**
> I started getting this exception quite reliably on JDK17 on my machine with one particular test setup using ssl-tests testsuite. Unfortunately setup itself needed some RH specific patches and also ability to reproduce depends on other factors such number keys in keystore, machine where testing was performed... I tried a bit to create some reproducer, but I couldn't find a way to easily reproduce this issue :(
> 
> **Problem:**
> SunPKCS11 provider does session pooling. This is done in SessionManager [1] (one per SunPKCS11 provider). Released sessions are kept by SessionManager for a while, for reuse (in limited number). This however is a bit complicated as some sessions can own objects (e.g. keys). So there are actually 2 pools. One for sessions with objects ("objSessions") and one for sessions without objects ("opSessions"). This is because sessions without objects, which are not being used, can be safely closed (SessionManager only keeps around limited amount of these), while sessions with objects cannot be safely closed (until all objects are removed from them). Session manager has methods for getting Session for given purpose (object creation or just doing other operations), prioritizing appropriate pool. Each session has counter (called "createdObjects") to track how many objects it owns. When session is being returned to pool this counter is checked and session is placed to appropriate pool. Also whe
 n counter for some Session in "objSessions" pool reaches zero it is moved ("demoted") to "opSessions" pool.
> 
> And here comes complicated part. As far as I understand it, Session.addObject() [2] (which increases "createdObjects" counter) is always being called by thread "holding" session which owns the created object. (That is: thread gets a session, uses it to create an object and calls Session.addObject() on that session to increase the counter, before returning the session to pool. See e.g.: [3]) However this is not true for Session.removeObject() [4]. (That is: thread gets session, which is not necessary the same one owning object being removed, performs object removal, but then calls Session.removeObject() on session which owned that object. See e.g.: [5]) That is Session.removeObject() can be called on Session which is in "objSessions" pool or which is being used be other thread. (object removal can happen as result of releasing key, either explicitly or as result of GC etc..). 
> 
> And finally, there is a problem in code handling object removal from a session. Session.removeObject() [4] first checks if "createdObjects" counter reached zero. If so, it calls SessionManager.demoteObjSession(this) [6], which attempts to remove Session from objSessions pool, if session is successfully removed from there, meaning no other thread "holds" this session, session is put to opSessions pool, if not (meaning other thread "holds" it), method just returns, since that other thread puts this session to appropriate pool, when it is done with it by calling SessionManager.releaseSession(session).
> 
> There is race condition here. Consider following scenario:
> 
> // Thread T1 runs:
> Session.removeObject() // [4]
> createdObjects.decrementAndGet() // returns zero
> 
> // Thread T2 steps in (operating on the same session instance):
> Session.addObject() // increases "createdObjects" counter [2]
> SessionManager.releaseSession(session) // releases session to objSessions pool
> 
> // Thread T1 continues:
> SessionManager.demoteObjSession(this) // [6]
> objSessions.remove(session) // returns true
> opSessions.release(session)  // puts session (with objects!) to opSessions pool
> // if opSessions is already full, close of session with objects is attempted throwing Exception..
> 
> 
> **Fix:**
> SessionManager.demoteObjSession [6] method was changed, so that check for objects is done once again if session was successfully removed from "objSessions" pool (now that it is out of pool and other threads should not be adding objects to it). Based on this check session is either released to "opSessions" pool or returned to "objSessions" pool. This can be achieved by calling releaseSession(session) instead of opSessions.release(session).
> 
> **Testing:**
> jdk_security tests passed for me locally with this change.
> I have also tested this change on top of custom JDK17 build which allows scenario, where I can reproduce this issue. Problem got fixed.
> 
> [1] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java
> [2] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L93
> [3] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1339
> [4] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java#L98
> [5] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L1360
> [6] https://github.com/openjdk/jdk/blob/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java#L195

This pull request has now been integrated.

Changeset: 1e031e6a
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e031e6a5886fba3009d8e5fa62416fe15a901b6
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8293232: Fix race condition in pkcs11 SessionManager

Reviewed-by: valeriep

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

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

From valeriep at openjdk.org  Wed Sep  7 20:56:53 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 20:56:53 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v2]
In-Reply-To: <d-25guxp4eKePAlPv97TGsicikep24ARKaGbGbPRTpk=.e63e45d8-a63d-4c23-a400-653d37024805@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com>
 <tr0eNclGrHXdVyvG4_J6NTaW0fjgdqNZe28Se_M1TlM=.01adfdee-e3ea-47be-a86c-061f629cba46@github.com>
 <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com>
 <2untLt_BbgbDuMGC7B3_YDpcraMlFxJ4aDrhLO9dhAQ=.2337b367-7d9b-45f1-b003-3ef03c9153e8@github.com>
 <76ynublD6DHvO1wSkvKDlA16ANoXlhiwWVJIWNC8P9c=.43034088-79f6-4caa-9636-be9f599ea8ad@github.com>
 <rs73a1pn3qeyS_OXXiPHzWd0-2lC_SY_NaQUBCj-zvw=.3ddfb34a-0962-4632-ac8a-e186bb0f9af6@github.com>
 <ZvYdlsPCrJB4gxz4bDccpKfykkwZwLec0MhCzvVCmgQ=.9325383d-586a-4826-b9d2-82e2b6cdd48f@github.com>
 <0kIJUTRiuqrrnBSD2uJ0eHikgAU94AoycIjFcaiWQ-0=.80e2af9b-2f79-4e89-9280-7b51b8fc8b4c@github.com>
 <-0YJt-4R5uKrkcQvkyITtc2fPefRozm70GT-YmWc73w=.e34db6e2-34d5-47d7-a04c-fe277b7aa97c@github.com>
 <d-25guxp4eKePAlPv97TGsicikep24ARKaG
 bGbPRTpk=.e63e45d8-a63d-4c23-a400-653d37024805@github.com>
Message-ID: <cD2kNzITdvH8hwKz-ouABszl_QIhiKXsqKtbkgMos8g=.cea34ac5-ace3-4ceb-8e75-094717f4dac1@github.com>

On Wed, 7 Sep 2022 18:42:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> So, is it about empty all Providers or empty filter map? I only added the check on latter. Are you suggesting to add a check for the former?
>
> Maybe the former. I just don't want this method to return an empty array, whatever the reason is.

Then I will re-write the checks. The original code does not ensure null is returned when allProviders is empty.

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

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

From mullan at openjdk.org  Wed Sep  7 21:12:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 Sep 2022 21:12:43 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint [v2]
In-Reply-To: <tDL-ecYlxGUK3nNU6Cb2tthWOoNiEVee-sn5vWWT9RU=.d4b4f141-64bb-4424-b2d9-47fec4ad4022@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
 <tDL-ecYlxGUK3nNU6Cb2tthWOoNiEVee-sn5vWWT9RU=.d4b4f141-64bb-4424-b2d9-47fec4ad4022@github.com>
Message-ID: <9Oam79g1uvvKBgsS4s3aHsoSj5jcUp7qZj3qPEjEi-E=.b1514dbf-0540-4c60-b799-4d1c27ec52c2@github.com>

On Wed, 7 Sep 2022 20:06:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Provide a new test for an old bug fix.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use RSA key, no need to clear disabled alg

Marked as reviewed by mullan (Reviewer).

test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java line 27:

> 25: // SunJSSE does not support dynamic system properties, no way to re-use
> 26: // system properties in samevm/agentvm mode.
> 27: //

You can also remove this comment now.

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

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

From valeriep at openjdk.org  Wed Sep  7 23:38:53 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Sep 2022 23:38:53 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v6]
In-Reply-To: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
Message-ID: <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>

> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
> 
> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
> 
> Thanks in advance for review~

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

  More refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10008/files
  - new: https://git.openjdk.org/jdk/pull/10008/files/2ecc0e7e..be39047d

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

  Stats: 117 lines in 2 files changed: 25 ins; 38 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/10008.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10008/head:pull/10008

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

From weijun at openjdk.org  Thu Sep  8 01:39:58 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 01:39:58 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint [v3]
In-Reply-To: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
Message-ID: <5yDYaf_ZmAkZ3Ftjf38Xp4gc96iAKDW3h1xQTlHfc2U=.17e5a858-6fcc-4999-be20-6dd43850598f@github.com>

> Provide a new test for an old bug fix.

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

  remove comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10203/files
  - new: https://git.openjdk.org/jdk/pull/10203/files/4624fb59..ce915aad

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

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

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

From weijun at openjdk.org  Thu Sep  8 01:40:01 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 01:40:01 GMT
Subject: RFR: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint [v2]
In-Reply-To: <9Oam79g1uvvKBgsS4s3aHsoSj5jcUp7qZj3qPEjEi-E=.b1514dbf-0540-4c60-b799-4d1c27ec52c2@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
 <tDL-ecYlxGUK3nNU6Cb2tthWOoNiEVee-sn5vWWT9RU=.d4b4f141-64bb-4424-b2d9-47fec4ad4022@github.com>
 <9Oam79g1uvvKBgsS4s3aHsoSj5jcUp7qZj3qPEjEi-E=.b1514dbf-0540-4c60-b799-4d1c27ec52c2@github.com>
Message-ID: <4PeuSwcY6SsK0VaerpztrGV_M2A-j4tcXRMt_7wdacY=.a7c706f2-0f34-4a7f-a105-d2623ff5edac@github.com>

On Wed, 7 Sep 2022 21:08:11 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 RSA key, no need to clear disabled alg
>
> test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java line 27:
> 
>> 25: // SunJSSE does not support dynamic system properties, no way to re-use
>> 26: // system properties in samevm/agentvm mode.
>> 27: //
> 
> You can also remove this comment now.

Done.

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

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

From weijun at openjdk.org  Thu Sep  8 01:40:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 01:40:02 GMT
Subject: Integrated: 8293489: Accept CAs with BasicConstraints without
 pathLenConstraint
In-Reply-To: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
References: <l97mO1A8BvBONwngJs481-HfM07i_IQqEa2LZLtm3nU=.df472abd-56a7-47a1-8eea-840b7b98e6c7@github.com>
Message-ID: <X7t1exJCKYJGykkIKCl0ZQCCYA6sUrBGKJiXOD_hka8=.0af16841-6c06-492e-a33d-90b8419ffdf8@github.com>

On Wed, 7 Sep 2022 16:49:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Provide a new test for an old bug fix.

This pull request has now been integrated.

Changeset: 986b8341
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/986b834148f425aa21611814d162a8578b26b502
Stats:     73 lines in 1 file changed: 73 ins; 0 del; 0 mod

8293489: Accept CAs with BasicConstraints without pathLenConstraint

Reviewed-by: mullan

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

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

From weijun at openjdk.org  Thu Sep  8 14:34:06 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 14:34:06 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v6]
In-Reply-To: <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
Message-ID: <cuPbHrJtBX-rU08-AJMKSkdga1nJokTE0VcOAKS0L7A=.1ba7f238-7cf3-45d1-8d70-3ba026cb8067@github.com>

On Wed, 7 Sep 2022 23:38:53 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More refactoring

One problem. One suggestion.

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

> 608:             // return null if the selection criteria is empty; this is to match
> 609:             // earlier behavior
> 610:             return null;

Is this true? In the original code when `filter` is empty, `keySet` is also empty and `allProviders` will be returned.

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

> 871:         // whose value may be composite, i.e. multiple values separated by "|"
> 872:         private boolean isCompositeValue() {
> 873:             return (attrName != null &&

`attrName` is never null when this method is called.

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

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

From weijun at openjdk.org  Thu Sep  8 15:09:58 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 15:09:58 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v7]
In-Reply-To: <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
Message-ID: <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>

On Wed, 7 Sep 2022 14:40:23 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This is my last part of code review. Most trivial, but the one in `ssl/ECDHClientKeyExchange.java` might need some attention.

src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java line 289:

> 287:             }
> 288: 
> 289:             // Can't figure this out, bail.

Maybe we should instead check if `namedParams` is null on line 286 and avoid the NPE there.

src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 70:

> 68:     @SuppressWarnings({"unchecked", "rawtypes"})
> 69:     B_NULL("NULL", NULL_CIPHER, 0, 0, 0, 0, true, true,
> 70:             new Map.Entry[] {

It looks cleaner to me if `new Map.Entry[] {` is put at the end of the previous line. Otherwise, the indentation seems growing backwards. Same for line 80 and all below.

src/java.base/share/classes/sun/security/ssl/SSLExtensions.java line 307:

> 305:                                                     // extension_data length(2)
> 306:                 }
> 307:                 encodedLength += encoded.length + 4;

I think the two comment lines above should follow.

src/java.base/share/classes/sun/security/ssl/SSLHandshakeBinding.java line 2:

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

No change in this file?

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 587:

> 585:                 for (String string : strings) {
> 586:                     builder.append("      \"" + string + "\"");
> 587:                     if (!Objects.equals(string, strings[strings.length - 1])) {

The original usage looks weird. I'd rather use

                int len = strings.length;
                for (int i = 0; i < len; i++) {
                    String string = strings[i];
                    builder.append("      "" + string + """);
                    if (i != len - 1) {
                        builder.append(",");
                    }
                    builder.append("\n");
                }

src/java.base/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java line 86:

> 84:     @Override
> 85:     public Socket createSocket(String host, int port)
> 86:     throws IOException {

Join this with the previous line.

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

> 585:         boolean useUserCanceled = !isNegotiated &&
> 586:                 (handshakeContext != null) && !peerUserCanceled;
> 587:         // initial handshake

Move this comment line above a little.

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

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

From weijun at openjdk.org  Thu Sep  8 15:10:03 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 15:10:03 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
Message-ID: <ilIK9ePWa9T4n6psBYaYRh5Qqmd8qPc7AnIjvH1Ji14=.213f7dcd-06b0-45cb-8f6c-b20139b384c3@github.com>

On Fri, 2 Sep 2022 18:48:32 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291509
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   white space

src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 610:

> 608:             X509TrustManager tm = chc.sslContext.getX509TrustManager();
> 609: 
> 610:             // Find the key exchange algorithm used.

Not a native English speaker, but I find "find out" better.

src/java.base/share/classes/sun/security/ssl/DTLSRecord.java line 40:

> 38:      * The size of the header plus the max IV length
> 39:      */
> 40:     int    headerPlusMaxIVSize =

Maybe join the next line? Same below.

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

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

From weijun at openjdk.org  Thu Sep  8 15:21:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 15:21:46 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <US-UVF82zLqb9HEtYblLbKm9YACgdg0poar7kx_-QFo=.873a0d62-641c-4221-ab46-0e78f9b734c7@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
 <-A4R9l6pS4wdGmqVSoBOzEQRI4IDTER2Y2ddd4HXU_Q=.de5f64ba-ebfb-4a4a-b864-042deae17f58@github.com>
 <pWpva2q5Z4y754gjDLovBVE4RdqS2Ri3lx6wh0pWy_4=.62f22f9f-1102-4800-a1be-050652e00706@github.com>
 <US-UVF82zLqb9HEtYblLbKm9YACgdg0poar7kx_-QFo=.873a0d62-641c-4221-ab46-0e78f9b734c7@github.com>
Message-ID: <ZyrKsJqFzK4C1r9oJ8ePKJq2ZoAh1YcbgNcCEgecIN4=.15797c60-4ea5-4caa-813e-139ad1efbf46@github.com>

On Fri, 2 Sep 2022 08:51:04 GMT, Bernd <duke at openjdk.org> wrote:

>> I want this to be spec from now on. If we want to backport this to older releases, then the paragraph above can be @implNote.
>
> I agree that this should be in the API spec.
> 
> Does the ?return null? case for invalid encodings need to mention any exceptions triggered by the actual key instantion to make clear the Spec is only a container?

I plan to swallow all exceptions while parsing the ASN.1 encoding and not mentioning any type name. Also, I only intend to read until the algorithm field, no key material is read and certainly no `Key` object is instantiated.

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

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

From weijun at openjdk.org  Thu Sep  8 15:36:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 15:36:43 GMT
Subject: RFR: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method [v2]
In-Reply-To: <pZsYPPK2evRHsewWcBhoakHcCFqGJVAtxMsNHtIGX2E=.677fd75a-9f53-47db-9c89-5f9f7e20a5a6@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
 <LgA8k53s9KTEYxR9hvFqI6sRkD9CZ4gYMD7Pqv80Fxc=.fd5cc3dc-0632-4aaf-8e06-800b28753d7e@github.com>
 <pZsYPPK2evRHsewWcBhoakHcCFqGJVAtxMsNHtIGX2E=.677fd75a-9f53-47db-9c89-5f9f7e20a5a6@github.com>
Message-ID: <WxK-WJNlju3AmbESNR64RptLAgYPpmarHR7fVUvQBz8=.d43212e7-54e3-4ffa-9c3b-e1afdd385d4b@github.com>

On Fri, 2 Sep 2022 09:11:56 GMT, Bernd <duke at openjdk.org> wrote:

> Should this also be aligned with EncryptedPrivateKeyInfo?

`EncryptedPrivateKeyInfo` claims it might return a different more-standard name other than the one provided in a constructor, We don't intend to do it here because of compatibility issue.

> See also my PBES2 discussion on secure-dev last month.

Oh, haven't read it. It's not about algorithm name, right? PBES2 could be a little awkward because in Java the name itself (Ex: `PBEWithHmacSHA1AndAES_128`) maps to a combination of OID ("PBES2") and parameters. I've tried to make this transparent with JDK-8286428.

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

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

From valeriep at openjdk.org  Thu Sep  8 19:36:09 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 8 Sep 2022 19:36:09 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v6]
In-Reply-To: <cuPbHrJtBX-rU08-AJMKSkdga1nJokTE0VcOAKS0L7A=.1ba7f238-7cf3-45d1-8d70-3ba026cb8067@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
 <cuPbHrJtBX-rU08-AJMKSkdga1nJokTE0VcOAKS0L7A=.1ba7f238-7cf3-45d1-8d70-3ba026cb8067@github.com>
Message-ID: <qoqp8uZS5vA9QDl9okcrTDELDN6EFEn_cGmuJIXX_vk=.2b7501ce-aeac-451f-b022-04322dbd8e1b@github.com>

On Thu, 8 Sep 2022 14:25:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More refactoring
>
> src/java.base/share/classes/java/security/Security.java line 610:
> 
>> 608:             // return null if the selection criteria is empty; this is to match
>> 609:             // earlier behavior
>> 610:             return null;
> 
> Is this true? In the original code when `filter` is empty, `keySet` is also empty and `allProviders` will be returned.

Yes, if you look at the original impl (not my earlier changes), the result set is populated inside the loop which iterate over the keys. So, for empty key set, the result set is empty and null will end up being returned. It does not match my expectation. However, I tried it against a clean workspace.

> src/java.base/share/classes/java/security/Security.java line 873:
> 
>> 871:         // whose value may be composite, i.e. multiple values separated by "|"
>> 872:         private boolean isCompositeValue() {
>> 873:             return (attrName != null &&
> 
> `attrName` is never null when this method is called.

Yes, but that's depending on the current calling pattern. Now that it's inside Criteria class where attrName may be null (for Service.AlgName type of criteria), it should be checked for completeness.

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

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

From weijun at openjdk.org  Thu Sep  8 22:02:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 22:02:10 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v6]
In-Reply-To: <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
Message-ID: <DP3oTSah8WVBjXMdcylZ0XiICsiwqhVPVBDt7Mpfokc=.80a9d0f1-7dcd-42b8-8310-beaeb92878f8@github.com>

On Wed, 7 Sep 2022 23:38:53 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More refactoring

Marked as reviewed by weijun (Reviewer).

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

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

From weijun at openjdk.org  Thu Sep  8 22:02:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Sep 2022 22:02:11 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v6]
In-Reply-To: <qoqp8uZS5vA9QDl9okcrTDELDN6EFEn_cGmuJIXX_vk=.2b7501ce-aeac-451f-b022-04322dbd8e1b@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
 <cuPbHrJtBX-rU08-AJMKSkdga1nJokTE0VcOAKS0L7A=.1ba7f238-7cf3-45d1-8d70-3ba026cb8067@github.com>
 <qoqp8uZS5vA9QDl9okcrTDELDN6EFEn_cGmuJIXX_vk=.2b7501ce-aeac-451f-b022-04322dbd8e1b@github.com>
Message-ID: <Se4htgjw3pUlthL11Zu4GgN7ytEhv8L_CuFm50yFHy8=.0691a8e4-62cf-4b9e-b20f-582cab4e98ea@github.com>

On Thu, 8 Sep 2022 19:30:57 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 610:
>> 
>>> 608:             // return null if the selection criteria is empty; this is to match
>>> 609:             // earlier behavior
>>> 610:             return null;
>> 
>> Is this true? In the original code when `filter` is empty, `keySet` is also empty and `allProviders` will be returned.
>
> Yes, if you look at the original impl (not my earlier changes), the result set is populated inside the loop which iterate over the keys. So, for empty key set, the result set is empty and null will end up being returned. It does not match my expectation. However, I tried it against a clean workspace.

Yes, you're right.

>> src/java.base/share/classes/java/security/Security.java line 873:
>> 
>>> 871:         // whose value may be composite, i.e. multiple values separated by "|"
>>> 872:         private boolean isCompositeValue() {
>>> 873:             return (attrName != null &&
>> 
>> `attrName` is never null when this method is called.
>
> Yes, but that's depending on the current calling pattern. Now that it's inside Criteria class where attrName may be null (for Service.AlgName type of criteria), it should be checked for completeness.

OK.

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

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

From valeriep at openjdk.org  Thu Sep  8 22:57:27 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 8 Sep 2022 22:57:27 GMT
Subject: RFR: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions [v6]
In-Reply-To: <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
 <nBtsfIODOvDrsf6cutCXBWQr0288EFvnIwi4aFzbucU=.6b688550-d35c-4a80-91e3-dd5c46cf9f23@github.com>
Message-ID: <A3_3JA5H80juagoIRhQr5KEmN_DcWLfbFHb79Fcg9cY=.ed5ee3df-71a1-44d9-8750-749f2459e58c@github.com>

On Wed, 7 Sep 2022 23:38:53 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
>> 
>> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
>> 
>> Thanks in advance for review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More refactoring

Thanks for the review and many helpful comments~

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

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

From valeriep at openjdk.org  Fri Sep  9 00:34:57 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 9 Sep 2022 00:34:57 GMT
Subject: Integrated: 6447816: Provider filtering (getProviders) is not working
 with OR'd conditions
In-Reply-To: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
References: <JDVjMiIeASWXjMSVlwjnx91rO_ycUATIlk5sf-ALH64=.411b44c8-1d0a-406e-9adc-3db73e7fa240@github.com>
Message-ID: <aF35VoalmaEb5peH3Bv4sq5wHazg_9WkYN534c88Jos=.1403e169-6e2f-4a18-a980-51fe478deb18@github.com>

On Wed, 24 Aug 2022 20:22:32 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these.
> 
> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817.
> 
> Thanks in advance for review~

This pull request has now been integrated.

Changeset: 812d805a
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/812d805a488597cb9ab6b375869bc6748fd7fa94
Stats:     408 lines in 2 files changed: 212 ins; 121 del; 75 mod

6447816: Provider filtering (getProviders) is not working with OR'd conditions

Reviewed-by: weijun

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

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

From mpowers at openjdk.org  Mon Sep 12 16:35:37 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 12 Sep 2022 16:35:37 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
Message-ID: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>

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

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

Commit messages:
 - first iteration

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

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

From weijun at openjdk.org  Mon Sep 12 16:35:38 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 12 Sep 2022 16:35:38 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <RQqOF1yKcQ8G_el3rfvrb3VXjUfBQ-9XDgn3q5ZWG5s=.78360b3a-8344-4cf1-a002-54aba2ec238a@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

Code change looks good to me. Since a `serialVersionUID` is already defined and `testing` is always false, removing it is not a compatibility issue.

However, now that the serialized form is modified (see https://download.java.net/java/early_access/jdk20/docs/api/serialized-form.html#javax.security.auth.PrivateCredentialPermission), I wonder if we need a small CSR.

Assign it a default value, `false`.

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

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

From mpowers at openjdk.org  Mon Sep 12 16:35:39 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 12 Sep 2022 16:35:39 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <CNPQ-Eo2S8tq4yhrWm03qAep9Ct-6JZXxkTvN6_IbM8=.d4d592c8-eb74-4682-a61d-3b3aed6fb5a3@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

What happens when deserialization encounters a missing field like `testing`? Does it ignore it?

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

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

From coffeys at openjdk.org  Tue Sep 13 15:08:11 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 13 Sep 2022 15:08:11 GMT
Subject: RFR: 8292297: Fix up loading of override java.security properties file
Message-ID: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>

Ensure that security properties are only overridden if the override security properties file exists. 
Refactored some of the code in Security class initialization also.
Extra test coverage for security properties file options.

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

Commit messages:
 - Merge branch 'master' into 8292297-securityConf
 - Correct URL syntax
 - fix early initization issue and expand testing
 - 8292297 initial commit

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

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

From xuelei at openjdk.org  Tue Sep 13 16:50:44 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 13 Sep 2022 16:50:44 GMT
Subject: RFR: 8292297: Fix up loading of override java.security properties
 file
In-Reply-To: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
References: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
Message-ID: <0fwPve8Ic02gt_DZzqNFNM0-vQ_ENfz_QnyWP0CGa_w=.7880d9dd-ba5b-41dd-b9ef-3fc3daad2465@github.com>

On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Ensure that security properties are only overridden if the override security properties file exists. 
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.

Is it a behavioral change that requires CSR approval?

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

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

From mpowers at openjdk.org  Tue Sep 13 17:18:11 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 13 Sep 2022 17:18:11 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v6]
In-Reply-To: <ilIK9ePWa9T4n6psBYaYRh5Qqmd8qPc7AnIjvH1Ji14=.213f7dcd-06b0-45cb-8f6c-b20139b384c3@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <DlNS5plKOHu4qoIT9LNmuRAFeYj_gVqw4_4vTLOZKqY=.26bdc161-f877-4d30-8195-cd67f21cf858@github.com>
 <ilIK9ePWa9T4n6psBYaYRh5Qqmd8qPc7AnIjvH1Ji14=.213f7dcd-06b0-45cb-8f6c-b20139b384c3@github.com>
Message-ID: <DtEGz6AhrwigK8lOMsvaa6ippcOyysl1BfTlVQG0fl0=.19958c51-201a-4d13-8804-12b5e423f416@github.com>

On Tue, 6 Sep 2022 22:48:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   white space
>
> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 610:
> 
>> 608:             X509TrustManager tm = chc.sslContext.getX509TrustManager();
>> 609: 
>> 610:             // Find the key exchange algorithm used.
> 
> Not a native English speaker, but I find "find out" better.

You are right. Use "find" for objects, e.g. "I have to find my car". Use "find out" for information, e.g. "Find out when the party starts".

> src/java.base/share/classes/sun/security/ssl/DTLSRecord.java line 40:
> 
>> 38:      * The size of the header plus the max IV length
>> 39:      */
>> 40:     int    headerPlusMaxIVSize =
> 
> Maybe join the next line? Same below.

Fixed.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:40 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
Message-ID: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>

Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.

It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2


Best,
Lance

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

Commit messages:
 - switch linkePlain to code tag
 - Addressed 3rd draft comments
 - Merge branch 'master' into JDK-8215788
 - Third draft of the class description
 - Minor update to the wording for signature entries
 - Inital draft to clarify Manifest access

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

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

From weijun at openjdk.org  Tue Sep 13 17:24:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 17:24:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/util/jar/JarInputStream.java line 38:

> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}
> 37:  * entry. The {@linkplain JarFile#MANIFEST_NAME Manifest} can be used to store
> 38:  * meta-information about the JAR file and its entries.

No need to linkplain twice.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:

> 60:  *         is the second jar entry
> 61:  *      </li>
> 62:  * </ul>

I wonder if it's necessary to duplicate these lines. How about something like "If ...., then getManifest() returns the manifest and the first call to getNextEntry() returns the entry after it".

src/java.base/share/classes/java/util/jar/JarInputStream.java line 74:

> 72:  *  {@linkplain  JarEntry#getCertificates()} may be called to obtain the certificates
> 73:  *  for this entry and {@linkplain JarEntry#getCodeSigners()} may be called to obtain
> 74:  *  the verified signers.

Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.

Also, you might want to mention:
1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
2. These two methods return null if the file is not signed or the signature is not parseable.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 75:

> 73:  *      </li>
> 74:  *      <li>
> 75:  *         All signature entries must immediately follow the {@code manifest}

We normally say "signature-related entries", which contains both the signature files (.SF) and the signature block files (.DSA/.RSA/.EC) files.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:45 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
Message-ID: <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>

On Tue, 30 Aug 2022 21:47:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:
> 
>> 60:  *         is the second jar entry
>> 61:  *      </li>
>> 62:  * </ul>
> 
> I wonder if it's necessary to duplicate these lines. How about something like "If ...., then getManifest() returns the manifest and the first call to getNextEntry() returns the entry after it".

The challenge I had with the wording is due to the fact that if "META-INF/" is the first entry in the Zip file, it will not be returned regardless of whether there is a manifest.  So open to suggestions.

> Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.
> 

Fixed
> Also, you might want to mention:
> 
>     1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
> 
Added a note
>     2. These two methods return null if the file is not signed or the signature is not parseable.
Given I link to the javadoc for these methods, this I hope is enough as my goal was not to replace the javadoc for the JarEntry methods.  If you feel the methods should be clarified, happy to work on that next

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 75:
> 
>> 73:  *      </li>
>> 74:  *      <li>
>> 75:  *         All signature entries must immediately follow the {@code manifest}
> 
> We normally say "signature-related entries", which contains both the signature files (.SF) and the signature block files (.DSA/.RSA/.EC) files.

Updated in the next push

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

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

From weijun at openjdk.org  Tue Sep 13 17:24:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 17:24:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
Message-ID: <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>

On Wed, 31 Aug 2022 18:31:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:
>> 
>>> 60:  *         is the second jar entry
>>> 61:  *      </li>
>>> 62:  * </ul>
>> 
>> I wonder if it's necessary to duplicate these lines. How about something like "If ...., then getManifest() returns the manifest and the first call to getNextEntry() returns the entry after it".
>
> The challenge I had with the wording is due to the fact that if "META-INF/" is the first entry in the Zip file, it will not be returned regardless of whether there is a manifest.  So open to suggestions.

That's right. But I think we care about the MANIFEST more. It's not that important whether META-INF is there.

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 74:
>> 
>>> 72:  *  {@linkplain  JarEntry#getCertificates()} may be called to obtain the certificates
>>> 73:  *  for this entry and {@linkplain JarEntry#getCodeSigners()} may be called to obtain
>>> 74:  *  the verified signers.
>> 
>> Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.
>> 
>> Also, you might want to mention:
>> 1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
>> 2. These two methods return null if the file is not signed or the signature is not parseable.
>
>> Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.
>> 
> 
> Fixed
>> Also, you might want to mention:
>> 
>>     1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
>> 
> Added a note
>>     2. These two methods return null if the file is not signed or the signature is not parseable.
> Given I link to the javadoc for these methods, this I hope is enough as my goal was not to replace the javadoc for the JarEntry methods.  If you feel the methods should be clarified, happy to work on that next

Fair enough.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:47 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
Message-ID: <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>

On Wed, 31 Aug 2022 19:13:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The challenge I had with the wording is due to the fact that if "META-INF/" is the first entry in the Zip file, it will not be returned regardless of whether there is a manifest.  So open to suggestions.
>
> That's right. But I think we care about the MANIFEST more. It's not that important whether META-INF is there.

True we do care more about the manifest, but was also trying to address the difference between ZipInputStream which will always return both entries regardless of location

We also have the case such where you the 1st entry in the jar is a normal file and the 2nd entry is the manifest.,  getManifest() will return null.

I guess I could say:

 _"getManifest will return the Manifest if it is the first entry or META-INF/ is  the first entry and the Manifest is the second entry within the Jar file. For all cases, getManifest will return null."

Is the above any better?

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

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

From weijun at openjdk.org  Tue Sep 13 17:24:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 17:24:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
Message-ID: <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>

On Thu, 1 Sep 2022 11:06:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> That's right. But I think we care about the MANIFEST more. It's not that important whether META-INF is there.
>
> True we do care more about the manifest, but was also trying to address the difference between ZipInputStream which will always return both entries regardless of location
> 
> We also have the case such where you the 1st entry in the jar is a normal file and the 2nd entry is the manifest.,  getManifest() will return null.
> 
> I guess I could say:
> 
>  _"getManifest will return the Manifest if it is the first entry or META-INF/ is  the first entry and the Manifest is the second entry within the Jar file. For all cases, getManifest will return null."
> 
> Is the above any better?

It's better. Do you need to explicitly say "For all other cases"?

My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:49 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:49 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
 <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
Message-ID: <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>

On Thu, 1 Sep 2022 17:27:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> It's better. Do you need to explicitly say "For all other cases"?
>> 
>> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.
>
>> It's better. Do you need to explicitly say "For all other cases"?
> 
> I thought it is worth being specific,  but happy to leave it out if you and others prefer
>> 
>> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.
> 
> I think the challenge is there is not an exact match to the behavior between `getManifest()` and `getNext[Jar]Entry()`.    We also have the case if the manifest is the first entry and META-INF/ is the 2nd or later entry, then  META-INF/ will be returned by `JarInputStream`.  ` ZipInputStream` will return all entries which differs from `JarInputStream` so thought it made sense to be specific but perhaps I am overthinking it.

I could do tweak further to say:

_`getManifest()` will return the Manifest if it is the first entry or META-INF/ is the first entry and the Manifest is the second entry within the Jar file.   When the Manifest is returned by `getManifest()`,  the `getNextEntry()` and `getNextJarEntry()` methods will not return the Manifest_

Is that more what you were thinking?

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:48 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:48 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
Message-ID: <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>

On Thu, 1 Sep 2022 13:53:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> It's better. Do you need to explicitly say "For all other cases"?

I thought it is worth being specific,  but happy to leave it out if you and others prefer
> 
> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.

I think the challenge is there is not an exact match to the behavior between `getManifest()` and `getNext[Jar]Entry()`.    We also have the case if the manifest is the first entry and META-INF/ is the 2nd or later entry, then  META-INF/ will be returned by `JarInputStream`.  ` ZipInputStream` will return all entries which differs from `JarInputStream` so thought it made sense to be specific but perhaps I am overthinking it.

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

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

From alanb at openjdk.org  Tue Sep 13 17:24:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 17:24:49 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
 <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
 <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>
Message-ID: <Q-0JnUgZm8McmL9RoBEzjddBq-L6sPP1pXyAVS_eoTo=.3bdeeb79-c0dd-4933-8b72-376a1195f1dc@github.com>

On Thu, 1 Sep 2022 17:56:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> It's better. Do you need to explicitly say "For all other cases"?
>> 
>> I thought it is worth being specific,  but happy to leave it out if you and others prefer
>>> 
>>> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.
>> 
>> I think the challenge is there is not an exact match to the behavior between `getManifest()` and `getNext[Jar]Entry()`.    We also have the case if the manifest is the first entry and META-INF/ is the 2nd or later entry, then  META-INF/ will be returned by `JarInputStream`.  ` ZipInputStream` will return all entries which differs from `JarInputStream` so thought it made sense to be specific but perhaps I am overthinking it.
>
> I could do tweak further to say:
> 
> _`getManifest()` will return the Manifest if it is the first entry or META-INF/ is the first entry and the Manifest is the second entry within the Jar file.   When the Manifest is returned by `getManifest()`,  the `getNextEntry()` and `getNextJarEntry()` methods will not return the Manifest_
> 
> Is that more what you were thinking?

I read the current draft and it makes we wonder if it would be simpler to just replace the class description with something like this:


 * The JarInputStream class is used to read the contents of a JAR file from
 * an input stream. It extends ZipInputStream with support for reading an optional
 * manifest named "META-INF/MANIFEST.MF" when it is found at as the first entry in
 * the stream. If the first entry in the stream is "META-INF/" then it is skipped,
 * in which case the manifest is found if it is the second entry in the stream.
 *
 * JarInputStream defines the getNextJarEntry() method to iterate through the
 * JAR file entries in the stream. The method reads the metadata for the next JAR
 * file entry in the stream and positions the input stream to read the entry's
 * file data. The first entry found by getNextJarEntry() (or getNextEntry())
 * will follow the manifest when the manifest is the first entry in the JAR
 * file (or the second entry when the first entry is "META-INF/").

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:50 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:50 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <Q-0JnUgZm8McmL9RoBEzjddBq-L6sPP1pXyAVS_eoTo=.3bdeeb79-c0dd-4933-8b72-376a1195f1dc@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
 <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
 <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>
 <Q-0JnUgZm8McmL9RoBEzjddBq-L6sPP1pXyAVS_eoTo=.3bdeeb79-c0dd-4933-8b72-376a1195f1dc@github.com>
Message-ID: <442Fu17tGdi8NaT6Xf78IPWFB2UOAAujeoOzFe0N00U=.3eece7e9-f1f6-4087-a6a7-18753f4483d0@github.com>

On Fri, 2 Sep 2022 14:50:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I could do tweak further to say:
>> 
>> _`getManifest()` will return the Manifest if it is the first entry or META-INF/ is the first entry and the Manifest is the second entry within the Jar file.   When the Manifest is returned by `getManifest()`,  the `getNextEntry()` and `getNextJarEntry()` methods will not return the Manifest_
>> 
>> Is that more what you were thinking?
>
> I read the current draft and it makes we wonder if it would be simpler to just replace the class description with something like this:
> 
> 
>  * The JarInputStream class is used to read the contents of a JAR file from
>  * an input stream. It extends ZipInputStream with support for reading an optional
>  * manifest named "META-INF/MANIFEST.MF" when it is found at as the first entry in
>  * the stream. If the first entry in the stream is "META-INF/" then it is skipped,
>  * in which case the manifest is found if it is the second entry in the stream.
>  *
>  * JarInputStream defines the getNextJarEntry() method to iterate through the
>  * JAR file entries in the stream. The method reads the metadata for the next JAR
>  * file entry in the stream and positions the input stream to read the entry's
>  * file data. The first entry found by getNextJarEntry() (or getNextEntry())
>  * will follow the manifest when the manifest is the first entry in the JAR
>  * file (or the second entry when the first entry is "META-INF/").

Thank you for the suggestions.  I just updated the the description leveraging your feedback.  Please let me know if this is better

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

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

From mullan at openjdk.org  Tue Sep 13 19:33:48 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 Sep 2022 19:33:48 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <wmShyWSIfM6hC-PWRPCnYs1E1xpp1kDLmJztJ7I4nic=.cf4f3b7c-eb17-430c-8ffd-dc5f4386f86d@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

I would write a test which serializes the data (before your change) and deserializes it after. There should be some regression tests that already do that.

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

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

From weijun at openjdk.org  Tue Sep 13 20:48:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 20:48:11 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Mostly good. Some small comments.

BTW, there are still a lot of `linkplain`. I'm not sure how javadoc are written for core-libs, but my experience on security-libs is that it's only used when the text is &mdash; er &mdash; plaintext that's neither a class name nor a method name.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:

> 34:  * The {@code JarInputStream} class, which extends {@linkplain ZipInputStream},
> 35:  * is used to read the contents of a JAR file from an input stream.
> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}

`Manifest` above is the same as the one below. If the one below is in fixed-width, so should be the one above.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 67:

> 65:  *      </li>
> 66:  *      <li>
> 67:  *         All signature-related entries must immediately follow the {@code Manifest}

No need to say `must`. This is is one of the requirements.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:

> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,
> 77:  * a {@linkplain SecurityException} will be thrown when an attempt is made to
> 78:  * read the entry.

Not sure if the the `an attempt` word is precise. The exception is only thrown when the last byte is read.

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

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

From lancea at openjdk.org  Tue Sep 13 21:05:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 21:05:41 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <HiFgQPD_YWDsr8c_GZqCY6UwQnkB4GrSPt7pABcv42c=.23b75077-667e-480e-8398-84e7fe39e044@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Max,

Thank you for your feedback.  See my responses below

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

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

From lancea at openjdk.org  Tue Sep 13 21:05:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 21:05:45 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
Message-ID: <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>

On Tue, 13 Sep 2022 20:39:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
> 
>> 34:  * The {@code JarInputStream} class, which extends {@linkplain ZipInputStream},
>> 35:  * is used to read the contents of a JAR file from an input stream.
>> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}
> 
> `Manifest` above is the same as the one below. If the one below is in fixed-width, so should be the one above.

Could you please clarify what you are suggesting.  I am using the  `@linkplain` to provide a means to see the actual Manifest name.   I am happy to tweak, just need (perhaps an example) of what you would like

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 67:
> 
>> 65:  *      </li>
>> 66:  *      <li>
>> 67:  *         All signature-related entries must immediately follow the {@code Manifest}
> 
> No need to say `must`. This is is one of the requirements.

addressed in the next update

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
> 
>> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,
>> 77:  * a {@linkplain SecurityException} will be thrown when an attempt is made to
>> 78:  * read the entry.
> 
> Not sure if the the `an attempt` word is precise. The exception is only thrown when the last byte is read.

Are you suggesting change:

"...will be thrown when an attempt is made to read the entry."

to

"...will be thrown when the entry has been read."

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

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

From weijun at openjdk.org  Wed Sep 14 00:44:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 00:44:50 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
 <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>
Message-ID: <F-9FaZUKRQ3W2FFaLzFtX2WfSD9bjNju4nXNJhchxpc=.156616ad-6d29-48ff-aa56-35f1d3046a87@github.com>

On Tue, 13 Sep 2022 20:58:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
>> 
>>> 34:  * The {@code JarInputStream} class, which extends {@linkplain ZipInputStream},
>>> 35:  * is used to read the contents of a JAR file from an input stream.
>>> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}
>> 
>> `Manifest` above is the same as the one below. If the one below is in fixed-width, so should be the one above.
>
> Could you please clarify what you are suggesting.  I am using the  `@linkplain` to provide a means to see the actual Manifest name.   I am happy to tweak, just need (perhaps an example) of what you would like

On lines 36 and 37, there are two "Manifest". The first uses `linkplain` so it's using normal font style, the 2nd uses `code` so it's fixed-width. I would like them to be the same. In fact, I would not use `linkplain` at all. I only use it when the text is not a Java identifier. For example, `{@linkplain SecurityManager the Security Manager}`. However in this PR, for all the places where you use it, the text is either a class name or a method name. I would just use `link`.

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
>> 
>>> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,
>>> 77:  * a {@linkplain SecurityException} will be thrown when an attempt is made to
>>> 78:  * read the entry.
>> 
>> Not sure if the the `an attempt` word is precise. The exception is only thrown when the last byte is read.
>
> Are you suggesting change:
> 
> "...will be thrown when an attempt is made to read the entry."
> 
> to
> 
> "...will be thrown when the entry has been read."

Not sure. Maybe just `is read` is OK.

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

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

From lancea at openjdk.org  Wed Sep 14 01:42:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 01:42:20 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  changed linkplain to link and updated note wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/36a74efa..cfdfa06b

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

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

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

From lancea at openjdk.org  Wed Sep 14 01:42:21 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 01:42:21 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <F-9FaZUKRQ3W2FFaLzFtX2WfSD9bjNju4nXNJhchxpc=.156616ad-6d29-48ff-aa56-35f1d3046a87@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
 <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>
 <F-9FaZUKRQ3W2FFaLzFtX2WfSD9bjNju4nXNJhchxpc=.156616ad-6d29-48ff-aa56-35f1d3046a87@github.com>
Message-ID: <jW20Sc4H1eNGdGkdKTLSRAU6gCoNyW1LGprCyeQkoMo=.b67a678e-8ca0-4273-b4a4-15a55b200f1a@github.com>

On Wed, 14 Sep 2022 00:39:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> On lines 36 and 37, there are two "Manifest". The first uses `linkplain` so it's using normal font style, the 2nd uses `code` so it's fixed-width. I would like them to be the same. In fact, I would not use `linkplain` at all. I only use it when the text is not a Java identifier. For example, `{@linkplain SecurityManager the Security Manager}`. However in this PR, for all the places where you use it, the text is either a class name or a method name. I would just use `link`.

Ok, thank you switched to use `link` from `linkplain` per your suggestion

> Not sure. Maybe just `is read` is OK.

Updated  as "...will be thrown when the entry is read."

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

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

From weijun at openjdk.org  Wed Sep 14 02:25:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 02:25:42 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>
Message-ID: <ixnb9DdDiqCKevDjG7-wPnjQ7e4a-hx2HQ9KwL9bph0=.cf96e0e2-65eb-41dc-9790-652d6216bc96@github.com>

On Wed, 14 Sep 2022 01:42:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed linkplain to link and updated note wording

Only tiny comments for the last paragraph.

That said, I have some questions on the other parts of this file:
1. In `getNextEntry`, the method spec says "If verification has been enabled, any invalid signature detected while positioning the stream for the next entry will result in an exception." What does this mean?
2. In `getManifest`, the method spec says "or null if none". Do we need to say "if not found"?

src/java.base/share/classes/java/util/jar/JarInputStream.java line 76:

> 74:  *  the signers.
> 75:  * <p>
> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,

Add a space before `If`. Capitalize `Jar`.

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

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

From mpowers at openjdk.org  Wed Sep 14 03:17:25 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 14 Sep 2022 03:17:25 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v7]
In-Reply-To: <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
 <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
Message-ID: <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>

On Wed, 7 Sep 2022 01:41:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Max and Sean
>
> src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java line 289:
> 
>> 287:             }
>> 288: 
>> 289:             // Can't figure this out, bail.
> 
> Maybe we should instead check if `namedParams` is null on line 286 and avoid the NPE there.

Fixed. Throwing exception sooner rather than later.

> src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 70:
> 
>> 68:     @SuppressWarnings({"unchecked", "rawtypes"})
>> 69:     B_NULL("NULL", NULL_CIPHER, 0, 0, 0, 0, true, true,
>> 70:             new Map.Entry[] {
> 
> It looks cleaner to me if `new Map.Entry[] {` is put at the end of the previous line. Otherwise, the indentation seems growing backwards. Same for line 80 and all below.

I did as you suggested and did a bit more with the indentation.

> src/java.base/share/classes/sun/security/ssl/SSLExtensions.java line 307:
> 
>> 305:                                                     // extension_data length(2)
>> 306:                 }
>> 307:                 encodedLength += encoded.length + 4;
> 
> I think the two comment lines above should follow.

Sure that looks right?

> src/java.base/share/classes/sun/security/ssl/SSLHandshakeBinding.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> No change in this file?

Fixed. No change to file.

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 587:
> 
>> 585:                 for (String string : strings) {
>> 586:                     builder.append("      \"" + string + "\"");
>> 587:                     if (!Objects.equals(string, strings[strings.length - 1])) {
> 
> The original usage looks weird. I'd rather use
> 
>                 int len = strings.length;
>                 for (int i = 0; i < len; i++) {
>                     String string = strings[i];
>                     builder.append("      "" + string + """);
>                     if (i != len - 1) {
>                         builder.append(",");
>                     }
>                     builder.append("\n");
>                 }

Fixed.

> src/java.base/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java line 86:
> 
>> 84:     @Override
>> 85:     public Socket createSocket(String host, int port)
>> 86:     throws IOException {
> 
> Join this with the previous line.

Fixed.

> src/java.base/share/classes/sun/security/ssl/TransportContext.java line 587:
> 
>> 585:         boolean useUserCanceled = !isNegotiated &&
>> 586:                 (handshakeContext != null) && !peerUserCanceled;
>> 587:         // initial handshake
> 
> Move this comment line above a little.

Fixed.

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

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

From xuelei at openjdk.org  Wed Sep 14 06:05:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 06:05:16 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey() method
Message-ID: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>

Hi,

Please review this simple code cleanup.

The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.


        if (k == null) {
            throw new InvalidKeyException("Empty key");
        }
        if (!isKeySizeValid(k.length)) {
             throw new InvalidKeyException("Invalid AES key length: " +
                                           k.length + " bytes");
        }


No new regression test, simple cleanup.

Thanks,
Xuelei

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

Commit messages:
 - 8293779: redundant checking in AESCrypt.makeSessionKey() method

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

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

From djelinski at openjdk.org  Wed Sep 14 08:25:30 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 14 Sep 2022 08:25:30 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method
In-Reply-To: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
Message-ID: <CqUsxsl0rXqjTVvRQbrCVjEfMQkCi63WnmarIiOOMis=.eb2a5d74-e97b-43b4-b717-b4db06f34549@github.com>

On Wed, 14 Sep 2022 05:58:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple code cleanup.
> 
> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
> 
> 
>         if (k == null) {
>             throw new InvalidKeyException("Empty key");
>         }
>         if (!isKeySizeValid(k.length)) {
>              throw new InvalidKeyException("Invalid AES key length: " +
>                                            k.length + " bytes");
>         }
> 
> 
> No new regression test, simple cleanup.
> 
> Thanks,
> Xuelei

Marked as reviewed by djelinski (Committer).

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

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

From coffeys at openjdk.org  Wed Sep 14 09:20:37 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Sep 2022 09:20:37 GMT
Subject: RFR: 8292297: Fix up loading of override java.security properties
 file
In-Reply-To: <0fwPve8Ic02gt_DZzqNFNM0-vQ_ENfz_QnyWP0CGa_w=.7880d9dd-ba5b-41dd-b9ef-3fc3daad2465@github.com>
References: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
 <0fwPve8Ic02gt_DZzqNFNM0-vQ_ENfz_QnyWP0CGa_w=.7880d9dd-ba5b-41dd-b9ef-3fc3daad2465@github.com>
Message-ID: <ETvAlWFKyV2_CIBCTQ9-t2hPPKvFjS_H-4tWFKmOkqQ=.21d3da95-535d-4947-831d-3bd89d780f57@github.com>

On Tue, 13 Sep 2022 16:47:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Is it a behavioral change that requires CSR approval?

I considered the CSR impact before logging this PR. This issue corrects a bug where security properties had potential to be lost if an incorrect URL/resource was specified for the secondary/override security conf file. The system was already working with bad user config in such a case. Don't think it needs a CSR but open to correction.

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

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

From lancea at openjdk.org  Wed Sep 14 10:31:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 10:31:41 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address a couple of typos in  Note

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/cfdfa06b..aff39596

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

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

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

From lancea at openjdk.org  Wed Sep 14 10:39:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 10:39:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <ixnb9DdDiqCKevDjG7-wPnjQ7e4a-hx2HQ9KwL9bph0=.cf96e0e2-65eb-41dc-9790-652d6216bc96@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>
 <ixnb9DdDiqCKevDjG7-wPnjQ7e4a-hx2HQ9KwL9bph0=.cf96e0e2-65eb-41dc-9790-652d6216bc96@github.com>
Message-ID: <wRE4TkmrctF7Pv3Hy3KujKcFxa7C5uj4TddczyRb8Vg=.120353ca-2d1a-4eac-ab7d-1f9819282a6e@github.com>

On Wed, 14 Sep 2022 02:22:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Only tiny comments for the last paragraph.

Thank you Max, I addressed the above
> 
> That said, I have some questions on the other parts of this file:
> 
>     1. In `getNextEntry`, the method spec says "If verification has been enabled, any invalid signature detected while positioning the stream for the next entry will result in an exception." What does this mean?

I don't know the history of this comment in the spec and on a quick scan of the code, I am not sure I know either.  As our signed JAR expert, I will defer to you (and Alan) if we should remove this or leave  for another time to address(which I would prefer if we are not removing the verbiage).

> 
>     2. In `getManifest`, the method spec says "or null if none". Do we need to say "if not found"?

I think we are OK given the changes to the class description.

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

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

From alanb at openjdk.org  Wed Sep 14 13:01:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 13:01:49 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
Message-ID: <8l5jHWgf0uRlQ73dADvKRAn1WknyANt08yKRYNg5TZU=.58a7f7d7-bbb4-43dc-8c0a-c454623ac44e@github.com>

On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address a couple of typos in  Note

src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:

> 42:  * The {@link #getManifest} method will return the {@code Manifest} when it is
> 43:  * the first entry in the stream or {@code META-INF/} is the first entry and
> 44:  * the {@code Manifest} is the second entry within the stream. When the

I think you can insert a comma after "when it is the first entry in the stream"? I think that would make it a bit clearer that there are two cases.

Also I'm wondering if the paragraph should be split into two, meaning "When the Manifest ..."  can be the start of a new paragraph. The reason is that the text is trying to explain two things, the first is that the manifest must be at the start of the JAR file, the second is that the ordering that methods are invoked will influence how other methods behave.

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

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

From mullan at openjdk.org  Wed Sep 14 13:29:40 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 13:29:40 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method
In-Reply-To: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
Message-ID: <2vG3GN7MIZTa2UlkqoToYlyuYUGN4j48_uh_A6jDOWg=.984f66bf-c0e2-491a-b421-062d540bc91f@github.com>

On Wed, 14 Sep 2022 05:58:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple code cleanup.
> 
> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
> 
> 
>         if (k == null) {
>             throw new InvalidKeyException("Empty key");
>         }
>         if (!isKeySizeValid(k.length)) {
>              throw new InvalidKeyException("Invalid AES key length: " +
>                                            k.length + " bytes");
>         }
> 
> 
> No new regression test, simple cleanup.
> 
> Thanks,
> Xuelei

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 604:

> 602:      * @exception InvalidKeyException  If the key is invalid.
> 603:      */
> 604:     private void makeSessionKey(byte[] k) throws InvalidKeyException {

Can it still throw InvalidKeyException?

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

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

From mpowers at openjdk.org  Wed Sep 14 13:48:19 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 14 Sep 2022 13:48:19 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v8]
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <rJL6xp2iJJkl68fmNW0QluD_hdqbDk_jhntB1Xpsx4o=.110243df-295b-4940-817d-dd994553009f@github.com>

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

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

  final comments from Max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9972/files
  - new: https://git.openjdk.org/jdk/pull/9972/files/800b100f..6e2c308b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=06-07

  Stats: 256 lines in 9 files changed: 10 ins; 24 del; 222 mod
  Patch: https://git.openjdk.org/jdk/pull/9972.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9972/head:pull/9972

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

From mpowers at openjdk.org  Wed Sep 14 13:53:00 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 14 Sep 2022 13:53:00 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v7]
In-Reply-To: <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
 <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
 <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
Message-ID: <m6_fnNr9F0xq9qDWLyHtFCLjsGwpSk3xcmsbjaroLuo=.049febb4-1076-4866-b946-dc3b44926e68@github.com>

On Wed, 14 Sep 2022 03:14:29 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 70:
>> 
>>> 68:     @SuppressWarnings({"unchecked", "rawtypes"})
>>> 69:     B_NULL("NULL", NULL_CIPHER, 0, 0, 0, 0, true, true,
>>> 70:             new Map.Entry[] {
>> 
>> It looks cleaner to me if `new Map.Entry[] {` is put at the end of the previous line. Otherwise, the indentation seems growing backwards. Same for line 80 and all below.
>
> I did as you suggested and did a bit more with the indentation.

I reworked it again. Take a look.

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

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

From weijun at openjdk.org  Wed Sep 14 15:56:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 15:56:07 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
Message-ID: <0bf2paYYal_MCs014sGdWjm0ElohULY16JGqJIzyM6I=.5958f587-f228-49f5-9daf-2b31e7aa697c@github.com>

On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address a couple of typos in  Note

I have no more comment.

My understanding is that `getNextEntry` does not throw a `SecurityException` since it should not read anything. If the signature does not match then a `SecurityException` should be thrown when reading a signature-related file. If a normal entry is modified it should be thrown when reading that entry.

This is a quite big change. I suggest we do not touch it this time.

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

Marked as reviewed by weijun (Reviewer).

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

From xuelei at openjdk.org  Wed Sep 14 15:58:40 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 15:58:40 GMT
Subject: RFR: 8292297: Fix up loading of override java.security properties
 file
In-Reply-To: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
References: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
Message-ID: <QLFJNWfCuJih1gGPYJp0lHOErhOGD8gxO2BqAkjbbko=.7ec6848f-999c-463e-ab40-dbbe5c946bf9@github.com>

On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Ensure that security properties are only overridden if the override security properties file exists. 
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.

Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From xuelei at openjdk.org  Wed Sep 14 16:03:48 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 16:03:48 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v2]
In-Reply-To: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
Message-ID: <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>

> Hi,
> 
> Please review this simple code cleanup.
> 
> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
> 
> 
>         if (k == null) {
>             throw new InvalidKeyException("Empty key");
>         }
>         if (!isKeySizeValid(k.length)) {
>              throw new InvalidKeyException("Invalid AES key length: " +
>                                            k.length + " bytes");
>         }
> 
> 
> No new regression test, simple cleanup.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:

 - remove unused throws in comment
 - remove unused throws

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10263/files
  - new: https://git.openjdk.org/jdk/pull/10263/files/fa427fd3..d915ca1b

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

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

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

From xuelei at openjdk.org  Wed Sep 14 16:03:50 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 16:03:50 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v2]
In-Reply-To: <2vG3GN7MIZTa2UlkqoToYlyuYUGN4j48_uh_A6jDOWg=.984f66bf-c0e2-491a-b421-062d540bc91f@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <2vG3GN7MIZTa2UlkqoToYlyuYUGN4j48_uh_A6jDOWg=.984f66bf-c0e2-491a-b421-062d540bc91f@github.com>
Message-ID: <GRN06D9C-1jGmpCmC8ZOzV0-g9WBxzszAkI1PgnwbJk=.421cc7db-bee9-49fb-8acf-ad27cc1f3e97@github.com>

On Wed, 14 Sep 2022 13:25:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove unused throws in comment
>>  - remove unused throws
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 604:
> 
>> 602:      * @exception InvalidKeyException  If the key is invalid.
>> 603:      */
>> 604:     private void makeSessionKey(byte[] k) throws InvalidKeyException {
> 
> Can it still throw InvalidKeyException?

Good catch.  The throws is no longer needed.

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

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

From hchao at openjdk.org  Wed Sep 14 16:11:58 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 14 Sep 2022 16:11:58 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v2]
In-Reply-To: <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
Message-ID: <7DL5TGMtXe41cP2_wquJ8yZ_SU3DepSfACG6fIKJ8cQ=.ad380147-4ed8-4f18-9bee-c78202b6990c@github.com>

On Wed, 14 Sep 2022 16:03:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple code cleanup.
>> 
>> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
>> 
>> 
>>         if (k == null) {
>>             throw new InvalidKeyException("Empty key");
>>         }
>>         if (!isKeySizeValid(k.length)) {
>>              throw new InvalidKeyException("Invalid AES key length: " +
>>                                            k.length + " bytes");
>>         }
>> 
>> 
>> No new regression test, simple cleanup.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused throws in comment
>  - remove unused throws

Marked as reviewed by hchao (Committer).

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

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

From lancea at openjdk.org  Wed Sep 14 16:43:43 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:43:43 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address latest input regarding wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/aff39596..10ddfd31

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

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

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

From lancea at openjdk.org  Wed Sep 14 16:43:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:43:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <0bf2paYYal_MCs014sGdWjm0ElohULY16JGqJIzyM6I=.5958f587-f228-49f5-9daf-2b31e7aa697c@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
 <0bf2paYYal_MCs014sGdWjm0ElohULY16JGqJIzyM6I=.5958f587-f228-49f5-9daf-2b31e7aa697c@github.com>
Message-ID: <_WstsrA3TqUNwvBCebh2rcW4GY0agCQxIxIlpBoYaJA=.63d8a273-04df-4bc7-8226-63d1109b03c0@github.com>

On Wed, 14 Sep 2022 15:53:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I have no more comment.

Thank you Max for your time and input

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

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

From lancea at openjdk.org  Wed Sep 14 16:43:46 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:43:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <8l5jHWgf0uRlQ73dADvKRAn1WknyANt08yKRYNg5TZU=.58a7f7d7-bbb4-43dc-8c0a-c454623ac44e@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
 <8l5jHWgf0uRlQ73dADvKRAn1WknyANt08yKRYNg5TZU=.58a7f7d7-bbb4-43dc-8c0a-c454623ac44e@github.com>
Message-ID: <V36LHH0-XBZFdlbPbcsW_oIpeVZmh4QEF4hGnaLu3Dk=.bb90a1b1-a3b2-43e4-857a-f61afe40dc57@github.com>

On Wed, 14 Sep 2022 12:53:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think you can insert a comma after "when it is the first entry in the stream"? I think that would make it a bit clearer that there are two cases.

Done
> 
> Also I'm wondering if the paragraph should be split into two, meaning "When the Manifest ..." can be the start of a new paragraph. The reason is that the text is trying to explain two things, the first is that the manifest must be at the start of the JAR file, the second is that the ordering that methods are invoked will influence how other methods behave.

Moved to a new paragraph per your suggestion

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

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

From coffeys at openjdk.org  Wed Sep 14 17:13:11 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Sep 2022 17:13:11 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
Message-ID: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>

Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

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

Commit messages:
 - Track successful getInstance calls only
 - Merge branch 'master' into 8254711-jfr-jca
 - Refactor and use of static Event on
 - Merge branch 'master' into 8254711-jfr-jca
 - new test
 - Event iteration
 - Merge branch 'master' into 8254711-jfr-jca
 - JFR edits

Changes: https://git.openjdk.org/jdk/pull/9657/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254711
  Stats: 305 lines in 8 files changed: 269 ins; 27 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9657.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657

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

From coffeys at openjdk.org  Wed Sep 14 17:13:11 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Sep 2022 17:13:11 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <QJlDzViaiirf-ANl-7Vw_l1WlRdArsYhIRuVlMMzNr4=.b1eb8913-4ac0-40ee-9eb0-54a4aafbd1b3@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Reviewer request: @seanjmullan @egahlin

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

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

From duke at openjdk.org  Wed Sep 14 17:23:17 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 14 Sep 2022 17:23:17 GMT
Subject: RFR: 8293815: P11PSSSignature.engineUpdate should not print debug
 messages during normal operation
Message-ID: <TJb_J1ZIMXZpaBFuiJdPtAD8PfBjs87_O0N9g_DoOMo=.78a03327-5f34-466f-bbc5-b64461da27e6@github.com>

During testing I have found messages such as this are printed to stdout:

sun.security.pkcs11.P11PSSSignature at 6e1567f1: Calling C_SignUpdate


**Problem:**
Problem is in P11PSSSignature.engineUpdate method [1], which unconditionally prints some debug information to stdout. Other prints in that class are conditional based on value of DEBUG field.

**Solution:**
I have made fix to make these conditional based on value of DEBUG field. As it only affects debug messages, there is no test added.

**Testing:**
Passed jdk_security locally with my fix.

[1] https://github.com/openjdk/jdk/blob/211fab8d361822bbd1a34a88626853bf4a029af5/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java#L578

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

Commit messages:
 - P11PSSSignature.engineUpdate should not print debug messages during normal operation

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

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

From mullan at openjdk.org  Wed Sep 14 17:38:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 17:38:51 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v2]
In-Reply-To: <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
Message-ID: <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>

On Wed, 14 Sep 2022 16:03:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple code cleanup.
>> 
>> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
>> 
>> 
>>         if (k == null) {
>>             throw new InvalidKeyException("Empty key");
>>         }
>>         if (!isKeySizeValid(k.length)) {
>>              throw new InvalidKeyException("Invalid AES key length: " +
>>                                            k.length + " bytes");
>>         }
>> 
>> 
>> No new regression test, simple cleanup.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused throws in comment
>  - remove unused throws

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 605:

> 603:      */
> 604:     private void makeSessionKey(byte[] k) throws InvalidKeyException {
> 605:         int ROUNDS          = getRounds(k.length);

You could have left the check in here and removed the duplicate check from `init()`. Since the key is not referenced by `init` unless the key is different from the last key, it seems cleaner to leave it here, and I think the check would be invoked fewer times if the same key is reused.

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

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

From mullan at openjdk.org  Wed Sep 14 17:51:02 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 17:51:02 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v2]
In-Reply-To: <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
Message-ID: <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>

On Wed, 14 Sep 2022 17:36:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove unused throws in comment
>>  - remove unused throws
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 605:
> 
>> 603:      */
>> 604:     private void makeSessionKey(byte[] k) throws InvalidKeyException {
>> 605:         int ROUNDS          = getRounds(k.length);
> 
> You could have left the check in here and removed the duplicate check from `init()`. Since the key is not referenced by `init` unless the key is different from the last key, it seems cleaner to leave it here, and I think the check would be invoked fewer times if the same key is reused.

Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.

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

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

From mullan at openjdk.org  Wed Sep 14 17:51:01 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 17:51:01 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v2]
In-Reply-To: <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
Message-ID: <iN99Ne6bKLqDvAjcaMa-QlonLkk8W2CVQOizWDRJzjQ=.2adb46a8-af67-496d-bbdd-06fe550c5242@github.com>

On Wed, 14 Sep 2022 16:03:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple code cleanup.
>> 
>> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
>> 
>> 
>>         if (k == null) {
>>             throw new InvalidKeyException("Empty key");
>>         }
>>         if (!isKeySizeValid(k.length)) {
>>              throw new InvalidKeyException("Invalid AES key length: " +
>>                                            k.length + " bytes");
>>         }
>> 
>> 
>> No new regression test, simple cleanup.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused throws in comment
>  - remove unused throws

Marked as reviewed by mullan (Reviewer).

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

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

From xuelei at openjdk.org  Wed Sep 14 18:13:40 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 18:13:40 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
Message-ID: <GdylbB4QPFajtYCWtiPJILq2Kq3pSkCOyuACfVYeHCQ=.e09e7a28-009f-4c0a-ad0b-e6ff23e95774@github.com>

> Hi,
> 
> Please review this simple code cleanup.
> 
> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
> 
> 
>         if (k == null) {
>             throw new InvalidKeyException("Empty key");
>         }
>         if (!isKeySizeValid(k.length)) {
>              throw new InvalidKeyException("Invalid AES key length: " +
>                                            k.length + " bytes");
>         }
> 
> 
> No new regression test, simple cleanup.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  check only if necessary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10263/files
  - new: https://git.openjdk.org/jdk/pull/10263/files/d915ca1b..af61f2ef

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

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

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

From xuelei at openjdk.org  Wed Sep 14 18:17:00 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 18:17:00 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
Message-ID: <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>

On Wed, 14 Sep 2022 17:48:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 605:
>> 
>>> 603:      */
>>> 604:     private void makeSessionKey(byte[] k) throws InvalidKeyException {
>>> 605:         int ROUNDS          = getRounds(k.length);
>> 
>> You could have left the check in here and removed the duplicate check from `init()`. Since the key is not referenced by `init` unless the key is different from the last key, it seems cleaner to leave it here, and I think the check would be invoked fewer times if the same key is reused.
>
> Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.

Good point.  Modified to use less checking.

If the key is null, the following condition could bypass the checking, and result in NPE.

`        if (!MessageDigest.isEqual(key, lastKey)) {
`

Although it is unlikely to happen as the caller should has already been checked that the key cannot be null, but the code logic here is not that clear to read.  In the new patch, I have the null checking in the init() method, and the validity checking in the makeSessionKey() method.

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

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

From xuelei at openjdk.org  Wed Sep 14 18:27:42 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 14 Sep 2022 18:27:42 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
 <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
Message-ID: <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>

On Wed, 14 Sep 2022 18:14:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.
>
> Good point.  Modified to use less checking.
> 
> If the key is null, the following condition could bypass the checking, and result in NPE.
> 
> `        if (!MessageDigest.isEqual(key, lastKey)) {
> `
> 
> Although it is unlikely to happen as the caller should has already been checked that the key cannot be null, but the code logic here is not that clear to read.  In the new patch, I have the null checking in the init() method, and the validity checking in the makeSessionKey() method.

> Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.

The key should be valid for common cases.  For valid key, it is more efficient to have the checking in makeSessionKey() as there is less checking.  For invalid key, it is more efficient to have the checking before calling MessageDigest.isEqual().  Exception itself is costly, I would prefer to have better performance for common cases (valid key).

I updated the patch before I read the comment.  Please let me know your preference.  I'm fine to rollback if you prefer the old patch.

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

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

From valeriep at openjdk.org  Wed Sep 14 18:43:44 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 14 Sep 2022 18:43:44 GMT
Subject: RFR: 8293815: P11PSSSignature.engineUpdate should not print debug
 messages during normal operation
In-Reply-To: <TJb_J1ZIMXZpaBFuiJdPtAD8PfBjs87_O0N9g_DoOMo=.78a03327-5f34-466f-bbc5-b64461da27e6@github.com>
References: <TJb_J1ZIMXZpaBFuiJdPtAD8PfBjs87_O0N9g_DoOMo=.78a03327-5f34-466f-bbc5-b64461da27e6@github.com>
Message-ID: <OCtrZrBCd7ODeJek0ggPjn3mmkfFNEjXWOvibn5QsDs=.5deb074b-7a1b-4004-98cb-244296de1da3@github.com>

On Wed, 14 Sep 2022 17:03:41 GMT, zzambers <duke at openjdk.org> wrote:

> During testing I have found messages such as this are printed to stdout:
> 
> sun.security.pkcs11.P11PSSSignature at 6e1567f1: Calling C_SignUpdate
> 
> 
> **Problem:**
> Problem is in P11PSSSignature.engineUpdate method [1], which unconditionally prints some debug information to stdout. Other prints in that class are conditional based on value of DEBUG field.
> 
> **Solution:**
> I have made fix to make these conditional based on value of DEBUG field. As it only affects debug messages, there is no test added.
> 
> **Testing:**
> Passed jdk_security locally with my fix.
> 
> [1] https://github.com/openjdk/jdk/blob/211fab8d361822bbd1a34a88626853bf4a029af5/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java#L578

Thanks for catching and fixing it.

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

Marked as reviewed by valeriep (Reviewer).

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

From weijun at openjdk.org  Wed Sep 14 19:49:00 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 19:49:00 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v8]
In-Reply-To: <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
 <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
 <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
Message-ID: <NLAftAgR2g79l4AQJVNo_Du48z0vBfxGQ8MZi9fQh9Y=.bac69f8a-0029-4ca1-8181-654082d4784e@github.com>

On Wed, 14 Sep 2022 03:14:33 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java line 289:
>> 
>>> 287:             }
>>> 288: 
>>> 289:             // Can't figure this out, bail.
>> 
>> Maybe we should instead check if `namedParams` is null on line 286 and avoid the NPE there.
>
> Fixed. Throwing exception sooner rather than later.

Some final comments.

1. Move the definition of `namedParams` inside the if block it is used and merge with the assignment line.
2. Change `if (ecParams == null)` to `else`, and then there is no need to assign an initial value to `namedGroup`.

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

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

From weijun at openjdk.org  Wed Sep 14 19:49:01 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 19:49:01 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v7]
In-Reply-To: <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
 <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
 <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
Message-ID: <ZblgDn5E1o7n7z-mo63HxQdpn_OVsbMy9gXYpNROhoc=.348f12b4-a3ab-4b49-9901-a7fb260bf14e@github.com>

On Wed, 14 Sep 2022 03:14:23 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLExtensions.java line 307:
>> 
>>> 305:                                                     // extension_data length(2)
>>> 306:                 }
>>> 307:                 encodedLength += encoded.length + 4;
>> 
>> I think the two comment lines above should follow.
>
> Sure that looks right?

Seems so.

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

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

From weijun at openjdk.org  Wed Sep 14 19:52:18 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 19:52:18 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v7]
In-Reply-To: <m6_fnNr9F0xq9qDWLyHtFCLjsGwpSk3xcmsbjaroLuo=.049febb4-1076-4866-b946-dc3b44926e68@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
 <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
 <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
 <m6_fnNr9F0xq9qDWLyHtFCLjsGwpSk3xcmsbjaroLuo=.049febb4-1076-4866-b946-dc3b44926e68@github.com>
Message-ID: <r9MpEq8qGkvgqqdLODs3AK0u_RXKei2qUmB6u3L5RyQ=.03df4877-f7b6-41b7-a1f9-6106841f82db@github.com>

On Wed, 14 Sep 2022 13:50:55 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I did as you suggested and did a bit more with the indentation.
>
> I reworked it again. Take a look.

Looks good. Thanks.

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

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

From weijun at openjdk.org  Wed Sep 14 19:57:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 19:57:40 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v8]
In-Reply-To: <rJL6xp2iJJkl68fmNW0QluD_hdqbDk_jhntB1Xpsx4o=.110243df-295b-4940-817d-dd994553009f@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <rJL6xp2iJJkl68fmNW0QluD_hdqbDk_jhntB1Xpsx4o=.110243df-295b-4940-817d-dd994553009f@github.com>
Message-ID: <e-Sov_y7C4LcDrSn3TY-Vd4ldaNYSUGIJnTwLTppm3k=.185fedd2-f1d4-4504-914a-6e8d44c35482@github.com>

On Wed, 14 Sep 2022 13:48:19 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

Almost done. I only have 2 comments on `ssl/ECDHClientKeyExchange.java` and `certpath/ForwardBuilder.java`, separately.

src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 572:

> 570:                 if (distanceTto1 < 0 || distanceTto2 < 0) {
> 571:                     if (distanceTto1 == distanceTto2) {
> 572:                         return -1;

This block can be modified like the previous one. This time it's about "at least one is negative".

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

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

From mullan at openjdk.org  Wed Sep 14 20:51:40 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 20:51:40 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
 <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
 <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>
Message-ID: <UWGnoIPbVSr5D5KW6iuI0soIQELeQOxaGMaTSK57U0o=.d417a356-8c9a-441e-b71d-1a81478dd117@github.com>

On Wed, 14 Sep 2022 18:23:51 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Good point.  Modified to use less checking.
>> 
>> If the key is null, the following condition could bypass the checking, and result in NPE.
>> 
>> `        if (!MessageDigest.isEqual(key, lastKey)) {
>> `
>> 
>> Although it is unlikely to happen as the caller should has already been checked that the key cannot be null, but the code logic here is not that clear to read.  In the new patch, I have the null checking in the init() method, and the validity checking in the makeSessionKey() method.
>
>> Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.
> 
> The key should be valid for common cases.  For valid key, it is more efficient to have the checking in makeSessionKey() as there is less checking.  For invalid key, it is more efficient to have the checking before calling MessageDigest.isEqual().  Exception itself is costly, I would prefer to have better performance for common cases (valid key).
> 
> I updated the patch before I read the comment.  Please let me know your preference.  I'm fine to rollback if you prefer the old patch.

> If the key is null, the following condition could bypass the checking, and result in NPE.
> 
> ` if (!MessageDigest.isEqual(key, lastKey)) {`
> 
> Although it is unlikely to happen as the caller should has already been checked that the key cannot be null, but the code logic here is not that clear to read. In the new patch, I have the null checking in the init() method, and the validity checking in the makeSessionKey() method.

I agree, the provider layer should have rejected a null `Key` or a null `Key.getEncoded` prior to this, but best to not change what this code previously did (at least not for this change).

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

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

From mullan at openjdk.org  Wed Sep 14 21:08:44 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 21:08:44 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <UWGnoIPbVSr5D5KW6iuI0soIQELeQOxaGMaTSK57U0o=.d417a356-8c9a-441e-b71d-1a81478dd117@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
 <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
 <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>
 <UWGnoIPbVSr5D5KW6iuI0soIQELeQOxaGMaTSK57U0o=.d417a356-8c9a-441e-b71d-1a81478dd117@github.com>
Message-ID: <QlIP7ZM3mnai3pp3V2VXVAkuV8MM818CkZPOOEHxnKw=.0e9f8f72-f9b8-419e-8a31-c337cbcf29ff@github.com>

On Wed, 14 Sep 2022 20:49:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.
>> 
>> The key should be valid for common cases.  For valid key, it is more efficient to have the checking in makeSessionKey() as there is less checking.  For invalid key, it is more efficient to have the checking before calling MessageDigest.isEqual().  Exception itself is costly, I would prefer to have better performance for common cases (valid key).
>> 
>> I updated the patch before I read the comment.  Please let me know your preference.  I'm fine to rollback if you prefer the old patch.
>
>> If the key is null, the following condition could bypass the checking, and result in NPE.
>> 
>> ` if (!MessageDigest.isEqual(key, lastKey)) {`
>> 
>> Although it is unlikely to happen as the caller should has already been checked that the key cannot be null, but the code logic here is not that clear to read. In the new patch, I have the null checking in the init() method, and the validity checking in the makeSessionKey() method.
> 
> I agree, the provider layer should have rejected a null `Key` or a null `Key.getEncoded` prior to this, but best to not change what this code previously did (at least not for this change).

> > Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.
> 
> The key should be valid for common cases. For valid key, it is more efficient to have the checking in makeSessionKey() as there is less checking. For invalid key, it is more efficient to have the checking before calling MessageDigest.isEqual(). Exception itself is costly, I would prefer to have better performance for common cases (valid key).
> 
> I updated the patch before I read the comment. Please let me know your preference. I'm fine to rollback if you prefer the old patch.

Yes, I think your current fix should be fine too. No need to rollback.

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

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

From mpowers at openjdk.org  Wed Sep 14 21:40:12 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 14 Sep 2022 21:40:12 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v8]
In-Reply-To: <e-Sov_y7C4LcDrSn3TY-Vd4ldaNYSUGIJnTwLTppm3k=.185fedd2-f1d4-4504-914a-6e8d44c35482@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <rJL6xp2iJJkl68fmNW0QluD_hdqbDk_jhntB1Xpsx4o=.110243df-295b-4940-817d-dd994553009f@github.com>
 <e-Sov_y7C4LcDrSn3TY-Vd4ldaNYSUGIJnTwLTppm3k=.185fedd2-f1d4-4504-914a-6e8d44c35482@github.com>
Message-ID: <CRRjmlkkvbLsIuBT5GUVyqUD1Ywuv7qCjYEm9dzcZB8=.676064ec-4f9d-4e52-bc64-dfd65cc74f88@github.com>

On Wed, 14 Sep 2022 19:52:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   final comments from Max
>
> src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 572:
> 
>> 570:                 if (distanceTto1 < 0 || distanceTto2 < 0) {
>> 571:                     if (distanceTto1 == distanceTto2) {
>> 572:                         return -1;
> 
> This block can be modified like the previous one. This time it's about "at least one is negative".

Fixed.

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

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

From mpowers at openjdk.org  Wed Sep 14 21:40:12 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 14 Sep 2022 21:40:12 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v8]
In-Reply-To: <NLAftAgR2g79l4AQJVNo_Du48z0vBfxGQ8MZi9fQh9Y=.bac69f8a-0029-4ca1-8181-654082d4784e@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <NCuSVluUDXZAak0rXX8dfaL7_Ok2N9SjLJ7jRTc9mXQ=.f635f588-65e6-42dc-84fc-763531bbd467@github.com>
 <ROinmVSSJvBXypfAOrq93_FhrcqgK_3a54yL0VBrLRM=.eb24c780-4d3d-4313-a074-6b957053e566@github.com>
 <Qvc8l0dXb7zDrLwquPpMffO_rWEEh8ZWXOvfxgiWLb8=.8c20b3a4-ba3c-434b-9069-f409c98f4461@github.com>
 <NLAftAgR2g79l4AQJVNo_Du48z0vBfxGQ8MZi9fQh9Y=.bac69f8a-0029-4ca1-8181-654082d4784e@github.com>
Message-ID: <F8d2X1i63M0Q0sctCe530cMI5-cv9uKA6uVDNtTy9Qc=.43ad0c88-c300-4a9c-a7c2-a04f44ae981f@github.com>

On Wed, 14 Sep 2022 19:44:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Fixed. Throwing exception sooner rather than later.
>
> Some final comments.
> 
> 1. Move the definition of `namedParams` inside the if block it is used and merge with the assignment line.
> 2. Change `if (ecParams == null)` to `else`, and then there is no need to assign an initial value to `namedGroup`.

Fixed.

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

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

From mpowers at openjdk.org  Wed Sep 14 23:15:29 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 14 Sep 2022 23:15:29 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v9]
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <kBfCmKK-5Xn3M5Zrpb9QCrVmIxctoUUB-A9PUl5HecQ=.14cdf42f-2256-4039-bcbd-92a777938e45@github.com>

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

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

  final comments from Max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9972/files
  - new: https://git.openjdk.org/jdk/pull/9972/files/6e2c308b..3f28895e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=07-08

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

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

From duke at openjdk.org  Thu Sep 15 00:08:45 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 15 Sep 2022 00:08:45 GMT
Subject: RFR: 8293815: P11PSSSignature.engineUpdate should not print debug
 messages during normal operation
In-Reply-To: <OCtrZrBCd7ODeJek0ggPjn3mmkfFNEjXWOvibn5QsDs=.5deb074b-7a1b-4004-98cb-244296de1da3@github.com>
References: <TJb_J1ZIMXZpaBFuiJdPtAD8PfBjs87_O0N9g_DoOMo=.78a03327-5f34-466f-bbc5-b64461da27e6@github.com>
 <OCtrZrBCd7ODeJek0ggPjn3mmkfFNEjXWOvibn5QsDs=.5deb074b-7a1b-4004-98cb-244296de1da3@github.com>
Message-ID: <xjgy43voJY3Y2FMPVlkjWK8faUeOlsZ1uFZNKnRaYkY=.dc93f13a-1772-4b42-8aa7-e80645afdf60@github.com>

On Wed, 14 Sep 2022 18:41:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> During testing I have found messages such as this are printed to stdout:
>> 
>> sun.security.pkcs11.P11PSSSignature at 6e1567f1: Calling C_SignUpdate
>> 
>> 
>> **Problem:**
>> Problem is in P11PSSSignature.engineUpdate method [1], which unconditionally prints some debug information to stdout. Other prints in that class are conditional based on value of DEBUG field.
>> 
>> **Solution:**
>> I have made fix to make these conditional based on value of DEBUG field. As it only affects debug messages, there is no test added.
>> 
>> **Testing:**
>> Passed jdk_security locally with my fix.
>> 
>> [1] https://github.com/openjdk/jdk/blob/211fab8d361822bbd1a34a88626853bf4a029af5/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java#L578
>
> Thanks for catching and fixing it.

@valeriepeng thanks

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

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

From duke at openjdk.org  Thu Sep 15 01:09:18 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 15 Sep 2022 01:09:18 GMT
Subject: Integrated: 8293815: P11PSSSignature.engineUpdate should not print
 debug messages during normal operation
In-Reply-To: <TJb_J1ZIMXZpaBFuiJdPtAD8PfBjs87_O0N9g_DoOMo=.78a03327-5f34-466f-bbc5-b64461da27e6@github.com>
References: <TJb_J1ZIMXZpaBFuiJdPtAD8PfBjs87_O0N9g_DoOMo=.78a03327-5f34-466f-bbc5-b64461da27e6@github.com>
Message-ID: <w0WGP6RHBl6nJbzIxTxS4pPvoFhoGCwrXdbIbRKPABk=.84ba28e0-80a1-4578-9c07-ec4e72d88328@github.com>

On Wed, 14 Sep 2022 17:03:41 GMT, zzambers <duke at openjdk.org> wrote:

> During testing I have found messages such as this are printed to stdout:
> 
> sun.security.pkcs11.P11PSSSignature at 6e1567f1: Calling C_SignUpdate
> 
> 
> **Problem:**
> Problem is in P11PSSSignature.engineUpdate method [1], which unconditionally prints some debug information to stdout. Other prints in that class are conditional based on value of DEBUG field.
> 
> **Solution:**
> I have made fix to make these conditional based on value of DEBUG field. As it only affects debug messages, there is no test added.
> 
> **Testing:**
> Passed jdk_security locally with my fix.
> 
> [1] https://github.com/openjdk/jdk/blob/211fab8d361822bbd1a34a88626853bf4a029af5/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java#L578

This pull request has now been integrated.

Changeset: 2057070e
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2057070eb069ccee20760e47bd5e09590850d2ce
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8293815: P11PSSSignature.engineUpdate should not print debug messages during normal operation

Reviewed-by: valeriep

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

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

From weijun at openjdk.org  Thu Sep 15 02:43:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Sep 2022 02:43:07 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v9]
In-Reply-To: <kBfCmKK-5Xn3M5Zrpb9QCrVmIxctoUUB-A9PUl5HecQ=.14cdf42f-2256-4039-bcbd-92a777938e45@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <kBfCmKK-5Xn3M5Zrpb9QCrVmIxctoUUB-A9PUl5HecQ=.14cdf42f-2256-4039-bcbd-92a777938e45@github.com>
Message-ID: <6-EwT_JiYpc9MyNVpMEw7BSipn5UwF7aUpcIcu7f1ac=.2359cca8-de63-446f-bc2c-378e37318527@github.com>

On Wed, 14 Sep 2022 23:15:29 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

Marked as reviewed by weijun (Reviewer).

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

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

From weijun at openjdk.org  Thu Sep 15 02:50:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Sep 2022 02:50:46 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <hdt16Pm1dqs0OzgENUVLe9kwZN4GYVw0GC6ZOptfEL4=.96b0b7a3-705d-4e70-9f89-39718467f90a@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

In the problem section part of the CSR, add a sentence on what's wrong with the field.

In the spec section, please only keep the removal of the `testing` field. All others are implementation changes and not part of spec.

In the compatibility reason, add a sentence on why removing the field has no actual effect on serialization and deserialization.

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

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

From djelinski at openjdk.org  Thu Sep 15 05:12:45 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Sep 2022 05:12:45 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <QlIP7ZM3mnai3pp3V2VXVAkuV8MM818CkZPOOEHxnKw=.0e9f8f72-f9b8-419e-8a31-c337cbcf29ff@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
 <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
 <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>
 <UWGnoIPbVSr5D5KW6iuI0soIQELeQOxaGMaTSK57U0o=.d417a356-8c9a-441e-b71d-1a81478dd117@github.com>
 <QlIP7ZM3mnai3pp3V2VXVAkuV8MM818CkZPOOEHxnKw=.0e9f8f72-f9b8-419e-8a31-c337cbcf29ff@github.com>
Message-ID: <EPEK96reRJKSntfvLootmeJyJybxRkCEnC9G4_vgtjc=.7541b20d-2207-4e05-9078-abe83c396359@github.com>

On Wed, 14 Sep 2022 21:04:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> If the key is null, the following condition could bypass the checking, and result in NPE.
>>> 
>>> ` if (!MessageDigest.isEqual(key, lastKey)) {`
>>> 
>>> Although it is unlikely to happen as the caller should has already been checked that the key cannot be null, but the code logic here is not that clear to read. In the new patch, I have the null checking in the init() method, and the validity checking in the makeSessionKey() method.
>> 
>> I agree, the provider layer should have rejected a null `Key` or a null `Key.getEncoded` prior to this, but best to not change what this code previously did (at least not for this change).
>
>> > Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.
>> 
>> The key should be valid for common cases. For valid key, it is more efficient to have the checking in makeSessionKey() as there is less checking. For invalid key, it is more efficient to have the checking before calling MessageDigest.isEqual(). Exception itself is costly, I would prefer to have better performance for common cases (valid key).
>> 
>> I updated the patch before I read the comment. Please let me know your preference. I'm fine to rollback if you prefer the old patch.
> 
> Yes, I think your current fix should be fine too. No need to rollback.

Speaking of MessageDigest.isEqual, we don't need constant time comparison here. We could use Arrays.equals for some extra performance.

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

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

From djelinski at openjdk.org  Thu Sep 15 05:25:12 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Sep 2022 05:25:12 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <GdylbB4QPFajtYCWtiPJILq2Kq3pSkCOyuACfVYeHCQ=.e09e7a28-009f-4c0a-ad0b-e6ff23e95774@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <GdylbB4QPFajtYCWtiPJILq2Kq3pSkCOyuACfVYeHCQ=.e09e7a28-009f-4c0a-ad0b-e6ff23e95774@github.com>
Message-ID: <oLbC62WvhvTX9Z3XOIiRDG8rQO0i0trElE5o7Z4_iYs=.46677feb-c083-4412-a0d1-ba3cc19d2bef@github.com>

On Wed, 14 Sep 2022 18:13:40 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple code cleanup.
>> 
>> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
>> 
>> 
>>         if (k == null) {
>>             throw new InvalidKeyException("Empty key");
>>         }
>>         if (!isKeySizeValid(k.length)) {
>>              throw new InvalidKeyException("Invalid AES key length: " +
>>                                            k.length + " bytes");
>>         }
>> 
>> 
>> No new regression test, simple cleanup.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check only if necessary

Marked as reviewed by djelinski (Committer).

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

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

From djelinski at openjdk.org  Thu Sep 15 05:25:12 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Sep 2022 05:25:12 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <EPEK96reRJKSntfvLootmeJyJybxRkCEnC9G4_vgtjc=.7541b20d-2207-4e05-9078-abe83c396359@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
 <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
 <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>
 <UWGnoIPbVSr5D5KW6iuI0soIQELeQOxaGMaTSK57U0o=.d417a356-8c9a-441e-b71d-1a81478dd117@github.com>
 <QlIP7ZM3mnai3pp3V2VXVAkuV8MM818CkZPOOEHxnKw=.0e9f8f72-f9b8-419e-8a31-c337cbcf29ff@github.com>
 <EPEK96reRJKSntfvLootmeJyJybxRkCEnC9G4_vgtjc=.7541b20d-2207-4e05-9078-abe83c396359@github.com>
Message-ID: <bvi71vFimS3kEkrjsKsXSOC74x40FDPF_zO48VUku1g=.19dd730b-5c33-42b5-9365-a381876f1ecc@github.com>

On Thu, 15 Sep 2022 05:09:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> > Actually, NM, init still has to call MessageDigest.isEqual so eliminating keys of invalid length before that is probably more efficient.
>>> 
>>> The key should be valid for common cases. For valid key, it is more efficient to have the checking in makeSessionKey() as there is less checking. For invalid key, it is more efficient to have the checking before calling MessageDigest.isEqual(). Exception itself is costly, I would prefer to have better performance for common cases (valid key).
>>> 
>>> I updated the patch before I read the comment. Please let me know your preference. I'm fine to rollback if you prefer the old patch.
>> 
>> Yes, I think your current fix should be fine too. No need to rollback.
>
> Speaking of MessageDigest.isEqual, we don't need constant time comparison here. We could use Arrays.equals for some extra performance.

Actually, never mind that. We need constant time comparison to avoid leaking information about differences between old and new key. Sorry for the noise.

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

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

From xuelei at openjdk.org  Thu Sep 15 05:34:45 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 15 Sep 2022 05:34:45 GMT
Subject: RFR: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method [v3]
In-Reply-To: <bvi71vFimS3kEkrjsKsXSOC74x40FDPF_zO48VUku1g=.19dd730b-5c33-42b5-9365-a381876f1ecc@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
 <dRL2eCeqR_X67dFTItTKsYNL9jA7njlO1YkH47p6DRU=.2776b5e3-edd1-444d-88da-cb7e3c506f1e@github.com>
 <xUDpmtXHxEJGxlshdlDuva4QPW3_q7wfEBHBa8V5XVU=.4a0ce996-90c9-41dc-978d-1335b02a842e@github.com>
 <CVhTHweHBxoE-TQnf96ygVKivV3j7OGTmgBYzShGtFw=.2e90ce1d-bb18-4f80-8f16-f6cc599dfc6c@github.com>
 <DcBarYtEyPy3OlACP2cqCdsCGNQLZVs2DZlJZ6SNFN8=.dd95f4fe-5032-4607-a15e-1ea0000824a5@github.com>
 <VZ0b8j73m671JCydvxyPRWq21EhzNJDN9wOCofyP5HA=.18311791-4b63-40fa-b1be-f4e71473fd84@github.com>
 <UWGnoIPbVSr5D5KW6iuI0soIQELeQOxaGMaTSK57U0o=.d417a356-8c9a-441e-b71d-1a81478dd117@github.com>
 <QlIP7ZM3mnai3pp3V2VXVAkuV8MM818CkZPOOEHxnKw=.0e9f8f72-f9b8-419e-8a31-c337cbcf29ff@github.com>
 <EPEK96reRJKSntfvLootmeJyJybxRkCEnC9G4_vgtjc=.7541b20d-2207-4e05-9078-abe83c396359@github.com>
 <bvi71vFimS3kEkrjsKsXSOC74x40FDPF_zO48VUku1g=.19dd730b-5c33-42b5-9365-a381876f1ecc@github.com>
Message-ID: <NVElVGmn_qQWduaJAK6emD73B0bfDGScDIzTJcCVlKg=.75521800-968d-4ac4-94d3-b8fd47afee52@github.com>

On Thu, 15 Sep 2022 05:21:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Speaking of MessageDigest.isEqual, we don't need constant time comparison here. We could use Arrays.equals for some extra performance.
>
> Actually, never mind that. We need constant time comparison to avoid leaking information about differences between old and new key. Sorry for the noise.

@djelinski If both styles (w/o constant-time operations) get used in the code, it may take time to analysis the potential secret leaking issues for code readers until there is a clear comment.  As may add additional human and maintenance cost, which may be as expensive as the computer cost, especially when something goes wrong.  So normally, I prefer to constant-time operations for secret informations, no matter if the operations expose to attacking surfaces or not.  Just my $.02.

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

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

From mbaesken at openjdk.org  Thu Sep 15 08:19:23 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Sep 2022 08:19:23 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
Message-ID: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>

Currently we see on various Windows machines the following exception :
https://bugs.openjdk.org/browse/JDK-8293097

java.security.KeyStoreException: Access is denied.

This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.

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

Commit messages:
 - JDK-8293808

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

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

From weijun at openjdk.org  Thu Sep 15 13:02:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Sep 2022 13:02:46 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
In-Reply-To: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
Message-ID: <CSHa6z0cBfTPXBAg73IH4YW-PL9cH0y0O1shfeBt110=.55f2b995-a31f-48f4-8f84-87d9e9661cfe@github.com>

On Thu, 15 Sep 2022 08:11:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we see on various Windows machines the following exception :
> https://bugs.openjdk.org/browse/JDK-8293097
> 
> java.security.KeyStoreException: Access is denied.
> 
> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.

This is not a fix for the bug itself, therefore I suggest either create a new issue or create a subtask for this code change.

Also, how about we enhance the existing `ThrowException` function to include the error code in the output as well.

Finally, with this change, do you have more clues on the "Access is denied" problem?

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

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

From mbaesken at openjdk.org  Thu Sep 15 13:18:51 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Sep 2022 13:18:51 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
In-Reply-To: <CSHa6z0cBfTPXBAg73IH4YW-PL9cH0y0O1shfeBt110=.55f2b995-a31f-48f4-8f84-87d9e9661cfe@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <CSHa6z0cBfTPXBAg73IH4YW-PL9cH0y0O1shfeBt110=.55f2b995-a31f-48f4-8f84-87d9e9661cfe@github.com>
Message-ID: <pPojY00by4QpbxM1OR06R7RVHkm6jQBM3RzM8H3tijc=.267e3246-d6b7-4c7b-961a-2d45fd5dd3e5@github.com>

On Thu, 15 Sep 2022 12:58:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is not a fix for the bug itself, therefore I suggest either create a new issue or create a subtask for this code change.

Hi, this one is just for the better/more detailed exception .   For the real issue we still have JDK-8293097  .

> Also, how about we enhance the existing ThrowException function to include the error code in the output as well.

Sounds like a good idea.

> Finally, with this change, do you have more clues on the "Access is denied" problem?

Still not 100% sure whats happening there,  it might be related to some special properties or missing privileges of the user executing those tests.

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

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

From xuelei at openjdk.org  Thu Sep 15 15:10:53 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 15 Sep 2022 15:10:53 GMT
Subject: Integrated: 8293779: redundant checking in AESCrypt.makeSessionKey()
 method
In-Reply-To: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
References: <MYuT1CGbUp601NS0USqISRwpgkLmrDiMJwnq3Ha99DY=.af83acf9-0fb1-4380-8382-c9650bef8622@github.com>
Message-ID: <F1rFfgONcs6H-SzlHTrVtRD1jfAfbrT7dfAGS7S_0-I=.0178edae-05bd-432f-973c-4cf4742ee7cd@github.com>

On Wed, 14 Sep 2022 05:58:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple code cleanup.
> 
> The following checking for key in the makeSessionKey() method is redundant as it the same checking has been performance before calling the method.
> 
> 
>         if (k == null) {
>             throw new InvalidKeyException("Empty key");
>         }
>         if (!isKeySizeValid(k.length)) {
>              throw new InvalidKeyException("Invalid AES key length: " +
>                                            k.length + " bytes");
>         }
> 
> 
> No new regression test, simple cleanup.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: ecb456ae
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecb456ae29ac155c7f5632fbe5cfc4c0c5b5c959
Stats:     10 lines in 1 file changed: 1 ins; 4 del; 5 mod

8293779: redundant checking in AESCrypt.makeSessionKey() method

Reviewed-by: djelinski, hchao, mullan

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

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

From mpowers at openjdk.org  Thu Sep 15 16:27:10 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 15 Sep 2022 16:27:10 GMT
Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v9]
In-Reply-To: <kBfCmKK-5Xn3M5Zrpb9QCrVmIxctoUUB-A9PUl5HecQ=.14cdf42f-2256-4039-bcbd-92a777938e45@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
 <kBfCmKK-5Xn3M5Zrpb9QCrVmIxctoUUB-A9PUl5HecQ=.14cdf42f-2256-4039-bcbd-92a777938e45@github.com>
Message-ID: <W11XKssdt0OscFOMrtGhDyk6H2O5G0RroL0h2_47awU=.8c9ef230-391b-408d-80b1-a6145f62df04@github.com>

On Wed, 14 Sep 2022 23:15:29 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

Thanks Sean and Max for being tenacious reviewing this big set of changes.

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

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

From mpowers at openjdk.org  Thu Sep 15 18:25:40 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 15 Sep 2022 18:25:40 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <wmShyWSIfM6hC-PWRPCnYs1E1xpp1kDLmJztJ7I4nic=.cf4f3b7c-eb17-430c-8ffd-dc5f4386f86d@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <wmShyWSIfM6hC-PWRPCnYs1E1xpp1kDLmJztJ7I4nic=.cf4f3b7c-eb17-430c-8ffd-dc5f4386f86d@github.com>
Message-ID: <WpMI-P4Pke-Ox2JfkR2ZFrVQKCU3H5O0Jz2zMYCZ8TE=.634ec005-ec94-4430-9d3b-1ceeeecf243e@github.com>

On Tue, 13 Sep 2022 19:31:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> I would write a test which serializes the data (before your change) and deserializes it after. There should be some regression tests that already do that.

@seanjmullan There is an existing test which serializes and deserializes a `PrivateCredentialPermission` object. It only checks that the deserialized object is same as the original. There is no testing for new or deleted fields. The Java Serialization Spec indicates that the `testing` variable can be safely removed. This is only possible because the variable is `boolean` and is initialized to `false`. The CSR has more details. I have verified this behavior with a manual test of my own.

Are you suggesting that I write and integrate a new test that basically verifies that the Java Serialization Spec works as documented?

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

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

From mpowers at openjdk.org  Thu Sep 15 20:04:13 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 15 Sep 2022 20:04:13 GMT
Subject: Integrated: JDK-8291509 Minor cleanup could be done in sun.security
In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com>
Message-ID: <gGMt-g1LNoLHtmMUGhSb95ytELzSp17gC-8la6Yb-E0=.9a077635-d661-47d4-a82d-ece7a3e22ec5@github.com>

On Mon, 22 Aug 2022 21:45:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 4cec141a
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cec141a90bc5d3b8ec17c024291d9c74a112cd4
Stats:     3471 lines in 298 files changed: 217 ins; 829 del; 2425 mod

8291509: Minor cleanup could be done in sun.security

Reviewed-by: weijun

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

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

From weijun at openjdk.org  Thu Sep 15 20:08:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Sep 2022 20:08:05 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <ArKzTQLZ_aywoMYa7j51nLLywy9wdlM_49N2FPDsfCs=.766e3127-8789-4f41-94a7-487e1b3bf3f1@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

I've added my name as a reviewer of the CSR.

As for the test, I think it makes sense to serialize the object in an old JDK, hardcode the bytes in a new test and try to deserialize it, and make sure it equals to an object that is freshly constructed.

For the opposite direction, one can write a test in the JDK 17 repo that deserializes a byte array "from the future". This sounds fascinating but probably not worth doing.

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

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

From valeriep at openjdk.org  Thu Sep 15 22:33:13 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 15 Sep 2022 22:33:13 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <CNPQ-Eo2S8tq4yhrWm03qAep9Ct-6JZXxkTvN6_IbM8=.d4d592c8-eb74-4682-a61d-3b3aed6fb5a3@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <CNPQ-Eo2S8tq4yhrWm03qAep9Ct-6JZXxkTvN6_IbM8=.d4d592c8-eb74-4682-a61d-3b3aed6fb5a3@github.com>
Message-ID: <FA1n8idtfYhmhO342676oPq3PDcIVKeVvkR790Q64LA=.73b06736-1d1e-4832-885d-03172e2642d2@github.com>

On Fri, 9 Sep 2022 14:43:50 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> What happens when deserialization encounters a missing field like `testing`? Does it ignore it?

Have we tried this to know for sure that it is ignored? I think you should verify this by serializing w/o this "testing" field and de-serialize it with older releases. 
Never mind the above comment, I just saw your other comment that this has been verified.

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

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

From xuelei at openjdk.org  Fri Sep 16 00:45:22 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 16 Sep 2022 00:45:22 GMT
Subject: RFR: 8293886: The abstract keyword can be removed in AESCipher
Message-ID: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>

Hi,

Please review this simple fix for readability.

In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.

BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.

Thanks,
Xuelei

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

Commit messages:
 - update copyright year
 - 8293886: The abstract keyword can be removed in AESCipher

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

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

From mbaesken at openjdk.org  Fri Sep 16 07:28:47 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 07:28:47 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
In-Reply-To: <pPojY00by4QpbxM1OR06R7RVHkm6jQBM3RzM8H3tijc=.267e3246-d6b7-4c7b-961a-2d45fd5dd3e5@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <CSHa6z0cBfTPXBAg73IH4YW-PL9cH0y0O1shfeBt110=.55f2b995-a31f-48f4-8f84-87d9e9661cfe@github.com>
 <pPojY00by4QpbxM1OR06R7RVHkm6jQBM3RzM8H3tijc=.267e3246-d6b7-4c7b-961a-2d45fd5dd3e5@github.com>
Message-ID: <7MHf6s2ZkGGe4DXHt2OwSP_4H8Qj8lT-a8H6ZnBf7sY=.c547210c-4809-40f2-8477-cb885dd207d5@github.com>

On Thu, 15 Sep 2022 13:16:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>Still not 100% sure whats happening there, it might be related to some special properties or missing privileges of the user >executing those tests.

After looking into a number of logs it looks more and more like some crappy (or awfully configured?)  "security product"  causes these  "Access is denied" problems on a number of our Windows test machines.

Having a detailed error message is of course good in this case , but it won't (and probably can't) tell you the reason / root cause of the issue.

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

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

From mbaesken at openjdk.org  Fri Sep 16 07:43:00 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 07:43:00 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v2]
In-Reply-To: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
Message-ID: <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>

> Currently we see on various Windows machines the following exception :
> https://bugs.openjdk.org/browse/JDK-8293097
> 
> java.security.KeyStoreException: Access is denied.
> 
> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add errcode output to ThrowException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10280/files
  - new: https://git.openjdk.org/jdk/pull/10280/files/0dd4bcdc..edeaaefa

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

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

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

From weijun at openjdk.org  Fri Sep 16 12:56:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Sep 2022 12:56:40 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
In-Reply-To: <pPojY00by4QpbxM1OR06R7RVHkm6jQBM3RzM8H3tijc=.267e3246-d6b7-4c7b-961a-2d45fd5dd3e5@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <CSHa6z0cBfTPXBAg73IH4YW-PL9cH0y0O1shfeBt110=.55f2b995-a31f-48f4-8f84-87d9e9661cfe@github.com>
 <pPojY00by4QpbxM1OR06R7RVHkm6jQBM3RzM8H3tijc=.267e3246-d6b7-4c7b-961a-2d45fd5dd3e5@github.com>
Message-ID: <dFuEItkkeui5jXTj7PYWwNq_stDioJU2rO_AebupqhQ=.cdb5316e-537d-40fb-ab8b-aaacc65f2f88@github.com>

On Thu, 15 Sep 2022 13:16:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > This is not a fix for the bug itself, therefore I suggest either create a new issue or create a subtask for this code change.
> 
> Hi, this one is just for the better/more detailed exception . For the real issue we still have JDK-8293097 .
> 

I see. Sorry.

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

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

From weijun at openjdk.org  Fri Sep 16 13:01:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Sep 2022 13:01:44 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
In-Reply-To: <7MHf6s2ZkGGe4DXHt2OwSP_4H8Qj8lT-a8H6ZnBf7sY=.c547210c-4809-40f2-8477-cb885dd207d5@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <CSHa6z0cBfTPXBAg73IH4YW-PL9cH0y0O1shfeBt110=.55f2b995-a31f-48f4-8f84-87d9e9661cfe@github.com>
 <pPojY00by4QpbxM1OR06R7RVHkm6jQBM3RzM8H3tijc=.267e3246-d6b7-4c7b-961a-2d45fd5dd3e5@github.com>
 <7MHf6s2ZkGGe4DXHt2OwSP_4H8Qj8lT-a8H6ZnBf7sY=.c547210c-4809-40f2-8477-cb885dd207d5@github.com>
Message-ID: <O8QmObFZMGQV5bjKrcjHMTEE6Ju3Q4oDKlhwAT64Ic4=.13def0e7-23a6-443f-ba61-ec8040965f8f@github.com>

On Fri, 16 Sep 2022 07:26:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After looking into a number of logs it looks more and more like some crappy (or awfully configured?) "security product" causes these "Access is denied" problems on a number of our Windows test machines.

Is it possible to find a Windows command that tries to do something similar and shows the same error? If yes, then it's safe to say it's not an issue in JDK and we may even be able to add more info in the exception message.

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

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

From weijun at openjdk.org  Fri Sep 16 13:01:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Sep 2022 13:01:43 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v2]
In-Reply-To: <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
Message-ID: <c70VhSftn3EOTIOKqNqVmfqA8-6uud0Bi9iGUYw8OKw=.83c1feae-b992-4b7a-8b1c-5c0326678ef7@github.com>

On Fri, 16 Sep 2022 07:43:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we see on various Windows machines the following exception :
>> https://bugs.openjdk.org/browse/JDK-8293097
>> 
>> java.security.KeyStoreException: Access is denied.
>> 
>> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add errcode output to ThrowException

Marked as reviewed by weijun (Reviewer).

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

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

From mbaesken at openjdk.org  Fri Sep 16 13:28:42 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 13:28:42 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v2]
In-Reply-To: <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
Message-ID: <rGPJyiz6qnkWaaYpffc7rJNB0eVicFgdJVRYOQkEgH4=.75c6886c-00f5-43dc-ad0c-b1e20a41b5f8@github.com>

On Fri, 16 Sep 2022 07:43:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we see on various Windows machines the following exception :
>> https://bugs.openjdk.org/browse/JDK-8293097
>> 
>> java.security.KeyStoreException: Access is denied.
>> 
>> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add errcode output to ThrowException

Thanks for the review !

> ...we may even be able to add more info in the exception message.

Unfortunately the "Access denied"  can show up also in other situations like missing permissions etc. of the user running the JDK so it is not completely clear what it means. Regarding "finding a Windows tool" showing the same issues, so far I am not aware of one unfortunately.

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

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

From weijun at openjdk.org  Fri Sep 16 13:32:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Sep 2022 13:32:42 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v2]
In-Reply-To: <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
Message-ID: <b_64Wa7sliu6eeiBpAfGzS6FvNovegjVAQSAaniIcfg=.701039d7-eb7d-4051-847c-c3f3923c22bb@github.com>

On Fri, 16 Sep 2022 07:43:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we see on various Windows machines the following exception :
>> https://bugs.openjdk.org/browse/JDK-8293097
>> 
>> java.security.KeyStoreException: Access is denied.
>> 
>> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add errcode output to ThrowException

Oops, find an issue. `msg` on line 165 is not defined.

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

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

From alanb at openjdk.org  Fri Sep 16 13:34:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 13:34:48 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
Message-ID: <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>

On Wed, 14 Sep 2022 16:43:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address latest input regarding wording

src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:

> 42:  * The {@link #getManifest} method will return the {@code Manifest} when it is
> 43:  * the first entry in the stream, or {@code META-INF/} is the first entry and
> 44:  * the {@code Manifest} is the second entry within the stream.

"within the stream" should probably be "in the stream" to be consistent the first part of the sentence.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:

> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
> 50:  * also not be returned by {@link #getNextEntry()} and
> 51:  * {@link #getNextJarEntry()}.

JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:

> 76:  *  the signers.
> 77:  * <p>
> 78:  * <b>Note:</b> If a {@code JarEntry} is modified after the JAR file is signed,

Can this be an apiNote?

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

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

From weijun at openjdk.org  Fri Sep 16 13:37:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Sep 2022 13:37:46 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v2]
In-Reply-To: <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
Message-ID: <h42Q71w-8fKZDezxhhHidElo0FyrE8Uzj_P06dlbPrE=.611fd3e1-2ed6-4dd3-a1ac-389ca416fc6d@github.com>

On Fri, 16 Sep 2022 07:43:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we see on various Windows machines the following exception :
>> https://bugs.openjdk.org/browse/JDK-8293097
>> 
>> java.security.KeyStoreException: Access is denied.
>> 
>> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add errcode output to ThrowException

Changes requested by weijun (Reviewer).

src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 165:

> 163:         strcpy(szMessage, "Unknown error");
> 164:     }
> 165:     snprintf(szMessage2, sizeof(szMessage2), "error %lu, %s", msg, dwError, szMessage);

`msg` is from nowhere.

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

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

From mbaesken at openjdk.org  Fri Sep 16 14:30:40 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 14:30:40 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v3]
In-Reply-To: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
Message-ID: <GV8idyMUD1wIUo7z_tQHt-LsfErFHhMYCU046v5BLR8=.90eb3938-142d-47b1-a183-7d693817aae9@github.com>

> Currently we see on various Windows machines the following exception :
> https://bugs.openjdk.org/browse/JDK-8293097
> 
> java.security.KeyStoreException: Access is denied.
> 
> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove msg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10280/files
  - new: https://git.openjdk.org/jdk/pull/10280/files/edeaaefa..b909aa64

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

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

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

From mbaesken at openjdk.org  Fri Sep 16 14:30:44 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 14:30:44 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v2]
In-Reply-To: <h42Q71w-8fKZDezxhhHidElo0FyrE8Uzj_P06dlbPrE=.611fd3e1-2ed6-4dd3-a1ac-389ca416fc6d@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <IEZimCPAWjGKwZ5rL8zj2CmUhU6aFJxnCwf0xz9yJRI=.0171dd90-d507-4965-a660-550eec5980d9@github.com>
 <h42Q71w-8fKZDezxhhHidElo0FyrE8Uzj_P06dlbPrE=.611fd3e1-2ed6-4dd3-a1ac-389ca416fc6d@github.com>
Message-ID: <jKBncJ9f7PdckWq_ERZFEt68xeGWCuRqeU9XlYwMi8k=.f144168e-934c-4e6e-bb9b-f2aca31cb222@github.com>

On Fri, 16 Sep 2022 13:33:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add errcode output to ThrowException
>
> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 165:
> 
>> 163:         strcpy(szMessage, "Unknown error");
>> 164:     }
>> 165:     snprintf(szMessage2, sizeof(szMessage2), "error %lu, %s", msg, dwError, szMessage);
> 
> `msg` is from nowhere.

Sorry, had to remove msg you are correct of course ...

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

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

From weijun at openjdk.org  Fri Sep 16 14:52:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Sep 2022 14:52:42 GMT
Subject: RFR: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception [v3]
In-Reply-To: <GV8idyMUD1wIUo7z_tQHt-LsfErFHhMYCU046v5BLR8=.90eb3938-142d-47b1-a183-7d693817aae9@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
 <GV8idyMUD1wIUo7z_tQHt-LsfErFHhMYCU046v5BLR8=.90eb3938-142d-47b1-a183-7d693817aae9@github.com>
Message-ID: <rDdi8nK5xIb44KZcR0-Oc2DumAOurV59xmXgzsAFTXE=.bbba5631-fcec-42b4-bfe9-19c0b2a74190@github.com>

On Fri, 16 Sep 2022 14:30:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we see on various Windows machines the following exception :
>> https://bugs.openjdk.org/browse/JDK-8293097
>> 
>> java.security.KeyStoreException: Access is denied.
>> 
>> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove msg

Looks good to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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

From lancea at openjdk.org  Fri Sep 16 16:20:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 16:20:41 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v5]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <g0ssx4ma6ABj_3rZdRwc38kZL-oCQ2qbGrEzZo9Slv4=.a3732275-2f7d-4a5e-8a01-da69b06fc2f1@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address additional javadoc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/10ddfd31..6d7795fe

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

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

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

From lancea at openjdk.org  Fri Sep 16 16:20:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 16:20:45 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
Message-ID: <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>

On Fri, 16 Sep 2022 13:06:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address latest input regarding wording
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:
> 
>> 42:  * The {@link #getManifest} method will return the {@code Manifest} when it is
>> 43:  * the first entry in the stream, or {@code META-INF/} is the first entry and
>> 44:  * the {@code Manifest} is the second entry within the stream.
> 
> "within the stream" should probably be "in the stream" to be consistent the first part of the sentence.

Updated as you suggested

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:
> 
>> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
>> 50:  * also not be returned by {@link #getNextEntry()} and
>> 51:  * {@link #getNextJarEntry()}.
> 
> JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.

I tend to agree but am reluctant to change 20+ year behavior via this PR as we don't know what we don't know.

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
> 
>> 76:  *  the signers.
>> 77:  * <p>
>> 78:  * <b>Note:</b> If a {@code JarEntry} is modified after the JAR file is signed,
> 
> Can this be an apiNote?

Sure Updated as suggested

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

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

From alanb at openjdk.org  Fri Sep 16 18:03:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 18:03:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
Message-ID: <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>

On Fri, 16 Sep 2022 16:15:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:
>> 
>>> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
>>> 50:  * also not be returned by {@link #getNextEntry()} and
>>> 51:  * {@link #getNextJarEntry()}.
>> 
>> JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.
>
> I tend to agree but am reluctant to change 20+ year behavior via this PR as we don't know what we don't know.

Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.

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

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

From lancea at openjdk.org  Fri Sep 16 18:37:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 18:37:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
 <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
Message-ID: <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>

On Fri, 16 Sep 2022 18:01:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.

Is this any better:



 * <p>
 * When the {@code Manifest} is returned by {@code getManifest()}, the {@link #getNextEntry()}
 * and {@link #getNextJarEntry()} methods will not return the {@code Manifest}.
 * If {@code META-INF/} is the first entry in the input stream it will be
 * also not be returned by {@link #getNextEntry()} and {@link #getNextJarEntry()}. 
 * </p>
 * @apiNote 
 * It is unspecified whether {@link #getNextEntry()} and
 * {@link #getNextJarEntry()} will return the {@code Manifest}
 * when the {@code Manifest} occurs later in the input stream.
 * <p>
 * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
 *  attributes for the current JAR file entry, if any, providing
 *  {@code getManifest()} returns a {@code Manifest} for the JAR file.
 * </p>

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

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

From alanb at openjdk.org  Sat Sep 17 08:07:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Sep 2022 08:07:51 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
 <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
 <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>
Message-ID: <XFNQ2uRsRfcC9H3eyjfdGsljPN8CiSaFQdpGCzKt48c=.806e8a99-33f1-4f2d-944c-cdd90c00dbb0@github.com>

On Fri, 16 Sep 2022 18:33:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.
>
>> Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.
> 
> Is this any better:
> 
> 
> 
>  * <p>
>  * When the {@code Manifest} is returned by {@code getManifest()}, the {@link #getNextEntry()}
>  * and {@link #getNextJarEntry()} methods will not return the {@code Manifest}.
>  * If {@code META-INF/} is the first entry in the input stream it will be
>  * also not be returned by {@link #getNextEntry()} and {@link #getNextJarEntry()}. 
>  * </p>
>  * @apiNote 
>  * It is unspecified whether {@link #getNextEntry()} and
>  * {@link #getNextJarEntry()} will return the {@code Manifest}
>  * when the {@code Manifest} occurs later in the input stream.
>  * <p>
>  * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
>  *  attributes for the current JAR file entry, if any, providing
>  *  {@code getManifest()} returns a {@code Manifest} for the JAR file.
>  * </p>

It's a bit better but I think we can make it clearer and also link the JAR Manifest section of the JAR file spec.  Can you try this:


 * <p> The {@link #getManifest() getManifest} method is used to read the
 * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
 * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
 * in the stream (or the second entry in the case that the fist entry is
 * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
 *
 * <p> The {@link #getNextJarEntry()} and {@link #getNextEntry()} methods are
 * used to read JAR file entries from the stream. These methods skip over the
 * manifest ({@code META-INF/MANIFEST.MF}) when it is at the beginning of the
 * stream. In other words, these methods do not return an entry for the manifest
 * when the manifest is the first entry in the stream. If the first entry is
 * {@code META-INF/} and the second entry is the manifest then both are skipped
 * over by these methods. Whether these methods skip over the manifest when it
 * appears later in the stream is not specified.


I think we also have to update getManifest method to align with the above as doesn't say anything about the manifest needing to be at the beginning of the stream.

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

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

From lancea at openjdk.org  Sat Sep 17 14:35:46 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 17 Sep 2022 14:35:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated latest round of input

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/6d7795fe..a0b7ae03

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

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

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

From lancea at openjdk.org  Sat Sep 17 14:38:29 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 17 Sep 2022 14:38:29 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <XFNQ2uRsRfcC9H3eyjfdGsljPN8CiSaFQdpGCzKt48c=.806e8a99-33f1-4f2d-944c-cdd90c00dbb0@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
 <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
 <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>
 <XFNQ2uRsRfcC9H3eyjfdGsljPN8CiSaFQdpGCzKt48c=.806e8a99-33f1-4f2d-944c-cdd90c00dbb0@github.com>
Message-ID: <zrsQZbDwyP9hUsuekkM1801siREc1kEFhOtgbINmogE=.85d4526b-2fb1-4038-bfb6-8891cc0f7338@github.com>

On Sat, 17 Sep 2022 08:05:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's a bit better but I think we can make it clearer and also link the JAR Manifest section of the JAR file spec. Can you try this:
> 
> ```
>  * <p> The {@link #getManifest() getManifest} method is used to read the
>  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
>  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
>  * in the stream (or the second entry in the case that the fist entry is
>  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
>  *
>  * <p> The {@link #getNextJarEntry()} and {@link #getNextEntry()} methods are
>  * used to read JAR file entries from the stream. These methods skip over the
>  * manifest ({@code META-INF/MANIFEST.MF}) when it is at the beginning of the
>  * stream. In other words, these methods do not return an entry for the manifest
>  * when the manifest is the first entry in the stream. If the first entry is
>  * {@code META-INF/} and the second entry is the manifest then both are skipped
>  * over by these methods. Whether these methods skip over the manifest when it
>  * appears later in the stream is not specified.
> ```
> 
Revised using the above

> I think we also have to update getManifest method to align with the above as doesn't say anything about the manifest needing to be at the beginning of the stream.

Ok,  I added some verbiage similar to what I had originally before we decided to update the class description.  Please let me know if this is what you had in mind

Thank you again for your feedback

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

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

From alanb at openjdk.org  Sun Sep 18 19:55:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 18 Sep 2022 19:55:03 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
Message-ID: <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>

On Sat, 17 Sep 2022 14:35:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated latest round of input

src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:

> 34:  * The {@code JarInputStream} class, which extends {@link ZipInputStream},
> 35:  * is used to read the contents of a JAR file from an input stream.
> 36:  * It provides support for reading an optional {@link JarFile#MANIFEST_NAME Manifest}

What would you think about linking this to {@docRoot}/../specs/jar/jar.html#jar-manifest rather tan JarFile#MANIFEST_NAME?

src/java.base/share/classes/java/util/jar/JarInputStream.java line 60:

> 58:  * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
> 59:  *  attributes for the current JAR file entry, if any, providing
> 60:  *  {@code getManifest()} returns a {@code Manifest} for the JAR file.

Per-entry attributes is an advanced feature to attempt to bring into the class description. I think it would be simpler to just drop this paragraph. If you really want something on this topic then it would require first describing main vs. per entry attributes and then explaining that the per-entry attributes are obtained with JarEntry::getAttributes when the manifest is at the beginning of the stream.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 157:

> 155:      *
> 156:      * @return the {@code Manifest} for this JAR file when accessible, or
> 157:      *         {@code null} otherwise.

The word "accessible" suggests there is access control in the picture so I think drop that word. Maybe just drop "if none" from the original return description?

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

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

From lancea at openjdk.org  Sun Sep 18 20:37:43 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 18 Sep 2022 20:37:43 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
Message-ID: <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>

On Sun, 18 Sep 2022 19:49:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated latest round of input
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
> 
>> 34:  * The {@code JarInputStream} class, which extends {@link ZipInputStream},
>> 35:  * is used to read the contents of a JAR file from an input stream.
>> 36:  * It provides support for reading an optional {@link JarFile#MANIFEST_NAME Manifest}
> 
> What would you think about linking this to {@docRoot}/../specs/jar/jar.html#jar-manifest rather tan JarFile#MANIFEST_NAME?

Sure if that is your preference.

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 60:
> 
>> 58:  * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
>> 59:  *  attributes for the current JAR file entry, if any, providing
>> 60:  *  {@code getManifest()} returns a {@code Manifest} for the JAR file.
> 
> Per-entry attributes is an advanced feature to attempt to bring into the class description. I think it would be simpler to just drop this paragraph. If you really want something on this topic then it would require first describing main vs. per entry attributes and then explaining that the per-entry attributes are obtained with JarEntry::getAttributes when the manifest is at the beginning of the stream.

I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO.  I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 157:
> 
>> 155:      *
>> 156:      * @return the {@code Manifest} for this JAR file when accessible, or
>> 157:      *         {@code null} otherwise.
> 
> The word "accessible" suggests there is access control in the picture so I think drop that word. Maybe just drop "if none" from the original return description?

Will change as you suggest

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

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

From lancea at openjdk.org  Sun Sep 18 20:43:25 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 18 Sep 2022 20:43:25 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updated to address latest feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/a0b7ae03..c16e5bb8

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

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

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

From alanb at openjdk.org  Mon Sep 19 06:37:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 06:37:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
Message-ID: <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>

On Sun, 18 Sep 2022 20:33:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.

Wording it is hard. The draft wording made it look  that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..

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

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

From alanb at openjdk.org  Mon Sep 19 06:48:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 06:48:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
Message-ID: <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>

On Sun, 18 Sep 2022 20:43:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to address latest feedback

src/java.base/share/classes/java/util/jar/JarInputStream.java line 60:

> 58:  *
> 59:  *  <h2>Verifying a JarInputStream</h2>
> 60:  *  {@link #JarInputStream(InputStream, boolean)} may be used to

I realise you've had a few iterations with Max on this section but I'm concerned that the text is telling the reader that they should use the 2-arg constructor to verify the signatures when a JAR is signed. The default is to verify and the a reason to use the 2-arg constructor is when you want to opt out, not opt-in.

I think the intro to this section will need to start with a sentence to say that JAR files can be signed (link to specs/jar/jar.html#signed-jar-file) and that JarInputStream can read a signed JAR from the input stream. As per the description further up, the manifest must be at the start of the stream.

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

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

From mbaesken at openjdk.org  Mon Sep 19 07:42:18 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Sep 2022 07:42:18 GMT
Subject: Integrated: JDK-8293808: mscapi destroyKeyContainer enhance
 KeyStoreException: Access is denied exception
In-Reply-To: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
References: <qJ67dfnZagK2fN1cJHGVYSE7dSe7T8ckVUOrimloN48=.0ad7e4ab-4356-4dc4-a933-b505175ace84@github.com>
Message-ID: <59U753vrWaPCxbm-sr0cykRkLerZQ8vaDVRh4OSrjes=.d8401ebf-423f-4b13-aeac-23d7863378b4@github.com>

On Thu, 15 Sep 2022 08:11:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we see on various Windows machines the following exception :
> https://bugs.openjdk.org/browse/JDK-8293097
> 
> java.security.KeyStoreException: Access is denied.
> 
> This should probably be enhanced a bit so that the exception tell us more about what went wrong exactly.

This pull request has now been integrated.

Changeset: 36c9034f
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36c9034ff1274f37969550a3f9239f1bb16a0b25
Stats:     26 lines in 1 file changed: 21 ins; 1 del; 4 mod

8293808: mscapi destroyKeyContainer enhance KeyStoreException: Access is denied exception

Reviewed-by: weijun

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

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

From lancea at openjdk.org  Mon Sep 19 10:23:47 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 10:23:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
Message-ID: <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>

On Mon, 19 Sep 2022 06:45:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I realise you've had a few iterations with Max on this section but I'm concerned that the text is telling the reader that they should use the 2-arg constructor to verify the signatures when a JAR is signed. The default is to verify and the main reason to use the 2-arg constructor is when you want to opt out, not opt-in.
> 
> I think the intro to this section will need to start with a sentence to say that JAR files can be signed (link to specs/jar/jar.html#signed-jar-file) and that JarInputStream can read a signed JAR from the input stream. As per the description further up, the manifest must be at the start of the stream.

OK, will make another pass at this today

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

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

From mullan at openjdk.org  Mon Sep 19 12:18:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 19 Sep 2022 12:18:43 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <ejhjgEoZEAud8eR_a_TiIBtMK0sPKhL2CE8fBTklyXg=.e120a898-da08-4e95-9562-d0e88b4a9741@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Looks good.

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

Marked as reviewed by mullan (Reviewer).

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

From jpai at openjdk.org  Mon Sep 19 13:38:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Sep 2022 13:38:07 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <wLSCRqjYZ6sQ4ALPzSJC5sU4aN0J6MA5sT0egSLgceY=.f68859ca-3a00-4953-b451-5e07bb960001@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

The failures reported in the GitHub Actions job look related to this change - `jdk.jfr.event.metadata.TestDefaultConfigurations` test appears to be failing:


java.lang.Exception: Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'default'
Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'profile'

	at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:115)
	at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:76)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)

JavaTest Message: Test threw exception: java.lang.Exception: Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'default'
Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'profile'

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:

> 30: 
> 31: import jdk.jfr.Event;
> 32: import jdk.jfr.events.*;

Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones?

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

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

From egahlin at openjdk.org  Mon Sep 19 13:45:09 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Sep 2022 13:45:09 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <JAvq0QxlwoUmW_xsMGY_WeQ0SKcniEymy68ZmdrKexg=.2c025b74-e1ae-48f5-acb8-c7cd15804f7b@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

I noticed that the event is disabled by default.

Is it because of concerns of too many events, or too much overhead? Or something else?

I think we should strive to have events always on. Few users will take the time to learn about the event and enable it. Usage will probably drop by 99%, if not enabled by default.

If concerns are performance related, there might be other event designs that could be used, for example, a periodic event that is always enabled.

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

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

From jpai at openjdk.org  Mon Sep 19 14:29:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Sep 2022 14:29:52 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

src/java.base/share/classes/java/security/Provider.java line 1293:

> 1291:         }
> 1292: 
> 1293:         if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {

Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture  that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null?

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

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

From coffeys at openjdk.org  Mon Sep 19 15:25:46 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:25:46 GMT
Subject: Integrated: 8292297: Fix up loading of override java.security
 properties file
In-Reply-To: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
References: <KAB8klQ1bHVqmfxksCG6Kz0RTmZN6jQsevPQSvx5pXI=.904ea53e-192a-45a0-9cc3-525aed0d949b@github.com>
Message-ID: <Ivq-gnVeu4FX2JNAhrQqrSyFuxjYA3innaBEd9_3vQY=.8b15bdeb-ce69-4939-95b4-bfbc5bf03deb@github.com>

On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Ensure that security properties are only overridden if the override security properties file exists. 
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.

This pull request has now been integrated.

Changeset: 1f9ff413
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f9ff413126fb68e07b8fc1f36dd3cb17093a484
Stats:     165 lines in 3 files changed: 69 ins; 70 del; 26 mod

8292297: Fix up loading of override java.security properties file

Reviewed-by: xuelei

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

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

From coffeys at openjdk.org  Mon Sep 19 15:45:50 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:45:50 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
Message-ID: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>

On Mon, 19 Sep 2022 14:25:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.
>
> src/java.base/share/classes/java/security/Provider.java line 1293:
> 
>> 1291:         }
>> 1292: 
>> 1293:         if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {
> 
> Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture  that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null?

I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order.

> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:
> 
>> 30: 
>> 31: import jdk.jfr.Event;
>> 32: import jdk.jfr.events.*;
> 
> Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones?

This was formatted via IDE. Seems like you've a preference to use the more verbose import style. I'll revert this change.

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

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

From coffeys at openjdk.org  Mon Sep 19 15:45:51 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:45:51 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
Message-ID: <GLm2s8J0vKM6eo0KoS4OjFGrwIHXyQwI0gW9WeJOW34=.f5fdf42a-6992-4c10-b73d-fbe03d19f24b@github.com>

On Mon, 19 Sep 2022 15:27:05 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:
>> 
>>> 30: 
>>> 31: import jdk.jfr.Event;
>>> 32: import jdk.jfr.events.*;
>> 
>> Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones?
>
> This was formatted via IDE. Seems like you've a preference to use the more verbose import style. I'll revert this change.

Thanks for pointing out that test issue also. I missed it. I'll push a minor edit to correct.

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

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

From coffeys at openjdk.org  Mon Sep 19 15:48:55 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:48:55 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <ARMnQasC6jHBtxbxSUDHRVtU65NXNUpKSZbf9HCuluU=.89bc857c-ceed-4365-9960-513eb26343da@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

> 

This new event is disabled by default just like the other crypto related events that were added some time back (e.g. `TLSHandshakeEvent`). My assumption is that these events will be enabled for audit mode when one is interested in finding out what their crypto operations looks like. Periodic events are good but for such operations I think it's critical that we capture all such crypto calls to ensure that admins get a good picture of what's been used/called. 

Perhaps we can have a discussion about whether such JDK events should be on by default and work the issue via another JBS issue. `jdk.Deserialization` is another example of a JDK level event that's off by default.

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

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

From mullan at openjdk.org  Mon Sep 19 15:55:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 19 Sep 2022 15:55:46 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
Message-ID: <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>

On Mon, 19 Sep 2022 15:25:43 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Provider.java line 1293:
>> 
>>> 1291:         }
>>> 1292: 
>>> 1293:         if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {
>> 
>> Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture  that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null?
>
> I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order.

Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer.

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

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

From coffeys at openjdk.org  Mon Sep 19 16:12:18 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 16:12:18 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  update from review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9657/files
  - new: https://git.openjdk.org/jdk/pull/9657/files/aab692b2..e168152f

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

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

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

From egahlin at openjdk.org  Mon Sep 19 16:25:44 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Sep 2022 16:25:44 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <ARMnQasC6jHBtxbxSUDHRVtU65NXNUpKSZbf9HCuluU=.89bc857c-ceed-4365-9960-513eb26343da@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <ARMnQasC6jHBtxbxSUDHRVtU65NXNUpKSZbf9HCuluU=.89bc857c-ceed-4365-9960-513eb26343da@github.com>
Message-ID: <cKneYaBdWbW7-e2pkHa9K6j74BcTSSm_j1ZeD3W8ZCk=.ba9cca57-a107-43f1-9fe4-769a1c54a11a@github.com>

On Mon, 19 Sep 2022 15:46:46 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> This new event is disabled by default just like the other crypto related events that were added some time back (e.g. `TLSHandshakeEvent`). My assumption is that these events will be enabled for audit mode when one is interested in finding out what their crypto operations looks like. Periodic events are good but for such operations I think it's critical that we capture all such crypto calls to ensure that admins get a good picture of what's been used/called.

I remember we had this discussion a few years back and maybe we need both? Some events for audits and some that can be detected by the JMC rules engine in a normal recording?

Perhaps it's time to introduce a parameterized setting, similar to what we have for GC and compiler, where user can specify levels. From JDK 17, they can be specified on command line, i.e. 

$ java -XX:StartFlightRecording:security=off/normal/debug/audit 

This would lower the bar and make the events useful to more people.

We can do this in another JBS issue.

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

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

From valeriep at openjdk.org  Mon Sep 19 16:45:45 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 16:45:45 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
 <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
Message-ID: <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>

On Mon, 19 Sep 2022 15:52:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order.
>
> Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer.

Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying.
Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately?

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

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

From coffeys at openjdk.org  Mon Sep 19 16:58:43 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 16:58:43 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
 <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
 <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>
Message-ID: <yhwL4gvGc1JzRzySXPoC5D_-F79QyHbTfqqqclP97bI=.05296d6e-2a00-49a1-9a6b-ff1d16e999c9@github.com>

On Mon, 19 Sep 2022 16:43:26 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer.
>
> Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying.
> Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately?

Let's stick to just recording events where a match on service and provider is made then.

The expectation is that analysis would be done post recording. Probably best to reduce the runtime performance impact.

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

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

From shade at openjdk.org  Mon Sep 19 17:09:27 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 17:09:27 GMT
Subject: RFR: 8279941: sun/security/pkcs11/Signature/TestDSAKeyLength.java
 fails when NSS version detection fails
Message-ID: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>

The test helpers try to identify NSS version by parsing the relevant `.so` files (!) looking for "Version: ..." string. This fails at least on Ubuntu 22.04, where the NSS does not have any version-identifiable strings. In this case, the test "detects" version as `0.0` and then fails. After brief discussion in the bug, the best fix is to ignore `0.0` as well.

Additional testing: 
 - [x] Linux x86_64 fastdebug, affected test now skipped on Ubuntu 22.04

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

Commit messages:
 - Fix

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

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

From lancea at openjdk.org  Mon Sep 19 17:25:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 17:25:53 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v8]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Minor clarification for verifying an JarInputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/c16e5bb8..bd4e0005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=06-07

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

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

From valeriep at openjdk.org  Mon Sep 19 17:35:41 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 17:35:41 GMT
Subject: RFR: 8279941: sun/security/pkcs11/Signature/TestDSAKeyLength.java
 fails when NSS version detection fails
In-Reply-To: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
References: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
Message-ID: <5hFM4_XQfF5Q569-hnf06BGewZHeaKkPpv9ZMEOz4Zw=.5834eda0-4353-4088-bc66-df2815280ed4@github.com>

On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The test helpers try to identify NSS version by parsing the relevant `.so` files (!) looking for "Version: ..." string. This fails at least on Ubuntu 22.04, where the NSS does not have any version-identifiable strings. In this case, the test "detects" version as `0.0` and then fails. After brief discussion in the bug, the best fix is to ignore `0.0` as well.
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, affected test now skipped on Ubuntu 22.04

Looks good.

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

Marked as reviewed by valeriep (Reviewer).

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

From valeriep at openjdk.org  Mon Sep 19 17:39:47 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 17:39:47 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
Message-ID: <G8cpKmx4jI2uamg9ssS2ldVMtoDoH6dEuBFPWLXCHto=.e841a94e-037e-4073-9fcc-e3bf909eec1c@github.com>

On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update from review comments

The java.base part of changes look good.

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

Marked as reviewed by valeriep (Reviewer).

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

From mpowers at openjdk.org  Mon Sep 19 17:45:51 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 19 Sep 2022 17:45:51 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <Bp2sB5_nBNHTs1D5QWariNNmQP1-uB1HXUIUJ66TaW8=.d8eda61d-c52e-40c9-93be-867177fa1076@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

I wrote a test to deserialize an object created and serialized before the fix. I compare the old object with the current object after the fix. What is important is not the comparison, but that deserialization doesn't throw an exception.

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

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

From mpowers at openjdk.org  Mon Sep 19 17:54:57 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 19 Sep 2022 17:54:57 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>

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

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

  added test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10206/files
  - new: https://git.openjdk.org/jdk/pull/10206/files/04fda021..a8e304d1

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

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

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

From valeriep at openjdk.org  Mon Sep 19 17:54:57 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 17:54:57 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging
In-Reply-To: <Bp2sB5_nBNHTs1D5QWariNNmQP1-uB1HXUIUJ66TaW8=.d8eda61d-c52e-40c9-93be-867177fa1076@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Bp2sB5_nBNHTs1D5QWariNNmQP1-uB1HXUIUJ66TaW8=.d8eda61d-c52e-40c9-93be-867177fa1076@github.com>
Message-ID: <pEMs0-jJW98iKGm5NIYRv8ZDFext-h0FY9_Rm5jbBmo=.e08a1662-e642-4004-a5c1-07782f939e41@github.com>

On Mon, 19 Sep 2022 17:43:35 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> I wrote a test to deserialize an object created and serialized before the fix. I compare the old object with the current object after the fix. What is important is not the comparison, but that deserialization doesn't throw an exception.

Does both de-serialization pass, i.e. deserialize the new bytes using old release and deserializing the old bytes using new release?

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

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

From lancea at openjdk.org  Mon Sep 19 17:55:59 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 17:55:59 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
 <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
Message-ID: <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>

On Mon, 19 Sep 2022 06:34:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
> 
> Wording it is hard. The draft wording made it look that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..

Thinking about this some more, would the following be any better:


 * <p>
 * The {@code Manifest} for a JAR file may include
 *  <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
 *  <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
 *  attributes. {@link JarEntry#getAttributes()} will return the per entry
 *  attributes for the current JAR file entry, if any, providing
 *  {@code getManifest()} returns the {@code Manifest} for the JAR file.
 *  </p>

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

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

From mpowers at openjdk.org  Mon Sep 19 18:13:44 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 19 Sep 2022 18:13:44 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
Message-ID: <R9YoH0tRqfqN_1Cdn9mx2OByISK0OIodBjLrlG_N30k=.f7cfb8fd-dec6-42a3-83ea-117b2ff49fd6@github.com>

On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

I tested old bytes on new release. It passes. I didn't test new bytes on an old release because of Max's "from the future" comment. Honestly, I'm not sure what any of this testing proves. Maybe that the Java Object Serialization Specification isn't broken?

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

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

From weijun at openjdk.org  Mon Sep 19 18:24:59 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 19 Sep 2022 18:24:59 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
Message-ID: <af6ZJqEE2GUHqxG5-OYAs8-NFcBAovkrPt8dCyEWNjs=.849772ea-0273-4e75-8cb3-2c1204485137@github.com>

On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

It's still worth manually testing the opposite direction at least once on your own machine, I just meant it's not worth adding this test into our code repository since it must run with a different JDK.

I agree the test should pass if the Java Object Serialization Specification isn't broken, but sometimes our tests are able to expose problems in other areas.

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

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

From mpowers at openjdk.org  Mon Sep 19 18:24:59 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 19 Sep 2022 18:24:59 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
Message-ID: <FiLVubnztcoDVCVXLX6uKwDGsbRtPbzQ3vs4_DnuSRE=.54d28793-e330-4c6b-881c-4eda6cde9f83@github.com>

On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

Fair enough. I'll run a test in the opposite direction.

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

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

From valeriep at openjdk.org  Mon Sep 19 18:29:43 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 18:29:43 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <R9YoH0tRqfqN_1Cdn9mx2OByISK0OIodBjLrlG_N30k=.f7cfb8fd-dec6-42a3-83ea-117b2ff49fd6@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <R9YoH0tRqfqN_1Cdn9mx2OByISK0OIodBjLrlG_N30k=.f7cfb8fd-dec6-42a3-83ea-117b2ff49fd6@github.com>
Message-ID: <fME1eX_Niy1iohg3vfjPStpWFup2a2lRDq3RLQoyq_I=.418c58a3-02c5-4051-86bd-e5b99ba20ab2@github.com>

On Mon, 19 Sep 2022 18:10:17 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> I tested old bytes on new release. It passes. I didn't test new bytes on an old release because of Max's "from the future" comment. Honestly, I'm not sure what any of this testing proves. Maybe that the Java Object Serialization Specification isn't broken?

Supposedly if the newer bytes doesn't work with the older releases, it is a compatibility format change and you should change the serialVersionID value to indicate it. In this case, some may wonder if it's worthwhile to remove this field.

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

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

From rriggs at openjdk.org  Mon Sep 19 18:54:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Sep 2022 18:54:48 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
Message-ID: <lZYoUeo-o1l4mcT381NopCBbCz33MUlxe4QOt_a8JuE=.45ea50b8-d137-4cc5-8c4f-9c0855d3807a@github.com>

On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

As mentioned earlier in the comments...
This is a completely compatible change.  Removing a field is well specified as a compatible change.
>From old version to new version the value in the stream is discarded.
>From a new version to the old version, the value in the stream is missing so the field is initialized to its default value (false for boolean).
There's no reason to change the serialVersionUID. Changing it would be an incompatible change and cause all kinds of other problems. 

In the current case, since the value of the field is false, it will be hard to observe any change in behavior.

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

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

From mpowers at openjdk.org  Mon Sep 19 19:11:44 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 19 Sep 2022 19:11:44 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
Message-ID: <gzZ_eUwUnwisEqsp9_i2NSCGcbmRC_M0ZCPypFAjSSc=.09ce2015-9b27-487c-b4a8-3ca0037c0612@github.com>

On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

I ran the test in the reverse direction. No difference in behavior was observed.

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

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

From mullan at openjdk.org  Mon Sep 19 19:49:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 19 Sep 2022 19:49:51 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v8]
In-Reply-To: <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>
Message-ID: <C7z7JjGo9DPaQQt7XbJ412IJKRxLEV0iwGcscjRBEiA=.dc2f6fd1-4729-4dd6-b7ab-94f6a003abc6@github.com>

On Mon, 19 Sep 2022 17:25:53 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor clarification for verifying an JarInputStream

src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:

> 42:  * <p>
> 43:  * The {@link #getManifest() getManifest} method is used to return the
> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>

Is it necessary to put "JAR" before "Manifest"? In the previous paragraph, you did not.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 46:

> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
> 46:  * in the stream (or the second entry the first entry in the stream is

missing "if": "or the second entry if ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 47:

> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
> 46:  * in the stream (or the second entry the first entry in the stream is
> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).

Missing "is": "and the second entry is ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 48:

> 46:  * in the stream (or the second entry the first entry in the stream is
> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
> 48:  *</p>

Nit, add space after "*".

src/java.base/share/classes/java/util/jar/JarInputStream.java line 59:

> 57:  * </p>
> 58:  *
> 59:  *  <h2>Verifying a JarInputStream</h2>

Is there a reason this is indented one extra space?

src/java.base/share/classes/java/util/jar/JarInputStream.java line 149:

> 147:     /**
> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
> 149:      * in the stream (or the second entry the first entry in the stream is

missing "if": "or the second entry if ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 150:

> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
> 149:      * in the stream (or the second entry the first entry in the stream is
> 150:      * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}), or

Missing "is": "and the second entry is ..."

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

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

From lancea at openjdk.org  Mon Sep 19 20:04:18 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 20:04:18 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v9]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <TwdhahrkUzeN0kDSyV1c6lKLENGCbH0f5_J7T5SRrH0=.78738797-e42b-4447-bf39-c998063bbf97@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address Sean's input

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/bd4e0005..2bafc00c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=07-08

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

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

From lancea at openjdk.org  Mon Sep 19 20:07:11 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 20:07:11 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v9]
In-Reply-To: <TwdhahrkUzeN0kDSyV1c6lKLENGCbH0f5_J7T5SRrH0=.78738797-e42b-4447-bf39-c998063bbf97@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <TwdhahrkUzeN0kDSyV1c6lKLENGCbH0f5_J7T5SRrH0=.78738797-e42b-4447-bf39-c998063bbf97@github.com>
Message-ID: <krpkrbRetivSurvWcEMe5BAeRlk__Bq2r3oOmJ6nXGg=.14ffe7dc-0794-4f63-a669-7576f560c10e@github.com>

On Mon, 19 Sep 2022 20:04:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Sean's input

Thank you Sean for the input.  Your suggestions should have all been addressed (hopefully)

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

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

From lancea at openjdk.org  Mon Sep 19 20:07:12 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 20:07:12 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v8]
In-Reply-To: <C7z7JjGo9DPaQQt7XbJ412IJKRxLEV0iwGcscjRBEiA=.dc2f6fd1-4729-4dd6-b7ab-94f6a003abc6@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>
 <C7z7JjGo9DPaQQt7XbJ412IJKRxLEV0iwGcscjRBEiA=.dc2f6fd1-4729-4dd6-b7ab-94f6a003abc6@github.com>
Message-ID: <Z-74DMU6M20_udsMSc9c3DG0J9s3tGrdqta8ElWX-IU=.4612cca8-6688-4a6d-a9d4-ab337c8f37cb@github.com>

On Mon, 19 Sep 2022 19:26:53 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor clarification for verifying an JarInputStream
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:
> 
>> 42:  * <p>
>> 43:  * The {@link #getManifest() getManifest} method is used to return the
>> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
> 
> Is it necessary to put "JAR" before "Manifest"? In the previous paragraph, you did not.

Removed JAR

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 46:
> 
>> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
>> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
>> 46:  * in the stream (or the second entry the first entry in the stream is
> 
> missing "if": "or the second entry if ..."

updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 47:
> 
>> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
>> 46:  * in the stream (or the second entry the first entry in the stream is
>> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
> 
> Missing "is": "and the second entry is ..."

updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 48:
> 
>> 46:  * in the stream (or the second entry the first entry in the stream is
>> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
>> 48:  *</p>
> 
> Nit, add space after "*".

fixed

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 59:
> 
>> 57:  * </p>
>> 58:  *
>> 59:  *  <h2>Verifying a JarInputStream</h2>
> 
> Is there a reason this is indented one extra space?

Updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 149:
> 
>> 147:     /**
>> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
>> 149:      * in the stream (or the second entry the first entry in the stream is
> 
> missing "if": "or the second entry if ..."

updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 150:
> 
>> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
>> 149:      * in the stream (or the second entry the first entry in the stream is
>> 150:      * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}), or
> 
> Missing "is": "and the second entry is ..."

fixed

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

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

From weijun at openjdk.org  Mon Sep 19 20:34:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 19 Sep 2022 20:34:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
 <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
 <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>
Message-ID: <LlI1t4-s_xsY_VOmbrlPOHYoF2EUFJI8-PBs691M0XU=.28859b65-62d8-41e4-b519-fe096ef6fb89@github.com>

On Mon, 19 Sep 2022 17:53:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
>> 
>> Wording it is hard. The draft wording made it look  that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..
>
>> > I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
>> 
>> Wording it is hard. The draft wording made it look that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..
> 
> Thinking about this some more, would the following be any better:
> 
> 
>  * <p>
>  * The {@code Manifest} for a JAR file may include
>  *  <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
>  *  <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
>  *  attributes. {@link JarEntry#getAttributes()} will return the per entry
>  *  attributes for the current JAR file entry, if any, providing
>  *  {@code getManifest()} returns the {@code Manifest} for the JAR file.
>  *  </p>

Does this mean that the "Verifying a JarInputStream" should also avoid mentioning "getManifest method returns the manifest"? I understand precisely it should be "getManifest method is able to return the manifest if you call it".

It almost sounds like we should first define the concepts of "well-formed JAR file" and "well-formed signed JAR" and then specify what these methods behave.

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

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

From jpai at openjdk.org  Tue Sep 20 06:19:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Sep 2022 06:19:58 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
Message-ID: <xbVtwov6ZBPq4qCrCSQ-1Ww0-u8WPJ4ApmpjzARVVAI=.3467f8bd-2b9c-4fdd-a58c-e60470f7aaa0@github.com>

On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update from review comments

Marked as reviewed by jpai (Reviewer).

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

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

From jpai at openjdk.org  Tue Sep 20 06:19:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Sep 2022 06:19:58 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <yhwL4gvGc1JzRzySXPoC5D_-F79QyHbTfqqqclP97bI=.05296d6e-2a00-49a1-9a6b-ff1d16e999c9@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
 <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
 <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>
 <yhwL4gvGc1JzRzySXPoC5D_-F79QyHbTfqqqclP97bI=.05296d6e-2a00-49a1-9a6b-ff1d16e999c9@github.com>
Message-ID: <Qt8K6gJtCIGJXJta2otQPLmZRh2v8Get-CQpSPmb7Y0=.2a0cbb5d-4506-46ca-a3ac-51086ebb2df7@github.com>

On Mon, 19 Sep 2022 16:55:01 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying.
>> Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately?
>
> Let's stick to just recording events where a match on service and provider is made then.
> 
> The expectation is that analysis would be done post recording. Probably best to reduce the runtime performance impact.

Thank you for noting the reason, Sean. It's reasonable to only generate an event for a match.

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

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

From alanb at openjdk.org  Tue Sep 20 07:00:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 07:00:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
Message-ID: <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>

On Mon, 19 Sep 2022 10:21:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> OK, will make another pass at this today

I looked at the latest draft (2bafc00c). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.

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

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

From lancea at openjdk.org  Tue Sep 20 10:53:57 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 10:53:57 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
 <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
Message-ID: <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>

On Tue, 20 Sep 2022 06:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I realise you've had a few iterations with Max on this section but I'm concerned that the text is telling the reader that they should use the 2-arg constructor to verify the signatures when a JAR is signed. The default is to verify and the main reason to use the 2-arg constructor is when you want to opt out, not opt-in.
>>> 
>>> I think the intro to this section will need to start with a sentence to say that JAR files can be signed (link to specs/jar/jar.html#signed-jar-file) and that JarInputStream can read a signed JAR from the input stream. As per the description further up, the manifest must be at the start of the stream.
>> 
>> OK, will make another pass at this today
>
>> OK, will make another pass at this today
> 
> I looked at the latest draft (2bafc00c). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.

> > OK, will make another pass at this today
> 
> I looked at the latest draft ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".

OK, I will change as you suggest

 The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.

The reason I used the getManifest wording is I felt it was easier and less redundant than copying the wording about the Manifest needing to be either the first or second entry (assuming META-INF/ is the first in the stream).  However if you prefer that, I will make that change.

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

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

From lancea at openjdk.org  Tue Sep 20 11:03:38 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 11:03:38 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <LlI1t4-s_xsY_VOmbrlPOHYoF2EUFJI8-PBs691M0XU=.28859b65-62d8-41e4-b519-fe096ef6fb89@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
 <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
 <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>
 <LlI1t4-s_xsY_VOmbrlPOHYoF2EUFJI8-PBs691M0XU=.28859b65-62d8-41e4-b519-fe096ef6fb89@github.com>
Message-ID: <DOtpoDAnkr2dN0Kq4d2ttjyY486ks5B9z2sbGgxk520=.7303f000-e8a7-4a86-b19f-040596a1095c@github.com>

On Mon, 19 Sep 2022 20:30:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Does this mean that the "Verifying a JarInputStream" should also avoid mentioning "getManifest method returns the manifest"? I understand precisely it should be "getManifest method is able to return the manifest if you call it".

See Alan's comment below.  I will be copying the wording regarding the Manifest being the 1st/2nd entry
> 
> It almost sounds like we should first define the concepts of "well-formed JAR file" and "well-formed signed JAR" and then specify what these methods behave.

The Manifest location requirement is unique to JarInputStream so really want to try to keep these updates to a minimum if at all possible so that we are not copying parts of the Jar spec into the javadoc.

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

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

From redestad at openjdk.org  Tue Sep 20 11:25:25 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Sep 2022 11:25:25 GMT
Subject: RFR: 8294058: Early use of lambda introduced in JDK-8285263 cause
 startup regressions in 20-b02
Message-ID: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>

[JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a (capturing) lambda. Since this is called during early bootstrap this shows up as a regression across the board on all our startup and footprint tests.

Restoring the anonymous class drops no. of classes loaded on a Hello World test from 493 to 448 (macosx).

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

Commit messages:
 - Add comment
 - De-sugar lambda in SecureClassLoader.getProtectionDomain

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

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

From mullan at openjdk.org  Tue Sep 20 12:11:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 20 Sep 2022 12:11:30 GMT
Subject: RFR: 8294058: Early use of lambda introduced in JDK-8285263 cause
 startup regressions in 20-b02
In-Reply-To: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>
References: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>
Message-ID: <0yO0uWio1T--BnIlcC7aTBabAYAYwivv59STOTmtyWs=.95243fa1-b1c4-4bf6-aafc-9190ab18dcb7@github.com>

On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a (capturing) lambda. Since this is called during early bootstrap this shows up as a regression across the board on all our startup and footprint tests.
> 
> Restoring the anonymous class drops no. of classes loaded on a Hello World test from 493 to 448 (macosx).

Marked as reviewed by mullan (Reviewer).

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

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

From shade at openjdk.org  Tue Sep 20 13:38:44 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Sep 2022 13:38:44 GMT
Subject: RFR: 8279941: sun/security/pkcs11/Signature/TestDSAKeyLength.java
 fails when NSS version detection fails
In-Reply-To: <5hFM4_XQfF5Q569-hnf06BGewZHeaKkPpv9ZMEOz4Zw=.5834eda0-4353-4088-bc66-df2815280ed4@github.com>
References: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
 <5hFM4_XQfF5Q569-hnf06BGewZHeaKkPpv9ZMEOz4Zw=.5834eda0-4353-4088-bc66-df2815280ed4@github.com>
Message-ID: <zWqFFNjVXKHpMHxVAFM4TjFgIWZ-iul8WexAEgjjh1s=.dc85fe84-37e3-4fd3-b695-957d95387e31@github.com>

On Mon, 19 Sep 2022 17:33:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Looks good.

Thank you! Any other reviews needed, or this one is enough?

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

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

From redestad at openjdk.org  Tue Sep 20 14:50:46 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Sep 2022 14:50:46 GMT
Subject: RFR: 8294058: Early use of lambda introduced in JDK-8285263 cause
 startup regressions in 20-b02
In-Reply-To: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>
References: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>
Message-ID: <qdoQuxVjxMDQtVL9c7A1UB4XjzNg0Qg50d2aB7-bT-w=.9a12c8a2-6cb4-4cd5-b58e-0f9c83e2735f@github.com>

On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a (capturing) lambda. Since this is called during early bootstrap this shows up as a regression across the board on all our startup and footprint tests.
> 
> Restoring the anonymous class drops no. of classes loaded on a Hello World test from 493 to 448 (macosx).

Thanks for reviewing, Sean!

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

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

From redestad at openjdk.org  Tue Sep 20 14:54:54 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Sep 2022 14:54:54 GMT
Subject: Integrated: 8294058: Early use of lambda introduced in JDK-8285263
 cause startup regressions in 20-b02
In-Reply-To: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>
References: <6iRL5pJdw1y57_8H0Fk-3JjdNU8KRgOwBoxFaJYihwc=.afd77115-4f30-4701-8804-4a8b5e15fba6@github.com>
Message-ID: <uNCoqRJFqlvZtkzpgQPzu2_Q1pRqEcXF4366X9VPxK4=.45b0956f-1998-4241-b913-3d1cfd0c27b4@github.com>

On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a (capturing) lambda. Since this is called during early bootstrap this shows up as a regression across the board on all our startup and footprint tests.
> 
> Restoring the anonymous class drops no. of classes loaded on a Hello World test from 493 to 448 (macosx).

This pull request has now been integrated.

Changeset: 584de68d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/584de68d7888b709b2eaa251541cd9fdcef3b244
Stats:     15 lines in 1 file changed: 6 ins; 1 del; 8 mod

8294058: Early use of lambda introduced in JDK-8285263 cause startup regressions in 20-b02

Reviewed-by: mullan

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

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

From lancea at openjdk.org  Tue Sep 20 16:55:51 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 16:55:51 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v10]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <yXv2wx-Ec2fZ3y-7sVoVwPZZhYb-c3mN1E8WXF7vQFQ=.3fbee5be-5a7d-4af9-bc1a-850b7db17bb8@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address comments regarding Verifying a JarInputStreams

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/2bafc00c..69138715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=08-09

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

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

From alanb at openjdk.org  Tue Sep 20 17:39:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 17:39:53 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
 <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
 <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>
Message-ID: <81kHCQ96IVkOJzWSXbhmSgeyxL-DNNjCVYIcyZhGu6w=.fad3d1c3-c45d-468c-aaec-94765804f614@github.com>

On Tue, 20 Sep 2022 10:49:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> OK, will make another pass at this today
>> 
>> I looked at the latest draft (2bafc00c). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.
>
>> > OK, will make another pass at this today
>> 
>> I looked at the latest draft ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".
> 
> OK, I will change as you suggest
> 
>  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.
> 
> The reason I used the getManifest wording is I felt it was easier and less redundant than copying the wording about the Manifest needing to be either the first or second entry (assuming META-INF/ is the first in the stream).  However if you prefer that, I will make that change.

Thanks for the updates in 69138715.  Just one comment on the updated text, and specifically this sentence:

+ *  A {@code JarInputStream} may be used to verify the signatures of a
+ *  <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">signed JAR file</a>
+ *  assuming the following requirements are met:

The signatures are verified by default so I think you can reduce this down to:
 
A {@code JarInputStream}  verifies the signatures of entries in a <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">Signed JAR file</a>  when:

We could say that a program could opt-out of verification by using the 2-arg constructor but that is probably too much to try to fit in here.

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

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

From lancea at openjdk.org  Tue Sep 20 17:47:03 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 17:47:03 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  More wordsmithing to the signed jar section

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/69138715..4c4c2a06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=09-10

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

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

From lancea at openjdk.org  Tue Sep 20 17:48:36 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 17:48:36 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <81kHCQ96IVkOJzWSXbhmSgeyxL-DNNjCVYIcyZhGu6w=.fad3d1c3-c45d-468c-aaec-94765804f614@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
 <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
 <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>
 <81kHCQ96IVkOJzWSXbhmSgeyxL-DNNjCVYIcyZhGu6w=.fad3d1c3-c45d-468c-aaec-94765804f614@github.com>
Message-ID: <mRiEannOneICGaDQu5Kpbmr8QOzrTOUHk4BR2mJ7gxE=.78dd8b1a-cbb7-48f2-9c07-f33b7eee07a3@github.com>

On Tue, 20 Sep 2022 17:37:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > OK, will make another pass at this today
>>> 
>>> I looked at the latest draft ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".
>> 
>> OK, I will change as you suggest
>> 
>>  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.
>> 
>> The reason I used the getManifest wording is I felt it was easier and less redundant than copying the wording about the Manifest needing to be either the first or second entry (assuming META-INF/ is the first in the stream).  However if you prefer that, I will make that change.
>
> Thanks for the updates in 69138715.  Just one comment on the updated text, and specifically this sentence:
> 
> + *  A {@code JarInputStream} may be used to verify the signatures of a
> + *  <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">signed JAR file</a>
> + *  assuming the following requirements are met:
> 
> The signatures are verified by default so I think you can reduce this down to:
>  
> A {@code JarInputStream}  verifies the signatures of entries in a <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">Signed JAR file</a>  when:
> 
> We could say that a program could opt-out of verification by using the 2-arg constructor but that is probably too much to try to fit in here.

> Thanks for the updates in [6913871](https://github.com/openjdk/jdk/commit/691387157f01602ee25a1887223e00f880d071d1). Just one comment on the updated text, and specifically this sentence:
> 
> * * A {@code JarInputStream} may be used to verify the signatures of a
> * * [signed JAR file]({@docRoot}/../specs/jar/jar.html#signed-jar-file)
> * * assuming the following requirements are met:
> 
> The signatures are verified by default so I think you can reduce this down to:
> 
> A {@code JarInputStream} verifies the signatures of entries in a [Signed JAR file]({@docRoot}/../specs/jar/jar.html#signed-jar-file) when:
> 
> We could say that a program could opt-out of verification by using the 2-arg constructor but that is probably too much to try to fit in here.

Updated per your suggestion above.

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

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

From mullan at openjdk.org  Tue Sep 20 17:55:52 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 20 Sep 2022 17:55:52 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
Message-ID: <OR1GB5lDiLLiWuCvxCQ_DF_vKLRyjJamorwkmyUwhyU=.5960d1d1-52d4-41b1-af82-1a87f377549b@github.com>

On Tue, 20 Sep 2022 17:47:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wordsmithing to the signed jar section

src/java.base/share/classes/java/util/jar/JarInputStream.java line 77:

> 75:  *  {@link JarEntry#getCertificates()} may be called to obtain the certificates
> 76:  *  for this entry and {@link JarEntry#getCodeSigners()} may be called to obtain
> 77:  *  the signers.

Now that this API has a section about signed JARs, I think  it  is very important to include the following sentences which are copied from `JarFile`:

"Please note that the verification process does not include validating the signer's certificate. A caller should inspect the return value of [JarEntry.getCodeSigners()](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/jar/JarEntry.html#getCodeSigners()) to further determine if the signature can be trusted."

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

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

From lancea at openjdk.org  Tue Sep 20 18:08:23 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 18:08:23 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added the verification note from JarFile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/4c4c2a06..18f7e5dc

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

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

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

From lancea at openjdk.org  Tue Sep 20 18:08:26 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 18:08:26 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <OR1GB5lDiLLiWuCvxCQ_DF_vKLRyjJamorwkmyUwhyU=.5960d1d1-52d4-41b1-af82-1a87f377549b@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
 <OR1GB5lDiLLiWuCvxCQ_DF_vKLRyjJamorwkmyUwhyU=.5960d1d1-52d4-41b1-af82-1a87f377549b@github.com>
Message-ID: <kwvoOBw-n77hZFz9WYOjJbwi6X7TZVDFquOlax9Jz8A=.d77523be-d329-4b40-ac43-672fdd6cc528@github.com>

On Tue, 20 Sep 2022 17:53:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Now that this API has a section about signed JARs, I think it is very important to include the following sentences which are copied from `JarFile`:
> 
> "Please note that the verification process does not include validating the signer's certificate. A caller should inspect the return value of [JarEntry.getCodeSigners()](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/jar/JarEntry.html#getCodeSigners()) to further determine if the signature can be trusted."

Add the note per your request

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

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

From lancea at openjdk.org  Tue Sep 20 18:12:07 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 18:12:07 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
Message-ID: <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>

On Tue, 20 Sep 2022 17:47:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wordsmithing to the signed jar section

Alan,

Assuming we are set with the other changes, did you want to add the following paragraph (or similar) at line 58 to make it clear that if the Manifest is not found, then the JarEntry attributes will not be available:


 * <p>
 * The {@code Manifest} for a JAR file may include
 * <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
 * <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
 *  attributes. {@link JarEntry#getAttributes()} will return the per entry
 *  attributes for the current JAR file entry, if any, providing
 *  the {@code Manifest} is the first or second entry in the stream as described
 *  above.
 *  </p>
 *


If you have alternate wording, that is fine or we can leave it out entirely.

Hopefully this is the last piece to the update to resolve

Thank you (all) for your time and input

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

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

From valeriep at openjdk.org  Tue Sep 20 20:04:46 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 20 Sep 2022 20:04:46 GMT
Subject: RFR: 8279941: sun/security/pkcs11/Signature/TestDSAKeyLength.java
 fails when NSS version detection fails
In-Reply-To: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
References: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
Message-ID: <gEPOwLbtpyiBRGIEwDV9GBwHfUd-eyWQBAqeZd3mZck=.a73aa800-b6eb-40b3-ac5a-72b5fbcd3058@github.com>

On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The test helpers try to identify NSS version by parsing the relevant `.so` files (!) looking for "Version: ..." string. This fails at least on Ubuntu 22.04, where the NSS does not have any version-identifiable strings. In this case, the test "detects" version as `0.0` and then fails. After brief discussion in the bug, the best fix is to ignore `0.0` as well.
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, affected test now skipped on Ubuntu 22.04

One should be enough. Just a trivial change.

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

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

From valeriep at openjdk.org  Tue Sep 20 20:07:54 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 20 Sep 2022 20:07:54 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <gzZ_eUwUnwisEqsp9_i2NSCGcbmRC_M0ZCPypFAjSSc=.09ce2015-9b27-487c-b4a8-3ca0037c0612@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <gzZ_eUwUnwisEqsp9_i2NSCGcbmRC_M0ZCPypFAjSSc=.09ce2015-9b27-487c-b4a8-3ca0037c0612@github.com>
Message-ID: <9181lcKZSBaTsBKPyTJkoIZDoVTxH0L6ET9OGHOFVoA=.1e8611f1-8fe8-4f23-85b5-47a29cd8270d@github.com>

On Mon, 19 Sep 2022 19:08:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> I ran the test in the reverse direction. No difference in behavior was observed.

Great, thanks for confirming.

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

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

From valeriep at openjdk.org  Tue Sep 20 20:07:55 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 20 Sep 2022 20:07:55 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <lZYoUeo-o1l4mcT381NopCBbCz33MUlxe4QOt_a8JuE=.45ea50b8-d137-4cc5-8c4f-9c0855d3807a@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <lZYoUeo-o1l4mcT381NopCBbCz33MUlxe4QOt_a8JuE=.45ea50b8-d137-4cc5-8c4f-9c0855d3807a@github.com>
Message-ID: <o4aP7tmjey8Vpz7KEjk1xeNbpTVu6PSB-08iVeMYLVo=.927c6c17-dd42-4600-8fb3-0e67994c07f5@github.com>

On Mon, 19 Sep 2022 18:50:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> As mentioned earlier in the comments... This is a completely compatible change. Removing a field is well specified as a compatible change. From old version to new version the value in the stream is discarded. From a new version to the old version, the value in the stream is missing so the field is initialized to its default value (false for boolean). There's no reason to change the serialVersionUID. Changing it would be an incompatible change and cause all kinds of other problems.
> 
> In the current case, since the value of the field is false, it will be hard to observe any change in behavior.

Thanks for the comments, just want to be sure the old version handles the missing field, that's all.

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

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

From shade at openjdk.org  Tue Sep 20 20:15:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Sep 2022 20:15:16 GMT
Subject: RFR: 8279941: sun/security/pkcs11/Signature/TestDSAKeyLength.java
 fails when NSS version detection fails
In-Reply-To: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
References: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
Message-ID: <qUew5ZAT1GNWRf1c2ljYsB1hVBsR-EJ_a1m5Bt916I8=.54098d1c-f33d-4f37-84f5-40215c9bbf0f@github.com>

On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The test helpers try to identify NSS version by parsing the relevant `.so` files (!) looking for "Version: ..." string. This fails at least on Ubuntu 22.04, where the NSS does not have any version-identifiable strings. In this case, the test "detects" version as `0.0` and then fails. After brief discussion in the bug, the best fix is to ignore `0.0` as well.
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, affected test now skipped on Ubuntu 22.04

Thanks!

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

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

From shade at openjdk.org  Tue Sep 20 20:15:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Sep 2022 20:15:16 GMT
Subject: Integrated: 8279941:
 sun/security/pkcs11/Signature/TestDSAKeyLength.java fails when NSS version
 detection fails
In-Reply-To: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
References: <Els087HMsFYnOQ5XYPIoRmuwGx5ik7v2m9LChpoMSlU=.d077b6c2-24bd-4894-b00f-aacf350e8908@github.com>
Message-ID: <mzMhiHVc6b7ABxTOeumdYCjI_dYbjBZq6WyjoEQ89ks=.e72f4f14-5b1c-4e1a-baad-d9eda4a9ebfb@github.com>

On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The test helpers try to identify NSS version by parsing the relevant `.so` files (!) looking for "Version: ..." string. This fails at least on Ubuntu 22.04, where the NSS does not have any version-identifiable strings. In this case, the test "detects" version as `0.0` and then fails. After brief discussion in the bug, the best fix is to ignore `0.0` as well.
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, affected test now skipped on Ubuntu 22.04

This pull request has now been integrated.

Changeset: cddd6def
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cddd6def9f796a25137e0059e82053142747c001
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8279941: sun/security/pkcs11/Signature/TestDSAKeyLength.java fails when NSS version detection fails

Reviewed-by: valeriep

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

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

From xuelei at openjdk.org  Wed Sep 21 04:18:33 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 21 Sep 2022 04:18:33 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
Message-ID: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>

Hi,

In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
"(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.

Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.

This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.

Thanks,
Xuelei

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

Commit messages:
 - remove tab space
 - 8294073: Performance improvement for message digest implementations

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

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

From alanb at openjdk.org  Wed Sep 21 09:25:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 09:25:53 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
 <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>
Message-ID: <fRT_O_SNLwp6sNaQMdsA9TRK-S1xBVCHsSE6GCwGPnw=.40a62866-6111-44eb-808f-2ef9239c594d@github.com>

On Tue, 20 Sep 2022 18:08:21 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Assuming we are set with the other changes, did you want to add the following paragraph (or similar) at line 58 to make it clear that if the Manifest is not found, then the JarEntry attributes will not be available:

This is something the reader can read about in the Signed JAR section of the JAR file spec and I think it's too much to try to include in this section of JarInputStream. If there is a place for this in JarInputStream then it's probably in the method description of getNextJarEntry as that can talk about the properties of the JarEntry that it returns. You could separate that out to a separate issue if you want.

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

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

From lancea at openjdk.org  Wed Sep 21 11:42:50 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 Sep 2022 11:42:50 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <fRT_O_SNLwp6sNaQMdsA9TRK-S1xBVCHsSE6GCwGPnw=.40a62866-6111-44eb-808f-2ef9239c594d@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
 <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>
 <fRT_O_SNLwp6sNaQMdsA9TRK-S1xBVCHsSE6GCwGPnw=.40a62866-6111-44eb-808f-2ef9239c594d@github.com>
Message-ID: <7HqqjzAqvKy4vjgVkmouPOro7YyIXNuye-v08RujFAM=.b3d9a188-4835-4046-a87a-930dd617bb5e@github.com>

On Wed, 21 Sep 2022 09:23:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Assuming we are set with the other changes, did you want to add the following paragraph (or similar) at line 58 to make it clear that if the Manifest is not found, then the JarEntry attributes will not be available:
> 
> This is something the reader can read about in the Signed JAR section of the JAR file spec and I think it's too much to try to include in this section of JarInputStream. If there is a place for this in JarInputStream then it's probably in the method description of getNextJarEntry as that can talk about the properties of the JarEntry that it returns. You could separate that out to a separate issue if you want.

OK, we can deal with this separately.  I guess I was trying to articulate that if the Manifest is not found in beginning of the input stream, then you have no access to the attributes given this is unique to JarInputStream

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

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

From shade at openjdk.org  Wed Sep 21 12:10:38 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Sep 2022 12:10:38 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
Message-ID: <4Bor4yGVSimu9ZwZ-tK4JSizWjYPZpfXYtHqZ0ubbBU=.a33e76d7-b10a-4304-a572-9ca6a4dc32be@github.com>

On Tue, 20 Sep 2022 22:12:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
> "(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.
> 
> Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.
> 
> This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.
> 
> Thanks,
> Xuelei

(Thinking out loud, because I am on the fence with this change)

First (negative), it departs from SHA function codes as stated in most papers. This is a minor thing if we can prove the equivalence, but it still adds to maintenance overhead. While the translation of `maj` (boolean majority) function is more or less straightforward, using the `xor`/`and` distributivity, the translation for `ch` is less so. I had to scribble down things to reveal that new expressions' DNF is the old one.

Second (negative), I suspect current code is optimized more for the instruction-level parallelism than for the number of operations. (This might be the reason why SHA papers do this, to optimize latency in hardware implementations?) In case of `ch`, we have one operation less, but it is probably a wash, since in the original expression that spare operation can run in parallel with the rest of the code. In `maj` case it is worse: we now have three operations on critical path (expression tree is one level deeper) instead of two, which inhibits the ILP.

Third (positive), I think the real target are VM modes which cannot exploit any ILP, so reduction in op count / bytecode size is sensible. For example, Zero that runs only in interpreter, and where bytecode-level ILP cannot be exploited as every bytecode instruction is handled by large chunk of code. The improvements/regressions on this code are usually visible when hashing the JMODs or jlinking the image. I see about 0.3% faster linux-x86_64-zero-release builds with this patch.

Fourth (positive), it is not unprecedented to optimize for interpreters here. I did https://bugs.openjdk.org/browse/JDK-8256523 the last time in the same code.

Are you getting +0.8% throughput on microbenchmarks?

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

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

From xuelei at openjdk.org  Wed Sep 21 15:16:24 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 21 Sep 2022 15:16:24 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <4Bor4yGVSimu9ZwZ-tK4JSizWjYPZpfXYtHqZ0ubbBU=.a33e76d7-b10a-4304-a572-9ca6a4dc32be@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
 <4Bor4yGVSimu9ZwZ-tK4JSizWjYPZpfXYtHqZ0ubbBU=.a33e76d7-b10a-4304-a572-9ca6a4dc32be@github.com>
Message-ID: <JzBO24xeWli6rmwHEWpBD-bScVheXwWr8ZFLh8l-gGE=.bbafcedf-8343-40e1-b055-80b9894f30c2@github.com>

On Wed, 21 Sep 2022 12:06:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
>> "(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.
>> 
>> Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.
>> 
>> This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.
>> 
>> Thanks,
>> Xuelei
>
> (Thinking out loud, because I am on the fence with this change)
> 
> First (negative), it departs from SHA function codes as stated in most papers. This is a minor thing if we can prove the equivalence, but it still adds to maintenance overhead. While the translation of `maj` (boolean majority) function is more or less straightforward, using the `xor`/`and` distributivity, the translation for `ch` is less so. I had to scribble down things to reveal that new expressions' DNF is the old one.
> 
> Second (negative), I suspect current code is optimized more for the instruction-level parallelism than for the number of operations. (This might be the reason why SHA papers do this, to optimize latency in hardware implementations?) In case of `ch`, we have one operation less, but it is probably a wash, since in the original expression that spare operation can run in parallel with the rest of the code. In `maj` case it is worse: we now have three operations on critical path (expression tree is one level deeper) instead of two, which inhibits the ILP.
> 
> Third (positive), I think the real target are VM modes which cannot exploit any ILP, so reduction in op count / bytecode size is sensible. For example, Zero that runs only in interpreter, and where bytecode-level ILP cannot be exploited as every bytecode instruction is handled by large chunk of code. The improvements/regressions on this code are usually visible when hashing the JMODs or jlinking the image. I see about 0.3% faster linux-x86_64-zero-release builds with this patch.
> 
> Fourth (positive), it is not unprecedented to optimize for interpreters here. I did https://bugs.openjdk.org/browse/JDK-8256523 the last time in the same code.
> 
> Are you getting +0.8% throughput on microbenchmarks?

@shipilev Good points and I agree with them.

> Are you getting +0.8% throughput on microbenchmarks?

Yes, I got it a few times. I tested on MacOS/M1 and Linux/AMD for 64/512/2048/16384.  As the improvement is not significant, the number was impacted by the platforms status/loading.  I can see improvement, but I did not get a stable +0.8%.

I got a more than +1% improvement in another algorithm implementation (SM3).  That's the reason I want to check out the JDK implementations.  But you let me convinced that this may not be worthy of the effort.  Thank you so much!

> https://bugs.openjdk.org/browse/JDK-8256523
Thank you so much for pointing this out.  From it, I learned something new that the Java inline may not work in some circumstance.  Impressed PR description!

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

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

From coffeys at openjdk.org  Wed Sep 21 15:22:17 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 21 Sep 2022 15:22:17 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v3]
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <USs_vDS5nXOTCPMXLrJ0SUufRlhCjR7fNrnaUmgK2Rg=.7bc0f094-abb1-4cde-ad0d-01a729adb679@github.com>

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Correct Label annontation capitals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9657/files
  - new: https://git.openjdk.org/jdk/pull/9657/files/e168152f..31cedc3a

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

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

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

From shade at openjdk.org  Wed Sep 21 18:31:19 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Sep 2022 18:31:19 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <JzBO24xeWli6rmwHEWpBD-bScVheXwWr8ZFLh8l-gGE=.bbafcedf-8343-40e1-b055-80b9894f30c2@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
 <4Bor4yGVSimu9ZwZ-tK4JSizWjYPZpfXYtHqZ0ubbBU=.a33e76d7-b10a-4304-a572-9ca6a4dc32be@github.com>
 <JzBO24xeWli6rmwHEWpBD-bScVheXwWr8ZFLh8l-gGE=.bbafcedf-8343-40e1-b055-80b9894f30c2@github.com>
Message-ID: <mvKHMwxZPHZlO2FmO7nG1UyUxszVY5yn1pO6mUdBxPc=.480a8543-4b3f-4156-8ef9-61819ede17e8@github.com>

On Wed, 21 Sep 2022 15:14:22 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> But you let me convinced that this may not be worthy of the effort.

Let's think about it and not discount it right away. 1% improvement on OpenJDK scale is still quite significant, if we can show the non-interpreter modes benefit from it. Maybe older X86 and AArch64 are our targets, since it is not guaranteed to have SHA hardware intrinsics?

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

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

From xuelei at openjdk.org  Wed Sep 21 21:29:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 21 Sep 2022 21:29:16 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <mvKHMwxZPHZlO2FmO7nG1UyUxszVY5yn1pO6mUdBxPc=.480a8543-4b3f-4156-8ef9-61819ede17e8@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
 <4Bor4yGVSimu9ZwZ-tK4JSizWjYPZpfXYtHqZ0ubbBU=.a33e76d7-b10a-4304-a572-9ca6a4dc32be@github.com>
 <JzBO24xeWli6rmwHEWpBD-bScVheXwWr8ZFLh8l-gGE=.bbafcedf-8343-40e1-b055-80b9894f30c2@github.com>
 <mvKHMwxZPHZlO2FmO7nG1UyUxszVY5yn1pO6mUdBxPc=.480a8543-4b3f-4156-8ef9-61819ede17e8@github.com>
Message-ID: <ABDWvT5aHPypkbzNU4MgtvcYwj4GNUljQESfNwyJHC0=.c6a140d7-477f-4f12-bbab-fa0c267c0f61@github.com>

On Wed, 21 Sep 2022 18:29:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Maybe older X86 and AArch64 are our targets, since it is not guaranteed to have SHA hardware intrinsics?

Yes, the platforms that do not support SHA intrinsics are the targets.  If I read the OpenJDK CPU code correctly, RISC-V and ARM platforms do not support SHA-1/2/3 hardware intrinsics yet.

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

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

From coffeys at openjdk.org  Thu Sep 22 13:57:48 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 22 Sep 2022 13:57:48 GMT
Subject: Integrated: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <H5DcOov8QfSxCYzSQ4cUHe0k01vfkRkkJgFL-VdjlQ8=.c292a3b0-f170-47b2-ab7f-55b8c8a083bc@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

This pull request has now been integrated.

Changeset: bc2af47e
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc2af47e1e4e6e96020e03a60ce098ddd17f63ba
Stats:     280 lines in 9 files changed: 271 ins; 1 del; 8 mod

8254711: Add java.security.Provider.getService JFR Event

Reviewed-by: mullan, valeriep, jpai

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

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

From coffeys at openjdk.org  Thu Sep 22 16:11:02 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 22 Sep 2022 16:11:02 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
Message-ID: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>

New JFR event to record state of initial security properties.
 
Debug output is also now added for these properties via -Djava.security.debug=properties

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

Commit messages:
 - merge with master
 - Correct test bug ids
 - fix up imports
 - Add security debug test logic
 - Add JFR testcase
 - remove mirror event
 - 8292177 initial commit

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

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

From xuelei at openjdk.org  Thu Sep 22 21:57:18 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Sep 2022 21:57:18 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
Message-ID: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>

Hi,

Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.

Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.

Here are the benchmark numbers without the patch:

Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms

KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms


And here are the numbers with the patch applied:

Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms

KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms


Thanks,
Xuelei

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

Commit messages:
 - remove tailing white spaces
 - 8294248: Use less limbs for P256 in EC implementation

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

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

From djelinski at openjdk.org  Fri Sep 23 06:15:16 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Sep 2022 06:15:16 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <hbFTr_58z0VPCjf1W5yeVSpJ2igg4Va28wve_cXQVGs=.764a56e1-ec19-4f98-9344-76c617ba4da8@github.com>

On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

Can you prove that this is correct?
My back-of-the-envelope calculations suggest that this may overflow:
- starting with 29 bit limbs
- after 2 additions (maxAdds) we have up to 31 bits
- then we multiply limbs (62 bits) and add up to numLimbs (9) results together = 65 bits, which overflows long
- and we didn't start reducing yet.

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

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

From xuelei at openjdk.org  Fri Sep 23 07:43:12 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 23 Sep 2022 07:43:12 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <y41iOIs0QHiHc3RPVl3Vw6dh51JcAoPgv1_i3-TAoxU=.5bb96d2c-a23e-40be-a62f-3afdaabecbcf@github.com>

On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

Thank you for the feedback, Daniel.

> Can you prove that this is correct?

That would depend on the implementation details.   The JDK testing passed, although it does not means there is no problem.  I will try if I could describe the implementation logic more clear tomorrow.  The following is just a quick reply for what I can see now for the case you described.

> My back-of-the-envelope calculations suggest that this may overflow:
> 
> * starting with 29 bit limbs
> * after 2 additions (maxAdds) we have up to 31 bits
> * then we multiply limbs (62 bits) and add up to numLimbs (9) results together = 65 bits, which overflows long
> * and we didn't start reducing yet.

For the multiply operation, I guess the result should have been carry reduced and fix in the limbs and sizes.  In the generated IntegerPolynomialP256.java, the code looks like:

    protected void mult(long[] a, long[] b, long[] r) {
        ... snipped ...
        long c16 = (a[8] * b[8]);

        carryReduce(r, c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10, c11, c12, c13, c14, c15, c16);
    }

carryReduce() is called, and the result 'r' is a set of limbs fit on the limbs size, I guess.


private void carryReduce(...) {
    ... snipped ...
        //carry from position 7
        t0 = (c7 + CARRY_ADD) >> 29;
        c7 -= (t0 << 29);
        c8 += t0;
    ... snipped ...
}


In the description of IntegerPolynomial.java, it is said that "Limb values will always fit within a long, so inputs to multiplication must be less than 32 bits. All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException."  

Did you see any code that use more than one addition before the multiplication?  Or did you refer to something else with "multiply limbs" other than the description in the IntegerPolynomial class?

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

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

From dholmes at openjdk.org  Fri Sep 23 08:58:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 08:58:42 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup
Message-ID: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>

Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).

Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.

Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).

Testing: tiers 1-3

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

Commit messages:
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/01e7b881...58bfb313

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293592
  Stats: 549 lines in 43 files changed: 134 ins; 308 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

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

From djelinski at openjdk.org  Fri Sep 23 09:24:23 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Sep 2022 09:24:23 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <y41iOIs0QHiHc3RPVl3Vw6dh51JcAoPgv1_i3-TAoxU=.5bb96d2c-a23e-40be-a62f-3afdaabecbcf@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <y41iOIs0QHiHc3RPVl3Vw6dh51JcAoPgv1_i3-TAoxU=.5bb96d2c-a23e-40be-a62f-3afdaabecbcf@github.com>
Message-ID: <WrroWOLM5cmESavUz7-3kwL5wQBVRvPNbeatHZcDsik=.04a7d173-21c0-4f57-83f4-e1bbf2e22372@github.com>

On Fri, 23 Sep 2022 07:39:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Limb values will always fit within a long, so inputs to multiplication must be less than 32 bits. *All IntegerPolynomial implementations allow at most one addition before multiplication*. Additions after that will result in an ArithmeticException.

The highlighted part of the comment is incorrect; IntegerPolynomial allows at most 2^maxAdds-1 additions, and maxAdds in your patch is 2:

static FieldParams P256 = new FieldParams(
            "IntegerPolynomialP256", 29, 9, 2 /*maxAdds*/, 256,


see the implementation of add (removed the irrelevant stuff):

        protected boolean isSummand() {
            return numAdds < maxAdds;
        }
        public ImmutableElement add(IntegerModuloP genB) {
            if (!(isSummand() && b.isSummand())) {
                throw new ArithmeticException("Not a valid summand");
            }
            int newNumAdds = Math.max(numAdds, b.numAdds) + 1;
        }


if you change maxAdds to 1, you'll start getting exceptions:

java.lang.ArithmeticException: Not a valid summand
        at java.base/sun.security.util.math.intpoly.IntegerPolynomial$MutableElement.setDifference(IntegerPolynomial.java:731)
        at java.base/sun.security.util.math.intpoly.IntegerPolynomial$MutableElement.setDifference(IntegerPolynomial.java:630)
        at jdk.crypto.ec/sun.security.ec.ECOperations.setSum(ECOperations.java:375)
        at jdk.crypto.ec/sun.security.ec.ECOperations.multiply(ECOperations.java:261)

which means that we perform at least 2 additions without doing a reduce (see [ECOperations.java:375](https://github.com/openjdk/jdk/blob/a5e0f7758ca1cdf28e221126fd9a543570bfcb7d/src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java#L375)).

So, we can multiply 29+2 = 31 bit limbs. Then in multiplication you have:

    protected void mult(long[] a, long[] b, long[] r) {
        long c8 = (a[0] * b[8]) + (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) + (a[8] * b[0]);


addition of 9 multiplication results; 31+31+lg 9 > 64.

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

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

From alanb at openjdk.org  Fri Sep 23 11:12:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 11:12:24 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <Bfq-Tx0S9oPszwvfoUkCtVd16ARxYp6c8Y1Oe9S1_y4=.1b7e4278-2ba0-455e-9cd8-2d0b27f49d70@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

(JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR once the list of changed files. You should be able to trim down the labels too.)

I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe.

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

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

From mullan at openjdk.org  Fri Sep 23 17:42:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Sep 2022 17:42:23 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
Message-ID: <WonbnHQk5TGBKyMxvqFxU0RhfCCB6RQyVHXIvaiJ2XY=.5a23c4e4-691a-440a-805d-b166d5f11e0d@github.com>

On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verification note from JarFile

As a side comment, I notice that `JarInputStream` capitalizes "JAR", whereas `JarFile` does not ("jar"). We should really be consistent in our javadocs. I think "JAR" is more correct, mainly because that is what the Jar File specification uses. 

I am not suggesting you need to change `JarFile` though this as part of this PR. Mostly noting it for future reference.

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

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

From lancea at openjdk.org  Fri Sep 23 17:56:09 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 Sep 2022 17:56:09 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <WonbnHQk5TGBKyMxvqFxU0RhfCCB6RQyVHXIvaiJ2XY=.5a23c4e4-691a-440a-805d-b166d5f11e0d@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
 <WonbnHQk5TGBKyMxvqFxU0RhfCCB6RQyVHXIvaiJ2XY=.5a23c4e4-691a-440a-805d-b166d5f11e0d@github.com>
Message-ID: <Dze-3-lpP8WsOzOSOrcFmeTxCUgvF7MHedLpAgRaseU=.9929af01-0e38-4fd1-bf9e-95587dfaedc9@github.com>

On Fri, 23 Sep 2022 17:38:47 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> As a side comment, I notice that `JarInputStream` capitalizes "JAR", whereas `JarFile` does not ("jar"). We should really be consistent in our javadocs. I think "JAR" is more correct, mainly because that is what the Jar File specification uses.
> 
> I am not suggesting you need to change `JarFile` though this as part of this PR. Mostly noting it for future reference.

 I think you raise a fair point for a different set up updates.  there are places in the JAR File spec which also uses "jar file" vs "JAR file".  Similar conversation for "ZIP" vs "Zip" vs "zip".
 
 Too yes, lets agree on the preferred convention and update in one pass through java.util.jar.* and java.util.zip.* and the JAR file spec

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

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

From mullan at openjdk.org  Fri Sep 23 17:59:12 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Sep 2022 17:59:12 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
Message-ID: <bfiWxsz5ohoh3D5f1Sq4Pc1G48_tVhL0bQXLJfj0zEo=.180cd786-8b05-4a79-82fe-4a8ac786c806@github.com>

On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verification note from JarFile

Some minor comments. Consider it reviewed either way.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 43:

> 41:  * <h2>Accessing the Manifest</h2>
> 42:  * <p>
> 43:  * The {@link #getManifest() getManifest} method is used to return the

I think this can be more simply said as "... method returns the ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 47:

> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
> 46:  * in the stream (or the second entry if the first entry in the stream is
> 47:  * {@code META-INF/} and the second entry is {@code META-INF/MANIFEST.MF}).

Do you also want to say "Otherwise, the method returns `null`."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 50:

> 48:  * </p>
> 49:  * <p> The {@link #getNextJarEntry()} and {@link #getNextEntry()} methods are
> 50:  * used to read JAR file entries from the stream. These methods skip over the

Consider removing "are used to". Just say "... methods read ...".

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

Marked as reviewed by mullan (Reviewer).

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

From cjplummer at openjdk.org  Fri Sep 23 18:31:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 18:31:23 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:

> 100:             try {
> 101:                 connector = connectors.next();
> 102:             } catch (Exception | Error x) {

Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:

> 124:             try {
> 125:                 transportService = transportServices.next();
> 126:             } catch (Exception | Error x) {

Another that could be just catch `Throwable`

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

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

From dholmes at openjdk.org  Fri Sep 23 21:47:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:06 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into 8293592-JVM_StopThread
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

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

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=01
  Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

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

From dholmes at openjdk.org  Fri Sep 23 21:47:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:08 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <pe2S9eAR6fAkhNMkE7zsvJjErBsmkHbm5PrW6Sm8jE4=.1c30dc46-dafb-4b16-be3f-73e27fc8e5fd@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

This PR is now back to its proper form after merging the upstream changes.  I can't say I like the "dependent PR" feature.

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

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

From dholmes at openjdk.org  Fri Sep 23 21:47:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:10 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
Message-ID: <WlSewOOWwaXOlFuSI6NrOYXMvwwp1xvfYxpLZF4xAPE=.9efe45f9-a6df-4bd5-bece-7e349b092a9c@github.com>

On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8293592-JVM_StopThread
>>  - Removal all special handling of ThreadDeath.
>>  - Remove all references to the stillborn field
>>  - Initial commit: remove JVM_StopThread
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:
> 
>> 100:             try {
>> 101:                 connector = connectors.next();
>> 102:             } catch (Exception | Error x) {
> 
> Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:
> 
>> 124:             try {
>> 125:                 transportService = transportServices.next();
>> 126:             } catch (Exception | Error x) {
> 
> Another that could be just catch `Throwable`

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

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

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

From xuelei at openjdk.org  Fri Sep 23 22:06:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 23 Sep 2022 22:06:58 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <0RlugKpeb_bVzXm_cxmHN74msZobJoLlFlbh7tw7gig=.013b61d9-ab67-42ce-b03e-2f0533a0b7bb@github.com>

On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

> > Limb values will always fit within a long, so inputs to multiplication must be less than 32 bits. _All IntegerPolynomial implementations allow at most one addition before multiplication_. Additions after that will result in an ArithmeticException.
> 
> The highlighted part of the comment is incorrect;

@djelinski I got your point now.  The scalar multiplication is carefully coded so that at most 2 additions are allowed.  If 2+ is required, reducing is used in the code (see the use of setReduced() in ECOperations).

The use of maxAdd may be fragile unless more checking get introduced to detect issues like integer overflow.  Alternatively, the additions implementation could be updated to take care of the overflow internally.   I will see if there is solution that is simple and effective.

Thanks!

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

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

From xuelei at openjdk.org  Sat Sep 24 08:20:18 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 24 Sep 2022 08:20:18 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <0-N7ke-OW93GiEoV0Ev9vYEQUgYboGLdZAnesFUL2b0=.49a52e31-c8cc-4d4f-ba5b-2089d994f17a@github.com>

On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

I check with the real bytes for the following computation.  For Secp256R1, the p is defined.

p = FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF
  = 2^224(2^32 ?1) + 2^192 + 2^96 ? 1
  = 2^256 - 2^224 + 2^192 + 2^96 ? 1


Let's use a full 256 bits integer for following computation, which is bigger than p:


FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

> starting with 29 bit limbs

With 29 bit limbs, it could be expressed in 9 29-bit words in little-endian order, as the following:


a[] = 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 00FFFFFF 


>From a[0] to a[7], 29 bits for each limbs, and a[8] is 24 bits.  29 * 8 + 24 = 256

> after 2 additions (maxAdds) we have up to 31 bits

after 2 additions, the 9-29 bits words are:

a[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF

>From a[0] to a[7],  31 bits for each limbs, and a[8] is 26 bits.  This is the biggest number we could get from the finite filed computation.

> then we multiply limbs (62 bits) and add up to numLimbs (9) results together = 65 bits, which overflows long
> and we didn't start reducing yet.

Let's multiply two limbs:

a[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF
b[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF 


The overflow we cared about is the following computation, the longest additions.

        long c8 = (a[0] * b[8]) + (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) + (a[8] * b[0]);

Now we have a[0]-a[7] are 31-bit words, and b[0]-b[7] are 31-bit words. a[8] and b[8] is 26-bit words.

Then, we know that (a[0] * b[8]) and (a[8] * b[0]) are multiplying between 31-bits words and 26-bits words.  So we have the equivalent computation for the a and b values above:

a[1]=a[2]=a[3]=a[4]=a[5]=a[6]=a[7]=0x7FFFFFFF;
b[1]=b[2]=b[3]=b[4]=b[5]=b[6]=b[7]=0x7FFFFFFF;
long i1x7 = (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) 
              = 0xBFFFFFF900000007L
long i0x8 =  (a[0] * b[8]) +  (a[8] * b[0]);
              = 0x03FFFFFEF8000002L

long c8 = i1x7 + i0x8
             = 0xC3FFFFF7F8000009L


c8 fills the 64 bits fully, but it does not overflow.

@djelinski does it sound right to you?

Although there is not overflow if I get the above computation right, it is still not a straightforward thing we can know without detailed computation.  Instead, this kind of computation and checking could be performed in FieldGen code automatically, or just reduce limbs operations result (up to no more than twice the modulus) and remove the limit of maxAdd.

This RFE, JDK-8294248, is one of a few performance improvement of the EC implementation in JDK ([JDK-8294188](https://bugs.openjdk.org/browse/JDK-8294188)).  I would like to address the checking or/and reducing improvement in a separately RFE.

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

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

From djelinski at openjdk.org  Sat Sep 24 09:38:23 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 24 Sep 2022 09:38:23 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <0-N7ke-OW93GiEoV0Ev9vYEQUgYboGLdZAnesFUL2b0=.49a52e31-c8cc-4d4f-ba5b-2089d994f17a@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <0-N7ke-OW93GiEoV0Ev9vYEQUgYboGLdZAnesFUL2b0=.49a52e31-c8cc-4d4f-ba5b-2089d994f17a@github.com>
Message-ID: <_XrHozgfWHiSh8L5_ONfzT1RHIfF5vw0uPXggMwaDVU=.aec3e3e0-9065-474b-a384-f4370a1a50d3@github.com>

On Sat, 24 Sep 2022 08:17:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
>> 
>> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
>> 
>> Here are the benchmark numbers without the patch:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
>> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
>> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
>> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
>> 
>> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
>> 
>> 
>> And here are the numbers with the patch applied:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
>> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
>> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
>> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
>> 
>> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
>> 
>> 
>> Thanks,
>> Xuelei
>
> I check with the real bytes for the following computation.  For Secp256R1, the p is defined.
> 
> p = FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF
>   = 2^224(2^32 ?1) + 2^192 + 2^96 ? 1
>   = 2^256 - 2^224 + 2^192 + 2^96 ? 1
> 
> 
> Let's use a full 256 bits integer for following computation, which is bigger than p:
> 
> 
> FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
> 
>> starting with 29 bit limbs
> 
> With 29 bit limbs, it could be expressed in 9 29-bit words in little-endian order, as the following:
> 
> 
> a[] = 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 00FFFFFF 
> 
> 
> From a[0] to a[7], 29 bits for each limbs, and a[8] is 24 bits.  29 * 8 + 24 = 256
> 
>> after 2 additions (maxAdds) we have up to 31 bits
> 
> after 2 additions, the 9-29 bits words are:
> 
> a[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF
> 
> From a[0] to a[7],  31 bits for each limbs, and a[8] is 26 bits.  This is the biggest number we could get from the finite filed computation.
> 
>> then we multiply limbs (62 bits) and add up to numLimbs (9) results together = 65 bits, which overflows long
>> and we didn't start reducing yet.
> 
> Let's multiply two limbs:
> 
> a[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF
> b[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF 
> 
> 
> The overflow we cared about is the following computation, the longest additions.
> 
>         long c8 = (a[0] * b[8]) + (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) + (a[8] * b[0]);
> 
> Now we have a[0]-a[7] are 31-bit words, and b[0]-b[7] are 31-bit words. a[8] and b[8] is 26-bit words.
> 
> Then, we know that (a[0] * b[8]) and (a[8] * b[0]) are multiplying between 31-bits words and 26-bits words.  So we have the equivalent computation for the a and b values above:
> 
> a[1]=a[2]=a[3]=a[4]=a[5]=a[6]=a[7]=0x7FFFFFFF;
> b[1]=b[2]=b[3]=b[4]=b[5]=b[6]=b[7]=0x7FFFFFFF;
> long i1x7 = (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) 
>               = 0xBFFFFFF900000007L
> long i0x8 =  (a[0] * b[8]) +  (a[8] * b[0]);
>               = 0x03FFFFFEF8000002L
> 
> long c8 = i1x7 + i0x8
>              = 0xC3FFFFF7F8000009L
> 
> 
> c8 fills the 64 bits fully, but it does not overflow.
> 
> @djelinski does it sound right to you?
> 
> Although there is not overflow if I get the above computation right, it is still not a straightforward thing we can know without detailed computation.  Instead, this kind of computation and checking could be performed in FieldGen code automatically, or just reduce limbs operations result (up to no more than twice the modulus) and remove the limit of maxAdd.
> 
> This RFE, JDK-8294248, is one of a few performance improvement of the EC implementation in JDK ([JDK-8294188](https://bugs.openjdk.org/browse/JDK-8294188)).  I would like to address the checking or/and reducing improvement in a separately RFE.

@XueleiFan as far as I can tell, we cannot assume that the starting number will be 256 bit; the `setReduced` operation performs a limited reduce that only ensures that limbs fit in bitsPerLimb; the carry from the last limb is only performed in `finalCarryReduceLast`.

If we start with 29 ones in every limb, the computation will overflow.

>  Instead, this kind of computation and checking could be performed in FieldGen code automatically, or just reduce limbs operations result (up to no more than twice the modulus) and remove the limit of maxAdd.

Both options are worth exploring.

Thanks for working on this!

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

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

From xuelei at openjdk.org  Sun Sep 25 05:55:10 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sun, 25 Sep 2022 05:55:10 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <0-N7ke-OW93GiEoV0Ev9vYEQUgYboGLdZAnesFUL2b0=.49a52e31-c8cc-4d4f-ba5b-2089d994f17a@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <0-N7ke-OW93GiEoV0Ev9vYEQUgYboGLdZAnesFUL2b0=.49a52e31-c8cc-4d4f-ba5b-2089d994f17a@github.com>
Message-ID: <QyTOAt1jcxe2sPl2Tohno-OBKEejzrh04TdsntBLynw=.9f297b61-2588-4003-9647-6444376510c6@github.com>

On Sat, 24 Sep 2022 08:17:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
>> 
>> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
>> 
>> Here are the benchmark numbers without the patch:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
>> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
>> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
>> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
>> 
>> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
>> 
>> 
>> And here are the numbers with the patch applied:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
>> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
>> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
>> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
>> 
>> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
>> 
>> 
>> Thanks,
>> Xuelei
>
> I check with the real bytes for the following computation.  For Secp256R1, the p is defined.
> 
> p = FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF
>   = 2^224(2^32 ?1) + 2^192 + 2^96 ? 1
>   = 2^256 - 2^224 + 2^192 + 2^96 ? 1
> 
> 
> Let's use a full 256 bits integer for following computation, which is bigger than p:
> 
> 
> FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
> 
>> starting with 29 bit limbs
> 
> With 29 bit limbs, it could be expressed in 9 29-bit words in little-endian order, as the following:
> 
> 
> a[] = 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 1FFFFFFF 00FFFFFF 
> 
> 
> From a[0] to a[7], 29 bits for each limbs, and a[8] is 24 bits.  29 * 8 + 24 = 256
> 
>> after 2 additions (maxAdds) we have up to 31 bits
> 
> after 2 additions, the 9-29 bits words are:
> 
> a[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF
> 
> From a[0] to a[7],  31 bits for each limbs, and a[8] is 26 bits.  This is the biggest number we could get from the finite filed computation.
> 
>> then we multiply limbs (62 bits) and add up to numLimbs (9) results together = 65 bits, which overflows long
>> and we didn't start reducing yet.
> 
> Let's multiply two limbs:
> 
> a[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF
> b[] = 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 7FFFFFFF 03FFFFFF 
> 
> 
> The overflow we cared about is the following computation, the longest additions.
> 
>         long c8 = (a[0] * b[8]) + (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) + (a[8] * b[0]);
> 
> Now we have a[0]-a[7] are 31-bit words, and b[0]-b[7] are 31-bit words. a[8] and b[8] is 26-bit words.
> 
> Then, we know that (a[0] * b[8]) and (a[8] * b[0]) are multiplying between 31-bits words and 26-bits words.  So we have the equivalent computation for the a and b values above:
> 
> a[1]=a[2]=a[3]=a[4]=a[5]=a[6]=a[7]=0x7FFFFFFF;
> b[1]=b[2]=b[3]=b[4]=b[5]=b[6]=b[7]=0x7FFFFFFF;
> long i1x7 = (a[1] * b[7]) + (a[2] * b[6]) + (a[3] * b[5]) + (a[4] * b[4]) + (a[5] * b[3]) + (a[6] * b[2]) + (a[7] * b[1]) 
>               = 0xBFFFFFF900000007L
> long i0x8 =  (a[0] * b[8]) +  (a[8] * b[0]);
>               = 0x03FFFFFEF8000002L
> 
> long c8 = i1x7 + i0x8
>              = 0xC3FFFFF7F8000009L
> 
> 
> c8 fills the 64 bits fully, but it does not overflow.
> 
> @djelinski does it sound right to you?
> 
> Although there is not overflow if I get the above computation right, it is still not a straightforward thing we can know without detailed computation.  Instead, this kind of computation and checking could be performed in FieldGen code automatically, or just reduce limbs operations result (up to no more than twice the modulus) and remove the limit of maxAdd.
> 
> This RFE, JDK-8294248, is one of a few performance improvement of the EC implementation in JDK ([JDK-8294188](https://bugs.openjdk.org/browse/JDK-8294188)).  I would like to address the checking or/and reducing improvement in a separately RFE.

> @XueleiFan as far as I can tell, we cannot assume that the starting number will be 256 bit; the `setReduced` operation performs a limited reduce that only ensures that limbs fit in bitsPerLimb; the carry from the last limb is only performed in `finalCarryReduceLast`.

Thank you @djelinski, I missed this point.

I tried to prototype and allow only one addition, and use reduce if necessary, and get the following benchmarking numbers:

Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
Signatures.sign               64  thrpt   15  1.629 ? 0.008  ops/ms
Signatures.sign              512  thrpt   15  1.628 ? 0.007  ops/ms
Signatures.sign             2048  thrpt   15  1.625 ? 0.006  ops/ms
Signatures.sign            16384  thrpt   15  1.588 ? 0.014  ops/ms
ECKeyGen.keyPairGen               thrpt   15  1.779 ?(99.9%) 0.007 ops/ms
``` 

The improvement looks positive to me (15%-20% improvement).   It implies that it may be performance friendly by reducing or semi-reducing limbs operations rather than using maxAdd controlling.  However, as the update would impact more curves in JDK, I would think it twice if it is good to start from it or not.

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

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

From xuelei at openjdk.org  Sun Sep 25 05:55:11 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sun, 25 Sep 2022 05:55:11 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <NyKl5HSgB7TqJny9gAKYAt1VQpNFdd3Iwwv-HdD8pjY=.8c71f7c9-83d7-4a82-a8d0-c084044164c7@github.com>

On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

Close this PR for now.  I may re-open it again when the long overflow issues get addressed.

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

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

From xuelei at openjdk.org  Sun Sep 25 05:55:12 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sun, 25 Sep 2022 05:55:12 GMT
Subject: Withdrawn: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <Q7JulcewYXMsa7n6-vppfnsLPHzpczjReGYxmjK2DHE=.6d769a01-a670-4631-8550-7cd8cbd521df@github.com>

On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

This pull request has been closed without being integrated.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

Commit messages:
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.

Done: https://bugs.openjdk.org/browse/SKARA-1566

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

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

From jpai at openjdk.org  Sun Sep 25 17:04:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
Message-ID: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>

On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.
> 
> Done: https://bugs.openjdk.org/browse/SKARA-1566

Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
Message-ID: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>

On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> these changes are mostly fine.

Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?  It doesn't seem useful to make a pull request with known deficiencies.

> we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

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

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
 <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
Message-ID: <RWGt4_adstjnxq1OHM-jBMqSjzlLdAqNrpTu3JozTYM=.36dbfb8e-bbfc-4853-ad43-dbeb78bfd92d@github.com>

On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?

These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification.

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

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

From jpai at openjdk.org  Sun Sep 25 17:04:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Hello Michael,

> > these changes are mostly fine.
> 
> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies.

I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `<bugid>: <bug summary>`). 
I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
Message-ID: <kqbMO6iHpa3xNDX1Ooa6zLtG9rZJK7mBogbO83RQQLs=.b1cb0e4a-032b-438e-b1a4-7644680ecd6b@github.com>

On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

OK.  I'll repeat my comment from before:

> Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
Message-ID: <MnLhhKzLqR1jb7PbtrJu2AlU4xQ5EolX_Zi7TUsJ96g=.e03c2f32-7815-40e8-9450-b66e425c31ef@github.com>

On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy <duke at openjdk.org> wrote:

> Oh no what happened

Oops!  Thanks for pointing out the goof.  It seems to be fixed now.

It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly.  It would be great to merge this pull request to avoid the need for more merges.

> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:
> 
>> 1051:    * fetch will take place at index 1.
>> 1052:    *
>> 1053:    * @return The current position index.
> 
> Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

Thanks for pointing out the inconsistency.  I have fixed it.  (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.)

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

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

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Oh no what happened
![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:

> 1051:    * fetch will take place at index 1.
> 1052:    *
> 1053:    * @return The current position index.

Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

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

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

From alanb at openjdk.org  Sun Sep 25 17:04:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

src/java.base/share/native/libzip/zlib/zlib.h line 756:

> 754:    If this is done, the old level and strategy will be applied to the data
> 755:    compressed before deflateParams(), and the new level and strategy will be
> 756:    applied to the data compressed after deflateParams().

This is an issue for the upstream zlib project, we probably don't want to change it here.

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

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

From lancea at openjdk.org  Sun Sep 25 17:04:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
Message-ID: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>

On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 
>> 754:    If this is done, the old level and strategy will be applied to the data
>> 755:    compressed before deflateParams(), and the new level and strategy will be
>> 756:    applied to the data compressed after deflateParams().
> 
> This is an issue for the upstream zlib project, we probably don't want to change it here.

Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
 <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
Message-ID: <rIuyz9yAlhyXwOpBnnAnmL0xQZbMk6bbr8QP4iogfzk=.33cce124-d245-46de-bb74-f3eaf9dbdfd8@github.com>

On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/zlib.h line 756:
>> 
>>> 754:    If this is done, the old level and strategy will be applied to the data
>>> 755:    compressed before deflateParams(), and the new level and strategy will be
>>> 756:    applied to the data compressed after deflateParams().
>> 
>> This is an issue for the upstream zlib project, we probably don't want to change it here.
>
> Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

OK.  I backed out the change to zlib.

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

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

From duke at openjdk.org  Sun Sep 25 17:23:28 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:23:28 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <l_BuZBAL5oEJ3CbI12q_XE9gFcXd-qEwGsRrSaIJDd0=.dea17f4e-b629-43e4-bc7e-47fccac4cb3a@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would.

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

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

From joehw at openjdk.org  Mon Sep 26 16:16:34 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 16:16:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <pGtnJ74g_UpsFiU5TaZ6E9jk1p0koWYtWUaoecRoxxk=.e98efc77-50d4-4959-a289-23e6a54380b8@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc.  Otherwise, I would suggest you contribute such changes to the upstream projects.  Thanks.

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

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

From mernst at openjdk.org  Mon Sep 26 16:51:36 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Mon, 26 Sep 2022 16:51:36 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01
  Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

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

From joehw at openjdk.org  Mon Sep 26 17:04:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 17:04:25 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <tTqHK2uU740KHuTMKapHnLcgfUbNs-4NqM-tQpds9HQ=.ba0b289d-011f-4f84-beeb-e20dd15a7d67@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thanks for the update!

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

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

From lancea at openjdk.org  Mon Sep 26 19:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 19:38:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thank you for your efforts on the cleaning up these typos

I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.  

I realize the changes are fairly trivial but this will most likely expedite getting your changes back

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

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

From mullan at openjdk.org  Tue Sep 27 20:35:21 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 27 Sep 2022 20:35:21 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>

On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312:

> 310:     }
> 311: 
> 312:     private static void emitInitialSecurityProperties() {

Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT.

src/jdk.jfr/share/conf/jfr/default.jfc line 713:

> 711: 
> 712:     <event name="jdk.InitialSecurityProperty">
> 713:       <setting name="enabled">true</setting>

The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.

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

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

From mernst at openjdk.org  Tue Sep 27 23:16:16 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Sep 2022 23:16:16 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>

On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Thank you for your efforts on the cleaning up these typos
> 
> I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.
> 
> I realize the changes are fairly trivial but this will most likely expedite getting your changes back

Feel free to break up the pull request if that is what is needed to free it from red tape.
Thanks.

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

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

From yangyuping at cn.panasonic.com  Wed Sep 28 01:58:55 2022
From: yangyuping at cn.panasonic.com (=?utf-8?B?WWFuZ1l1cGluZyjmnajnkZzokI0p?=)
Date: Wed, 28 Sep 2022 01:58:55 +0000
Subject: ECCN for openJDK
Message-ID: <BJSPR01MB04843E8AA91D04604D45DE27FD549@BJSPR01MB0484.CHNPR01.prod.partner.outlook.cn>

Hello, this is Panasonic software development department.
Is there any ECCN restriction for openJDK?
Thank you.

******************************************************************************************
? ???Yang YuPing??<yangyuping at cn.panasonic.com>
?????????????PFSS?   R&D???? ??????
?????????????????1?
Panasonic Factory Solutions Suzhou Co.,Ltd (PFSS)  R&D Center
TEL?+86-(0)512-80991188-393  FAX?+86-(0)512-62957913
******************************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220928/359be407/attachment.htm>

From jpai at openjdk.org  Wed Sep 28 07:10:22 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Sep 2022 07:10:22 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <HVbwXxN92O7Q9shNIuVCnREo0SVI-fGZSVWqaz2eZVE=.4dc123f2-8bda-42d0-867f-a7dbecc7a857@github.com>

On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Hello Sean,

> Debug output is also now added for these properties via -Djava.security.debug=properties

Looking at the existing code upstream, it appears that the value `properties` is already recognized for `java.security.debug` system property. So it's not something this PR is introducing/proposing. However, the documentation for this system property doesn't seem to be listing that as a value https://docs.oracle.com/en/java/javase/19/security/troubleshooting-security.html. Do you think that documentation would need to be addressed (as a separate issue)?

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

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

From duke at openjdk.org  Wed Sep 28 08:14:17 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 28 Sep 2022 08:14:17 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
Message-ID: <Z9Szpi8Hj5eA0fsBxP1JrnhXX_-EymK9za0IhRd-Kz0=.3acf8ddd-c045-46aa-90dc-206b0663f7e7@github.com>

On Tue, 20 Sep 2022 22:12:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
> "(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.
> 
> Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.
> 
> This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.
> 
> Thanks,
> Xuelei

I think Aleksey's first two points (the negative ones) are really weak: the new expressions are pretty easily provably equivalent with the old ones (if someone does not believe what the comment states, they can easily fill out two 8-line truth tables to convince themselves) and the height of the expression trees do not change, either. So I would say, go ahead with the change, especially since it helps on some architectures.

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

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

From coffeys at openjdk.org  Wed Sep 28 10:09:41 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 10:09:41 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
Message-ID: <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>

On Tue, 27 Sep 2022 20:29:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312:
> 
>> 310:     }
>> 311: 
>> 312:     private static void emitInitialSecurityProperties() {
> 
> Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT.

Good catch. JFR does load the Security class [1] via other dependencies but we shouldn't depend on that. I'll add a null check here. If Security class hasn't been loaded, then we shouldn't record any events.


[1]
java.lang.Throwable
        at java.base/java.security.Security.<clinit>(Security.java:73)
        at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
        at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
        at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
        at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
        at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
        at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
        at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
        at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
        at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
        at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
        at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

> src/jdk.jfr/share/conf/jfr/default.jfc line 713:
> 
>> 711: 
>> 712:     <event name="jdk.InitialSecurityProperty">
>> 713:       <setting name="enabled">true</setting>
> 
> The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.

Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 

We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.

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

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

From coffeys at openjdk.org  Wed Sep 28 10:16:22 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 10:16:22 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <rwmqU_nerPgYMzJ2MyQ5kr81jRdcmiV2VBvpbE4CaPI=.d67db897-460d-4141-b565-9ab8ba65bfb5@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Null check on Properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/5343a056..aed938d2

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

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

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

From coffeys at openjdk.org  Wed Sep 28 10:16:24 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 10:16:24 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <HVbwXxN92O7Q9shNIuVCnREo0SVI-fGZSVWqaz2eZVE=.4dc123f2-8bda-42d0-867f-a7dbecc7a857@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <HVbwXxN92O7Q9shNIuVCnREo0SVI-fGZSVWqaz2eZVE=.4dc123f2-8bda-42d0-867f-a7dbecc7a857@github.com>
Message-ID: <vpJ3K6Fzruk9P1OvaUd0F7azraM73R6SeLV51xVojMk=.d23f6da9-8da1-4e70-8ef0-f596bf69f1b4@github.com>

On Wed, 28 Sep 2022 07:06:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Sean,
> 
> > Debug output is also now added for these properties via -Djava.security.debug=properties
> 
> Looking at the existing code upstream, it appears that the value `properties` is already recognized for `java.security.debug` system property. So it's not something this PR is introducing/proposing. However, the documentation for this system property doesn't seem to be listing that as a value https://docs.oracle.com/en/java/javase/19/security/troubleshooting-security.html. Do you think that documentation would need to be addressed (as a separate issue)?

Good point Jai. It's a rarely used property value I guess, but it would be exposed via the "all" debug value option as per test. I suspect there may be other such properties also. I'll log a JBS issue to track this and to have security/docs team discuss.

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

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

From mullan at openjdk.org  Wed Sep 28 12:30:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 28 Sep 2022 12:30:23 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
Message-ID: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>

On Wed, 28 Sep 2022 10:06:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/jdk.jfr/share/conf/jfr/default.jfc line 713:
>> 
>>> 711: 
>>> 712:     <event name="jdk.InitialSecurityProperty">
>>> 713:       <setting name="enabled">true</setting>
>> 
>> The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.
>
> Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 
> 
> We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.

Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right?

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

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

From coffeys at openjdk.org  Wed Sep 28 12:54:19 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 12:54:19 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
Message-ID: <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>

On Wed, 28 Sep 2022 12:26:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 
>> 
>> We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.
>
> Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right?

Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level)

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

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

From dfuchs at openjdk.org  Wed Sep 28 13:24:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:24:26 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
 <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
Message-ID: <aY7BXF5EIYZFFZcE_IWj3PwKjQLD35cJPnaJkvQpQmU=.5464c3b4-6a6b-4841-b24f-969b371dfc74@github.com>

On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Feel free to break up the pull request if that is what is needed to free it from red tape.

Only you can do that @mernst

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

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

From mernst at openjdk.org  Wed Sep 28 14:49:20 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 14:49:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Regarding breaking up the pull request:
 * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
 * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
 * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.

I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections.

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

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

From dfuchs at openjdk.org  Wed Sep 28 15:13:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 15:13:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
Message-ID: <kTzLFBRbJQt3hKHD094hV-0zXH9FY4Fg2wdrOvFeK34=.c79081a5-df9a-4ea0-b481-19f903f56bd9@github.com>

On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> Regarding breaking up the pull request:
>  * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
>  * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams.  The only reasons stated have been custom and bureaucracy.
>  * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
>  * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions.  No pointer to documentation in the JDK itself, about pull requests, was given.
>  * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.
> 
> I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions.

Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas:

-     client
-     compiler
-     core-libs
-     hotspot
-     i18n
-     javadoc
-     jmx
-     net
-     nio
-     security
-     serviceability

Jaikiran suggested to reduce the scope of this PR in his first comment:
https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632

as did several other reviewers. Sorry if the meaning (or reason) was not clear.

best regards,

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

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

From aivanov at openjdk.org  Wed Sep 28 15:28:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:28:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

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

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

From mernst at openjdk.org  Wed Sep 28 15:35:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 15:35:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
Message-ID: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>

On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

The title was edited by someone other than me, as you can see from the PR history.

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

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

From mullan at openjdk.org  Wed Sep 28 16:36:15 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 28 Sep 2022 16:36:15 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
Message-ID: <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>

On Wed, 28 Sep 2022 12:52:02 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right?
>
> Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level)

How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled.

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

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

From xuelei at openjdk.org  Wed Sep 28 16:58:25 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 28 Sep 2022 16:58:25 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <Z9Szpi8Hj5eA0fsBxP1JrnhXX_-EymK9za0IhRd-Kz0=.3acf8ddd-c045-46aa-90dc-206b0663f7e7@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
 <Z9Szpi8Hj5eA0fsBxP1JrnhXX_-EymK9za0IhRd-Kz0=.3acf8ddd-c045-46aa-90dc-206b0663f7e7@github.com>
Message-ID: <sXYurAQ1uPGTqUZ9ECl6TFC5Dwj6RV70xI5f4q9AVGw=.fd85f1db-dbf7-4137-8c15-f254a31058bf@github.com>

On Wed, 28 Sep 2022 08:12:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Hi,
>> 
>> In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
>> "(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.
>> 
>> Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.
>> 
>> This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.
>> 
>> Thanks,
>> Xuelei
>
> I think Aleksey's first two points (the negative ones) are really weak: the new expressions are pretty easily provably equivalent with the old ones (if someone does not believe what the comment states, they can easily fill out two 8-line truth tables to convince themselves) and the height of the expression trees do not change, either. So I would say, go ahead with the change, especially since it helps on some architectures.

@ferakocz Thank you for the comment.  I added comment about the equality of the functions comparing to SHA-2 papers or specifications.  Hopefully, it could be  easier for readers to understand the point.

Can I have reviewed if anyone has cycles and no objections?

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

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

From alanb at openjdk.org  Wed Sep 28 19:19:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 19:19:56 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
Message-ID: <stOdNp4NzKMMvXuB88KOCEXfufzRQ9Zqfn2SdZxIryk=.c5fbc4fa-9342-4ebd-a799-3887fc1e6388@github.com>

On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verification note from JarFile

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Wed Sep 28 19:19:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 19:19:56 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <bfiWxsz5ohoh3D5f1Sq4Pc1G48_tVhL0bQXLJfj0zEo=.180cd786-8b05-4a79-82fe-4a8ac786c806@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
 <bfiWxsz5ohoh3D5f1Sq4Pc1G48_tVhL0bQXLJfj0zEo=.180cd786-8b05-4a79-82fe-4a8ac786c806@github.com>
Message-ID: <QlqVDCWJp_zs3vRwYaslpQMA2kGcHkwK5AExLYBhbx0=.42e2d6ea-e294-49dc-bc21-d0ff7766f731@github.com>

On Fri, 23 Sep 2022 17:45:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Do you also want to say "Otherwise, the method returns `null`."

The method description has that already, it might be too much detail to include in the class description,.

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

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

From lancea at openjdk.org  Wed Sep 28 19:25:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Sep 2022 19:25:45 GMT
Subject: Integrated: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <UtKzhEFnHon6wRfLX9aKL6l6HRUdIVzfux7tsV2x6J4=.73289fc9-9a39-4e67-a988-064552faf06b@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: 9db95edd
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9db95edd0133cb31358416829c942f5dcb84fc55
Stats:     61 lines in 1 file changed: 52 ins; 0 del; 9 mod

8215788: Clarify JarInputStream Manifest access

Reviewed-by: weijun, mullan, alanb

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

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

From coffeys at openjdk.org  Thu Sep 29 10:04:18 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 29 Sep 2022 10:04:18 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
Message-ID: <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>

On Wed, 28 Sep 2022 16:32:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level)
>
> How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled.

As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. 
@egahlin - would you have a preference on this ?

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

PR: https://git.openjdk.org/jdk/pull/10394

From egahlin at openjdk.org  Thu Sep 29 11:43:11 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 29 Sep 2022 11:43:11 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
Message-ID: <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>

On Thu, 29 Sep 2022 10:02:05 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled.
>
> As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. 
> @egahlin - would you have a preference on this ?

With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data.

That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories?

If the event triggers class loading, it might make sense to check if the event is enabled first.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Thu Sep 29 15:14:28 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 29 Sep 2022 15:14:28 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
 <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
Message-ID: <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>

On Thu, 29 Sep 2022 11:41:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. 
>> @egahlin - would you have a preference on this ?
>
> With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data.
> 
> That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories?
> 
> If the event triggers class loading, it might make sense to check if the event is enabled first.

Thanks @egahlin  - maybe we can leave it at beginChunk setting then.

I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). 

This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. 

`ProtectionDomain ` is a very early class to initialize [1] (initPhase2)

Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps  [2] - the JMX thread starts after about 3 seconds of runtime.

Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test.

If JFR is on, then Security class is already being loaded, even without this patch [3]

[1]

	at java.base/java.security.ProtectionDomain.<clinit>(ProtectionDomain.java:64)
	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:316)
	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:431)
	at java.base/java.security.SecureClassLoader.<init>(SecureClassLoader.java:113)
	at java.base/jdk.internal.loader.BuiltinClassLoader.<init>(BuiltinClassLoader.java:194)
	at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.<init>(ClassLoaders.java:135)
	at java.base/jdk.internal.loader.ClassLoaders.<clinit>(ClassLoaders.java:79)
	at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120)
	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266)
	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
	at java.base/java.lang.System.initPhase2(System.java:2214)


[2]

	at java.base/java.security.Security.<clinit>(Security.java:73)
	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93)
	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at java.base/sun.net.InetAddressCachePolicy.<clinit>(InetAddressCachePolicy.java:89)
	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005)
	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524)
	at java.base/java.net.InetAddress.getByName(InetAddress.java:1413)
	at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531)
	at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317)


[3]


	at java.base/java.security.Security.<clinit>(Security.java:73)
	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
	at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
	at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
	at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
	at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
	at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
	at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
	at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
	at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
	at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From darcy at openjdk.org  Fri Sep 30 00:40:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:40:24 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
Message-ID: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>

With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.

Updates were made using a shell script. I"ll run a copyright updater before any push.

-------------

Commit messages:
 - JDK-8294618: Update openjdk.java.net => openjdk.org

Changes: https://git.openjdk.org/jdk/pull/10501/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294618
  Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 00:54:05 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:54:05 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright.
 - Revert unintended update to binary file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01

  Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From mikael at openjdk.org  Fri Sep 30 00:54:08 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:08 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Switch to https where needed/applicable while at it?

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From mikael at openjdk.org  Fri Sep 30 00:54:06 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:06 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
Message-ID: <dFUTds1k1M7DaK_xGvMGBDegFeXy76CIcZ_PLh6gYC4=.188412c8-2ca0-42bb-a284-910d88d53422@github.com>

On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright.
>  - Revert unintended update to binary file.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:01:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:01:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <boxVctVZD3zFCVCc9kH4kEwNs-yE1UY9fP1YMTqCWlc=.171a92b3-ddf2-4e51-b3ec-ae5c5a265487@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Undo manpage update.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  http -> https

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03

  Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
Message-ID: <uBCZJHk7h3OFdIKNzXs7DXXlCJUbhiSGt7HZOnDf51Q=.c58467fe-b9cd-4edf-83af-ae99c17c196a@github.com>

On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Switch to https where needed/applicable while at it?

Good idea; might as well do the update in a single changeset.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From iris at openjdk.org  Fri Sep 30 04:11:19 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Sep 2022 04:11:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

Marked as reviewed by iris (Reviewer).

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:

> 32:  * the following link:
> 33:  *
> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c

The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From ihse at openjdk.org  Fri Sep 30 14:01:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Sep 2022 14:01:18 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

$ grep -rl doc make -e openjdk.java.net
doc/hotspot-unit-tests.html
doc/hotspot-style.html
doc/building.html
doc/hotspot-unit-tests.md
doc/hotspot-style.md
doc/building.md
make/Doctor.gmk
make/jdk/src/classes/build/tools/taglet/Incubating.java
make/autoconf/configure.ac
make/conf/branding.conf


Think you can fix those as well?

Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From weijun at openjdk.org  Fri Sep 30 14:18:28 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Sep 2022 14:18:28 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>

On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   http -> https
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
> 
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From prr at openjdk.org  Fri Sep 30 17:42:29 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 17:42:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
Message-ID: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>

On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>> 
>>> 32:  * the following link:
>>> 33:  *
>>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 
>> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

This is correct.
AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From joehw at openjdk.org  Fri Sep 30 18:12:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 30 Sep 2022 18:12:25 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <e9sYCA3vCcVdXUjRRnPbEK3Z7Ik5WANQMziL6OStdts=.aa1ad3f4-5d91-485d-b48f-3c59579f1869@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

The ones in java.xml look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10501

From mullan at openjdk.org  Fri Sep 30 19:36:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 Sep 2022 19:36:23 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
 <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
 <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>
Message-ID: <j4k9R1AoIxafqLpYbXI7jAvBWX2S6BRsXGgLMyuH5_s=.f513dae6-42ac-4c83-b077-981c74779f4e@github.com>

On Thu, 29 Sep 2022 15:12:06 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data.
>> 
>> That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories?
>> 
>> If the event triggers class loading, it might make sense to check if the event is enabled first.
>
> Thanks @egahlin  - maybe we can leave it at beginChunk setting then.
> 
> I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). 
> 
> This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. 
> 
> `ProtectionDomain ` is a very early class to initialize [1] (initPhase2)
> 
> Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps  [2] - the JMX thread starts after about 3 seconds of runtime.
> 
> Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test.
> 
> If JFR is on, then Security class is already being loaded, even without this patch [3]
> 
> [1]
> 
> 	at java.base/java.security.ProtectionDomain.<clinit>(ProtectionDomain.java:64)
> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:316)
> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:431)
> 	at java.base/java.security.SecureClassLoader.<init>(SecureClassLoader.java:113)
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.<init>(BuiltinClassLoader.java:194)
> 	at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.<init>(ClassLoaders.java:135)
> 	at java.base/jdk.internal.loader.ClassLoaders.<clinit>(ClassLoaders.java:79)
> 	at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120)
> 	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266)
> 	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
> 	at java.base/java.lang.System.initPhase2(System.java:2214)
> 
> 
> [2]
> 
> 	at java.base/java.security.Security.<clinit>(Security.java:73)
> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93)
> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
> 	at java.base/sun.net.InetAddressCachePolicy.<clinit>(InetAddressCachePolicy.java:89)
> 	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005)
> 	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658)
> 	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524)
> 	at java.base/java.net.InetAddress.getByName(InetAddress.java:1413)
> 	at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531)
> 	at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317)
> 
> 
> [3]
> 
> 
> 	at java.base/java.security.Security.<clinit>(Security.java:73)
> 	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
> 	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
> 	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
> 	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
> 	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
> 	at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
> 	at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
> 	at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
> 	at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

When support for the SM is removed, the dependency on `AccessController.doPrivileged` will be removed and there may no longer be a JFR dependency on loading the `Security` class. So, it is ok for now, but a solution that doesn't depend on this might be better in the long run.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From darcy at openjdk.org  Fri Sep 30 20:29:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:20 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <amUS-nAMV81aBx2GLfnDtuk_O_MhFE1Oi0Sxs2DYy2o=.d8155a10-80d6-4ab2-9f2a-4bc8ee61b96b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy 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:

 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - JDK-8294618: Update openjdk.java.net => openjdk.org

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04

  Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 20:29:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:21 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
Message-ID: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>

On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Yes; I think it is sufficient to update src and doc with this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 20:29:22 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:22 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <q7j-egb4NojCIVKfF-PxraFVvU3FucPfulisSzexu30=.888b04a2-1624-4de1-a81c-e65e747ccd73@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

> This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Update to persistent git links.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From joe.darcy at oracle.com  Fri Sep 30 04:41:06 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 29 Sep 2022 21:41:06 -0700
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com>

Thanks for catching that Iris; I'll changes those to git URLs.

-Joe

On 9/29/2022 9:11 PM, Iris Clark wrote:
> On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>>>
>>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    http -> https
> Marked as reviewed by iris (Reviewer).
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10501