From mullan at openjdk.org  Tue Jan  2 13:45:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Jan 2024 13:45:48 GMT
Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms
 [v2]
In-Reply-To: <ebixVoOq3D96Qaey4lHccOw5gXz9CVnIBF-hhWFZq4Y=.4b74f4ee-1dec-43fb-8cbc-1a63d36b5931@github.com>
References: <wycXUvfwu2oxsJSQ7VRx_SYILCu1KEuO9QDhBNilV7A=.18b1c633-3d04-4a3f-9f38-bcd5e5d2bf52@github.com>
 <ebixVoOq3D96Qaey4lHccOw5gXz9CVnIBF-hhWFZq4Y=.4b74f4ee-1dec-43fb-8cbc-1a63d36b5931@github.com>
Message-ID: <VvZujHF2yec_mJAEpsK1W4i4fXl0J4m47y050Cirh9U=.f4b8c2a8-48c6-43c6-8418-0d3484b97f76@github.com>

On Sat, 30 Dec 2023 00:48:00 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`.
>> It may be better to use `PKCS12` and `PKIX` respectively.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use default algorithms

Can you change the bug summary to "Micro bench SSLHandshake should use modern algorithms"?

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

PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1874042757


From jjiang at openjdk.org  Tue Jan  2 14:07:46 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 2 Jan 2024 14:07:46 GMT
Subject: RFR: 8322766: Micro bench SSLHandshake should use default
 algorithms [v2]
In-Reply-To: <VvZujHF2yec_mJAEpsK1W4i4fXl0J4m47y050Cirh9U=.f4b8c2a8-48c6-43c6-8418-0d3484b97f76@github.com>
References: <wycXUvfwu2oxsJSQ7VRx_SYILCu1KEuO9QDhBNilV7A=.18b1c633-3d04-4a3f-9f38-bcd5e5d2bf52@github.com>
 <ebixVoOq3D96Qaey4lHccOw5gXz9CVnIBF-hhWFZq4Y=.4b74f4ee-1dec-43fb-8cbc-1a63d36b5931@github.com>
 <VvZujHF2yec_mJAEpsK1W4i4fXl0J4m47y050Cirh9U=.f4b8c2a8-48c6-43c6-8418-0d3484b97f76@github.com>
Message-ID: <TXY9iPdiVSsEHvPnU_QSBbmdOwM6qXUp3IAmm9Ox7gA=.364cbd07-17cb-4285-8c33-c8a54afe6422@github.com>

On Tue, 2 Jan 2024 13:43:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use default algorithms
>
> Can you change the bug summary to "Micro bench SSLHandshake should use modern algorithms"?

@seanjmullan 
The last commit uses the default algorithms, so I just changed the summary to "Micro bench SSLHandshake should use default algorithms".

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

PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1874067097


From duke at openjdk.org  Tue Jan  2 14:13:52 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 2 Jan 2024 14:13:52 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
Message-ID: <7N-RSj57bmy750gwGeCCjg5cU-vF4i8iDa_MsbD4YjU=.52e762e2-3f40-4f87-8f04-9ac18194e0a0@github.com>

On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed more line breaks
>  - fixed line breaks

Still working on this

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

PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1874073990


From prappo at openjdk.org  Tue Jan  2 14:37:27 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 2 Jan 2024 14:37:27 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v10]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

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

 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Fix bugs in Shared.createSingle
 - Merge branch 'master' into 8310813
 - Group params coarser (suggested by @cl4es)
   
   - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
     Every testXYZ method invokes M operations, where M is the maximum
     number of elements in a group. Shorter groups are cyclically padded.
   - Uses the org.openjdk.jmh.infra.Blackhole API and increases
     benchmark time.
   - Fixes a bug in Shared that precluded 0 from being in a pair.
 - Use better overloads (suggested by @cl4es)
   
   - Uses simpler, more suitable overloads for the subrange
     starting from 0
 - Improve benchmarks
 - Merge branch 'master' into 8310813
 - ... and 7 more: https://git.openjdk.org/jdk/compare/cd913e32...252b7378

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/ef8b0c46..252b7378

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=08-09

  Stats: 4826 lines in 316 files changed: 2898 ins; 812 del; 1116 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

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


From stefank at openjdk.org  Tue Jan  2 15:36:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:10 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v3]
In-Reply-To: <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
 <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
Message-ID: <yDnkf3CvvXwTidrzaz6lrvS6XZVKBLVbJEOqBXwPi6M=.e4ddf28f-f03d-4c37-b831-a7206a202755@github.com>

On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
>> 
>> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
>> 
>> With these functions it is common to see the following pattern in tests:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = executeProcess(pb);
>> 
>> 
>> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
>> 
>> OutputAnalyzer output = ProcessTools.executeTestJvm();
>> 
>> 
>> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17049#issuecomment-1874176578


From stefank at openjdk.org  Tue Jan  2 15:36:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:07 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v4]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <yEDcAV7XwAPsBX5Z4vPBDDUowP57us2a3WIW5bJ6vyk=.d55a077c-b8c9-4050-ad9d-08337753fbae@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

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

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/5d488f42..486dc6d5

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

  Stats: 5249 lines in 348 files changed: 3069 ins; 973 del; 1207 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

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


From duke at openjdk.org  Tue Jan  2 18:25:37 2024
From: duke at openjdk.org (Ben Perez)
Date: Tue, 2 Jan 2024 18:25:37 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute
In-Reply-To: <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
Message-ID: <rIPMY7WYts2vAJHfuTWxbucs-SUo9oNsR1lR0k1hj4Y=.f4e05c0e-7697-4938-87c3-989b49a8868c@github.com>

On Thu, 21 Dec 2023 16:27:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 186:
> 
>> 184:     /**
>> 185:      * Array of attribute OIDs defined in PKCS9, by number.
>> 186:      */
> 
> I don't think `PKCS9_OIDS` is useful now. It's used in `PKCS9Attributes.getAttributes()` but this method is used nowhere. It's also used in `PKCS9Attributes.toString` but we can just iterate through `attributes` there. I don't see a reason to print the attributes in this order. If we want to print them in the order they appear in the data, we can use `LinkedHashMap` to in `PKCS9Attributes`. `Hashtable` is a little stale.

Do you think we can remove `PKCS9Attributes.getAttributes()` entirely or should we just modify it to not use `PKCS9_OIDS` anymore?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1439704152


From weijun at openjdk.org  Tue Jan  2 21:56:46 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 Jan 2024 21:56:46 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute
In-Reply-To: <rIPMY7WYts2vAJHfuTWxbucs-SUo9oNsR1lR0k1hj4Y=.f4e05c0e-7697-4938-87c3-989b49a8868c@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
 <rIPMY7WYts2vAJHfuTWxbucs-SUo9oNsR1lR0k1hj4Y=.f4e05c0e-7697-4938-87c3-989b49a8868c@github.com>
Message-ID: <RuJCHjzq2sYzhwbkcl64hDLA9Q6qVbthRGGtac6FUdI=.cf95ed10-3ce7-4071-b832-d27382f334db@github.com>

On Tue, 2 Jan 2024 18:22:51 GMT, Ben Perez <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 186:
>> 
>>> 184:     /**
>>> 185:      * Array of attribute OIDs defined in PKCS9, by number.
>>> 186:      */
>> 
>> I don't think `PKCS9_OIDS` is useful now. It's used in `PKCS9Attributes.getAttributes()` but this method is used nowhere. It's also used in `PKCS9Attributes.toString` but we can just iterate through `attributes` there. I don't see a reason to print the attributes in this order. If we want to print them in the order they appear in the data, we can use `LinkedHashMap` to in `PKCS9Attributes`. `Hashtable` is a little stale.
>
> Do you think we can remove `PKCS9Attributes.getAttributes()` entirely or should we just modify it to not use `PKCS9_OIDS` anymore?

I think we can remove both. There is no need to keep a useless method as long as it's not an exported API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1439897759


From stefank at openjdk.org  Wed Jan  3 07:55:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 07:55:12 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v5]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <GpEb2qpnxJqXX5Ogimr2sbaXPOyFbB7wh06f0a47vc8=.96bd91bf-8487-49e0-8112-77843e7e3b15@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

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

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/486dc6d5..755d925d

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

  Stats: 875 lines in 70 files changed: 577 ins; 58 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

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


From djelinski at openjdk.org  Wed Jan  3 08:19:46 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Jan 2024 08:19:46 GMT
Subject: RFR: 8322766: Micro bench SSLHandshake should use default
 algorithms [v2]
In-Reply-To: <ebixVoOq3D96Qaey4lHccOw5gXz9CVnIBF-hhWFZq4Y=.4b74f4ee-1dec-43fb-8cbc-1a63d36b5931@github.com>
References: <wycXUvfwu2oxsJSQ7VRx_SYILCu1KEuO9QDhBNilV7A=.18b1c633-3d04-4a3f-9f38-bcd5e5d2bf52@github.com>
 <ebixVoOq3D96Qaey4lHccOw5gXz9CVnIBF-hhWFZq4Y=.4b74f4ee-1dec-43fb-8cbc-1a63d36b5931@github.com>
Message-ID: <NVL2uFj8Ld_2OdFL1mx7E6S3o79RbdL6Jg6f52o9SiQ=.200b2e7a-ec2f-475a-94cc-c3272b12815a@github.com>

On Sat, 30 Dec 2023 00:48:00 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`.
>> It may be better to use `PKCS12` and `PKIX` respectively.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use default algorithms

Thank you. LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17202#pullrequestreview-1801543917


From jjiang at openjdk.org  Wed Jan  3 08:30:44 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 3 Jan 2024 08:30:44 GMT
Subject: RFR: 8322766: Micro bench SSLHandshake should use default
 algorithms [v2]
In-Reply-To: <z0-n82LLasz2f3UjPqVT5ZRvw7PGz5t2gOQkGkCU6cg=.93d0374a-b0fc-4962-a3ae-e2ffc35dc86f@github.com>
References: <wycXUvfwu2oxsJSQ7VRx_SYILCu1KEuO9QDhBNilV7A=.18b1c633-3d04-4a3f-9f38-bcd5e5d2bf52@github.com>
 <ebixVoOq3D96Qaey4lHccOw5gXz9CVnIBF-hhWFZq4Y=.4b74f4ee-1dec-43fb-8cbc-1a63d36b5931@github.com>
 <z0-n82LLasz2f3UjPqVT5ZRvw7PGz5t2gOQkGkCU6cg=.93d0374a-b0fc-4962-a3ae-e2ffc35dc86f@github.com>
Message-ID: <hptgOFSdrCQZZ8lvCFDmCVvWInzzl32XaRMd1I9-UNY=.16b01998-4819-431e-976e-cd471f266673@github.com>

On Sat, 30 Dec 2023 09:20:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use default algorithms
>
> Thanks. Users usually use the default algorithms, so benchmarking them is probably more useful than measuring the non-default ones.
> 
> There's a [ticket to update the default keyManager algorithm](https://bugs.openjdk.org/browse/JDK-8272875), so it may become the default one day. Did you compare the performance of the different algorithms?

@djelinski 
Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1874999547


From jjiang at openjdk.org  Wed Jan  3 08:30:45 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 3 Jan 2024 08:30:45 GMT
Subject: Integrated: 8322766: Micro bench SSLHandshake should use default
 algorithms
In-Reply-To: <wycXUvfwu2oxsJSQ7VRx_SYILCu1KEuO9QDhBNilV7A=.18b1c633-3d04-4a3f-9f38-bcd5e5d2bf52@github.com>
References: <wycXUvfwu2oxsJSQ7VRx_SYILCu1KEuO9QDhBNilV7A=.18b1c633-3d04-4a3f-9f38-bcd5e5d2bf52@github.com>
Message-ID: <cNiNa4pRMeUg1kh-t91WeYe4ASXkXdLw0DT7qg_fRJs=.79da08d3-cd10-4739-ac1c-c83d871540c1@github.com>

On Fri, 29 Dec 2023 06:49:26 GMT, John Jiang <jjiang at openjdk.org> wrote:

> test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`.
> It may be better to use `PKCS12` and `PKIX` respectively.

This pull request has now been integrated.

Changeset: 06dd7353
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/06dd73534271874eff008b8d3027f4ce49b136b3
Stats:     9 lines in 2 files changed: 1 ins; 0 del; 8 mod

8322766: Micro bench SSLHandshake should use default algorithms

Reviewed-by: djelinski

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

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


From stefank at openjdk.org  Wed Jan  3 08:55:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 08:55:54 GMT
Subject: Integrated: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <97p3loy_9ZZnMenWO0FMfeACOTWUjesg8dVD6fmYCzs=.160baa3e-3709-4ece-a3aa-986206b73148@github.com>

On Mon, 11 Dec 2023 09:15:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

This pull request has now been integrated.

Changeset: cbe329b9
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbe329b90ac1488836d4852fead79aa26c082114
Stats:     262 lines in 89 files changed: 73 ins; 1 del; 188 mod

8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

Reviewed-by: lkorinth, lmesnik

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

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


From mbaesken at openjdk.org  Wed Jan  3 11:47:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 11:47:54 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class
 name "java.util.Arrays"
Message-ID: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>

In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

Commit messages:
 - JDK-8322782

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

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


From alanb at openjdk.org  Wed Jan  3 13:32:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 13:32:38 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays"
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <9oRf6_NeT3KKnkiZNAwUlcK6kBs13ahenPR1iWFfcb8=.ed953023-01bb-45d0-858e-daf5d4d52093@github.com>

On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

Looks fine, surprised to see so many. I assume you'll bump the copyright date on all the files before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802064657


From mbaesken at openjdk.org  Wed Jan  3 13:51:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 13:51:03 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v2]
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <7MyzckmpbHdkVKO-GM7_sEkpOtRCN7wf2dBe50P7ptE=.8764e79c-d68b-4737-a906-31dadf47c140@github.com>

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

  adjust copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17241/files
  - new: https://git.openjdk.org/jdk/pull/17241/files/af1c0375..c06f35b5

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

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

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


From mbaesken at openjdk.org  Wed Jan  3 13:55:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 13:55:22 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

  Adjust Invokers.java too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17241/files
  - new: https://git.openjdk.org/jdk/pull/17241/files/c06f35b5..eac9ca69

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

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

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


From mbaesken at openjdk.org  Wed Jan  3 14:04:48 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 14:04:48 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <DT_MWVwT-RJ-7yBvvVC7b1g5Ydzaieys5v3KReYzyI4=.ba3f0f55-faf2-4988-bb39-4d8539ca075a@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Hi Alan, thanks for the review !
I adjust the copyright year info and also some more places in Invokers.java .

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

PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1875416193


From aivanov at openjdk.org  Wed Jan  3 16:53:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 3 Jan 2024 16:53:47 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <B4b8hcwJuDZ13_YT-Z3AmKful6e8fkxL1GkjF33HcuA=.0923da91-b9f8-4f70-8261-408d7db28edc@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802684965


From mullan at openjdk.org  Wed Jan  3 17:29:07 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 3 Jan 2024 17:29:07 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building certification
 paths
Message-ID: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>

This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.

[RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and increases the performance of `CertPathBuilder.build` by approximately 2x in tests involving certificates that do not contain KIDs. Specific changes include:

- Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
- Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
- `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
- The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

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

Commit messages:
 - Fix whitespace.
 - Update copyrights.
 - Merge
 - Simplify and improve performance of PKIXCertComparator.
 - Regression test.
 - Use shared secrets instead of reflection.
 - Remove obsolete methods.
 - Enhance code to use defaults for serial number and validity fields.
 - Use shared secrets instead of reflection. Remove obsolete methods.
 - Use shared secrets instead of reflection to access X500Name.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/84c23792...7098b73c

Changes: https://git.openjdk.org/jdk/pull/17248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317431
  Stats: 811 lines in 8 files changed: 319 ins; 460 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/17248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17248/head:pull/17248

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


From duke at openjdk.org  Wed Jan  3 18:46:23 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 3 Jan 2024 18:46:23 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute
In-Reply-To: <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
Message-ID: <NOnFrzEHRTXu4f_GVdqZBzB6ANkZ1lY4JumF__KpX7w=.8236f87c-fe45-4010-b15a-c39ed14d993b@github.com>

On Thu, 21 Dec 2023 17:01:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 344:
> 
>> 342:         info = oidMap.get(oid);
>> 343:         Class<?> clazz = (info == null) ? BYTE_ARRAY_CLASS : info.valueClass();
>> 344:         if (clazz == null) {
> 
> If we assign a class to `SIGNING_CERTIFICATE_OID`, this will never be null.

Would `sun.security.pkcs.SigningCertificateInfo` be appropriate here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1440798699


From weijun at openjdk.org  Wed Jan  3 19:14:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 Jan 2024 19:14:22 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute
In-Reply-To: <NOnFrzEHRTXu4f_GVdqZBzB6ANkZ1lY4JumF__KpX7w=.8236f87c-fe45-4010-b15a-c39ed14d993b@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
 <NOnFrzEHRTXu4f_GVdqZBzB6ANkZ1lY4JumF__KpX7w=.8236f87c-fe45-4010-b15a-c39ed14d993b@github.com>
Message-ID: <Rp-FGnkakZAE0o_Mklgw64KJLSpJv7Xi-3rzjjj0DBY=.9d007f5e-0176-40ff-93a5-2353cd8adfec@github.com>

On Wed, 3 Jan 2024 18:43:41 GMT, Ben Perez <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 344:
>> 
>>> 342:         info = oidMap.get(oid);
>>> 343:         Class<?> clazz = (info == null) ? BYTE_ARRAY_CLASS : info.valueClass();
>>> 344:         if (clazz == null) {
>> 
>> If we assign a class to `SIGNING_CERTIFICATE_OID`, this will never be null.
>
> Would `sun.security.pkcs.SigningCertificateInfo` be appropriate here?

I think so. In fact, I am curious why this class name has already appeared in this file but the value class assigned is still now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1440831641


From duke at openjdk.org  Wed Jan  3 20:39:57 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 3 Jan 2024 20:39:57 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/b8c2019f..32a2304c

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

  Stats: 114 lines in 2 files changed: 12 ins; 51 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/17132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17132/head:pull/17132

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


From weijun at openjdk.org  Wed Jan  3 20:48:00 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 Jan 2024 20:48:00 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party security
 provider is signed
Message-ID: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>

`KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.

Several adjustments to the test:
1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/17253/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322971
  Stats: 119 lines in 4 files changed: 74 ins; 29 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/17253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17253/head:pull/17253

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


From abakhtin at openjdk.org  Thu Jan  4 02:24:56 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 4 Jan 2024 02:24:56 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

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

  Add KeychainStore-ROOT keystore for root certificates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/db98b7c2..8fdea0f2

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

  Stats: 169 lines in 3 files changed: 121 ins; 21 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/16722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16722/head:pull/16722

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


From abakhtin at openjdk.org  Thu Jan  4 02:24:56 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 4 Jan 2024 02:24:56 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore
In-Reply-To: <zYSWfguP6KkoDgxwI4WS04wp_h4ZoKudRyxgQihipG0=.3e022794-332a-4b49-acce-2badc97abc30@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <zYSWfguP6KkoDgxwI4WS04wp_h4ZoKudRyxgQihipG0=.3e022794-332a-4b49-acce-2badc97abc30@github.com>
Message-ID: <dNrVSKs2IJ-onGOaGMXLe5gs5TAgs-3Kcp2N9uARiSw=.e59270b3-3ceb-4ba9-af07-c0f21144410e@github.com>

On Mon, 20 Nov 2023 13:49:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> How about putting these certs into a different keystore like Windows does (there are `Windows-MY` and `Windows-ROOT` there)? Anyway, there needs a CSR and release note for this big change.

As suggested by @wangweij, the new Keychain-ROOT keystore is introduced for the trusted anchor certificates.
The Keychain-ROOT keystore is read-only and throws KeyStoreException in an attempt to modification

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1876218683


From mbaesken at openjdk.org  Thu Jan  4 08:09:32 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Jan 2024 08:09:32 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <h5_ZKH7cVAf9LLYbYwTqfoD5L_UE2_KUlZZuDRQzckA=.3901c22a-ffc3-4a4b-9c93-059565a42682@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Hi Alexey, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1876673066


From mbaesken at openjdk.org  Thu Jan  4 08:09:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Jan 2024 08:09:34 GMT
Subject: Integrated: JDK-8322782: Clean up usages of unnecessary fully
 qualified class name "java.util.Arrays"
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <3omokFt2Z2o6tspIqc14e1qKWtD9FygYKsoXsHjHnI0=.f649ef22-6972-4008-8df0-f5e0dec1038a@github.com>

On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

This pull request has now been integrated.

Changeset: 1369c545
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1369c545ac51d7b5ff623d486e28c939869fecb8
Stats:     29 lines in 9 files changed: 0 ins; 0 del; 29 mod

8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays"

Reviewed-by: alanb, aivanov

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

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


From mdonovan at openjdk.org  Thu Jan  4 14:02:22 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 4 Jan 2024 14:02:22 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
Message-ID: <wJTirRYK3msVYC_KJpfmF5RbkTUcdE8jtLnjB9a4n5Y=.bc1ae8b9-cf8f-4409-b811-554a4feeee7a@github.com>

On Wed, 3 Jan 2024 20:41:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
> 
> Several adjustments to the test:
> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.

src/java.base/share/classes/javax/crypto/KEM.java line 545:

> 543:         List<Provider.Service> allowed = new ArrayList<>();
> 544:         for (Provider.Service s : list) {
> 545:             if (!JceSecurity.canUseProvider(s.getProvider())) {

Is there a test that verifies a provider won't be used if it's not signed?

Should there also be a test that verifies that a provider signed with an unknown key is rejected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17253#discussion_r1441779736


From weijun at openjdk.org  Thu Jan  4 14:19:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 Jan 2024 14:19:23 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <wJTirRYK3msVYC_KJpfmF5RbkTUcdE8jtLnjB9a4n5Y=.bc1ae8b9-cf8f-4409-b811-554a4feeee7a@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
 <wJTirRYK3msVYC_KJpfmF5RbkTUcdE8jtLnjB9a4n5Y=.bc1ae8b9-cf8f-4409-b811-554a4feeee7a@github.com>
Message-ID: <elZzC5Wcgnt6vz-fKEjfwKhIk_owdPL4kkTEf_lm0x4=.26f59298-bea7-402d-85b2-34f87f97a45c@github.com>

On Thu, 4 Jan 2024 13:59:38 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
>> 
>> Several adjustments to the test:
>> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
>> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.
>
> src/java.base/share/classes/javax/crypto/KEM.java line 545:
> 
>> 543:         List<Provider.Service> allowed = new ArrayList<>();
>> 544:         for (Provider.Service s : list) {
>> 545:             if (!JceSecurity.canUseProvider(s.getProvider())) {
> 
> Is there a test that verifies a provider won't be used if it's not signed?
> 
> Should there also be a test that verifies that a provider signed with an unknown key is rejected?

Thanks, I'll think about it. That said, OpenJDK builds usually do not perform this check so such tests will not be added in this repository.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17253#discussion_r1441797410


From mdonovan at openjdk.org  Thu Jan  4 15:21:39 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 4 Jan 2024 15:21:39 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v6]
In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
Message-ID: <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>

> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.

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

 - added additional class to @build tag
 - Merge branch 'master' into pkcs11-ol79
 - Merge branch 'master' into pkcs11-ol79
 - added isOracleLinux7() to IGNORED method group in TestMutuallyExclusivePlatformPredicates
 - moved isOracleLinux7() method to Platform class
 - simplified logic for determining OL 7
 - Merge branch 'master' into pkcs11-ol79
 - cleaned up MultipleLogins.java a little and added copyright date
 - Merge branch 'master' into pkcs11-ol79
 - Merge branch 'master' into pkcs11-ol79
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1ddab72a...eaaabc25

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16547/files
  - new: https://git.openjdk.org/jdk/pull/16547/files/8f3f41a7..eaaabc25

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

  Stats: 6834 lines in 498 files changed: 4261 ins; 948 del; 1625 mod
  Patch: https://git.openjdk.org/jdk/pull/16547.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16547/head:pull/16547

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


From weijun at openjdk.org  Thu Jan  4 16:59:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 Jan 2024 16:59:24 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
Message-ID: <_9uUrJ2VVhS3c-iSiFTxQ40zORA0QSHCabZfsZ-oAA4=.813cf332-31b6-4cf1-bf8d-ee7460cdb2d0@github.com>

On Thu, 4 Jan 2024 02:24:56 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add KeychainStore-ROOT keystore for root certificates

What are the change for existing `addCertificatesToKeystore` for? Is there any behavior change?

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1877444731


From abakhtin at openjdk.org  Thu Jan  4 17:17:28 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 4 Jan 2024 17:17:28 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <_9uUrJ2VVhS3c-iSiFTxQ40zORA0QSHCabZfsZ-oAA4=.813cf332-31b6-4cf1-bf8d-ee7460cdb2d0@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
 <_9uUrJ2VVhS3c-iSiFTxQ40zORA0QSHCabZfsZ-oAA4=.813cf332-31b6-4cf1-bf8d-ee7460cdb2d0@github.com>
Message-ID: <o9COMRXoME8Uzzvfu1nVbcF7lxPrP5Rxcm9iFDbzDBg=.cae10151-f3f1-43d5-98c9-4fb8b63fd0f3@github.com>

On Thu, 4 Jan 2024 16:56:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> What are the change for existing `addCertificatesToKeystore` for? Is there any behavior change?

Hi @wangweij . No behavior changes. Just reformatted to make it similar to addCertificatesToKeystoreRoot. Can be reverted back.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1877474131


From mullan at openjdk.org  Thu Jan  4 20:36:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 Jan 2024 20:36:23 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
Message-ID: <9CnXErgTLxSM8sdskubf0ERVYQZFn_LoUQsA2Tv3_Co=.6f14bb65-1f94-4ae6-89c8-c1c01cd18deb@github.com>

On Wed, 3 Jan 2024 20:39:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java line 306:

> 304:         PKCS9Attribute value;
> 305: 
> 306:         boolean first = true;

While you are changing this method, add an `@Override` annotation to `toString`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442228002


From mullan at openjdk.org  Thu Jan  4 20:55:27 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 Jan 2024 20:55:27 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
Message-ID: <NgUiKLgitCxcVGwFUPHi86ZnCHtydFciy42qW12Y0S0=.8df2bff1-5878-444d-b85a-ae075d398090@github.com>

On Wed, 3 Jan 2024 20:39:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 214:

> 212:     private record AttributeInfo(byte[] valueTags, Class<?> valueClass, boolean singleValued) {}
> 213: 
> 214:     private static final Map<ObjectIdentifier,AttributeInfo> oidMap = new HashMap<>();

Nit: add a space after ','.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 218:

> 216:     private static void add(ObjectIdentifier oid, boolean singleValued,
> 217:                             Class<?> valueClass, byte... valueTags) {
> 218:         AttributeInfo info = new AttributeInfo(valueTags,valueClass,singleValued);

Nit: add a space after ','.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 220:

> 218:         AttributeInfo info = new AttributeInfo(valueTags,valueClass,singleValued);
> 219:         if (oidMap.put(oid, info) != null) {
> 220:             throw new RuntimeException("Duplication oid: " + oid);

s/Duplication/Duplicate/

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 253:

> 251: 
> 252:             add(CHALLENGE_PASSWORD_OID, true,
> 253:                 Class.forName("java.lang.String"),

`String.class`

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 258:

> 256:                     DerValue.tag_BMPString,
> 257:                     DerValue.tag_UniversalString,
> 258:                     DerValue.tag_UTF8String);

Nit, too much indentation, line up with previous param.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 281:

> 279:                 DerValue.tag_Sequence);
> 280: 
> 281:         } catch (ClassNotFoundException e) {

Probably can remove this try/catch block if you make above changes to not call `Class.forName`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442236016
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442236248
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442237626
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442242028
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442241373
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442242646


From mullan at openjdk.org  Thu Jan  4 21:17:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 Jan 2024 21:17:26 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
Message-ID: <p-ZvHMWkd0WoysZpjKD5WqOl5qDK1lQfer1KyLV8aAM=.cee82871-86b3-4f26-80b1-c774ea0abaff@github.com>

On Wed, 3 Jan 2024 20:39:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

There are some existing regression tests in the `test/jdk/sun/security/pkcs/pkcs9` directory. I would look through those to see if it would be useful to add more test cases to make sure the code is being adequately tested.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 321:

> 319: 
> 320:         this.oid = oid;
> 321:         info = oidMap.get(oid);

Nit: Change to `this.info` to be consistent with other fields.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 321:

> 319: 
> 320:         this.oid = oid;
> 321:         info = oidMap.get(oid);

What if `info` is `null` (there is no entry for the specified OID)? The prior code set the value class to `byte[]` in that case. I think we want to preserve that behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/17132#issuecomment-1877768541
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442246539
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1442250877


From rgiulietti at openjdk.org  Mon Jan  8 13:48:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 Jan 2024 13:48:06 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti 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 15 additional commits since the last revision:

 - Merge branch 'master' into 8275338
 - Simplified event messages.
   Remove ckecker allocation.
 - Corrected @Label of event and of field.
 - Removed @module from test.
 - Merge branch 'master' into 8275338
 - Renamed an event field.
 - Minor changes.
 - Removed event kind.
   serialVersionUID must have type long.
   Test now base on keyword search in event message.
   Commented test classes about misdeclarations.
 - Changes according to reviewer's comments.
 - Better name for a label, corrected name of removed field.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/3fae3b44...9ca1f36d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/91523c67..9ca1f36d

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

  Stats: 6465 lines in 501 files changed: 3228 ins; 1677 del; 1560 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

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


From fferrari at openjdk.org  Mon Jan  8 18:59:54 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 8 Jan 2024 18:59:54 GMT
Subject: RFR: 8319332: Security properties files inclusion [v5]
In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
Message-ID: <QhHCuxOWJ7sZSTGiamjVRv1CBE3IESgc049oZ9Kt-uc=.aa4a1f16-0654-4eb3-83be-9fdeb72fc68f@github.com>

> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
> 
> ## Security properties loading (overview)
> 
> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
> 
> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
> 
> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
> 
> ## Loading security properties from paths (`loadFromPath` method)
> 
> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
> 
> ## Loading security properties from URLs (`loadFromUrl` method)
> 
> The extra properties file can be loaded from a URL. ...

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

 - Merge 'openjdk/master' into JDK-8319332
 - 8319332: Fix corner-case regression with bash pipe
   
   Extra properties files provided through bash pipes used to work before
   this enhancement, restore their behaviour.
   
   Also take advantage to use Files::isRegularFile, Files::isDirectory and
   Files::exists APIs instead of converting from Path to File.
   
   Linux reproducers (sub-shell, stdin, and combination of both):
   
   java -XshowSettings:security:properties                      \
        -Djava.security.properties==<(echo name=value)          \
        -Djava.security.debug=properties -version
   
   echo name=value | java -XshowSettings:security:properties    \
        -Djava.security.properties==/dev/stdin                  \
        -Djava.security.debug=properties -version
   
   echo name=value | java -XshowSettings:security:properties    \
        -Djava.security.properties==<(echo include /dev/stdin)  \
        -Djava.security.debug=properties -version
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Remove wildcard imports, adjust test case
   
   Test case adjustments: add missing check in PropsFile::assertApplied(),
   and fix typo in FilesManager::handleRequest() method name.
   
   Also, add clarifying comments to Executor::assertSuccess() explaining
   how we use the special properties to make the assertion. Make 'lastFile'
   assignation latter, so it's separated from the first group of asserts.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: use Path::of(URI) to deal with file URLs
   
   Instead of the previously introduced FileURLConnection::getFile(), use
   Path::of(URI), leaving some file URL corner-cases without relative
   imports support.
   
   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Implement security properties 'include'
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Refactor security properties file test
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Refactor properties file loading code
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16483/files
  - new: https://git.openjdk.org/jdk/pull/16483/files/90df17c2..40afe1f4

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

  Stats: 809876 lines in 4524 files changed: 189789 ins; 541418 del; 78669 mod
  Patch: https://git.openjdk.org/jdk/pull/16483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483

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


From fferrari at openjdk.org  Mon Jan  8 19:08:28 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 8 Jan 2024 19:08:28 GMT
Subject: RFR: 8319332: Security properties files inclusion [v5]
In-Reply-To: <QhHCuxOWJ7sZSTGiamjVRv1CBE3IESgc049oZ9Kt-uc=.aa4a1f16-0654-4eb3-83be-9fdeb72fc68f@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <QhHCuxOWJ7sZSTGiamjVRv1CBE3IESgc049oZ9Kt-uc=.aa4a1f16-0654-4eb3-83be-9fdeb72fc68f@github.com>
Message-ID: <ct73IInjFTWNY9ZudIhARZDTQlMGOtiF1GoflJDdGM0=.19e85d1c-da20-493f-94cc-6d29de254345@github.com>

On Mon, 8 Jan 2024 18:59:54 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
>> 
>> ## Security properties loading (overview)
>> 
>> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
>> 
>> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
>> 
>> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
>> 
>> ## Loading security properties from paths (`loadFromPath` method)
>> 
>> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
>> 
>> ## Loading security properties from URLs (`loadFromUrl` method)
>> 
>> The extra properti...
>
> Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge 'openjdk/master' into JDK-8319332
>  - 8319332: Fix corner-case regression with bash pipe
>    
>    Extra properties files provided through bash pipes used to work before
>    this enhancement, restore their behaviour.
>    
>    Also take advantage to use Files::isRegularFile, Files::isDirectory and
>    Files::exists APIs instead of converting from Path to File.
>    
>    Linux reproducers (sub-shell, stdin, and combination of both):
>    
>    java -XshowSettings:security:properties                      \
>         -Djava.security.properties==<(echo name=value)          \
>         -Djava.security.debug=properties -version
>    
>    echo name=value | java -XshowSettings:security:properties    \
>         -Djava.security.properties==/dev/stdin                  \
>         -Djava.security.debug=properties -version
>    
>    echo name=value | java -XshowSettings:security:properties    \
>         -Djava.security.properties==<(echo include /dev/stdin)  \
>         -Djava.security.debug=properties -version
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: Remove wildcard imports, adjust test case
>    
>    Test case adjustments: add missing check in PropsFile::assertApplied(),
>    and fix typo in FilesManager::handleRequest() method name.
>    
>    Also, add clarifying comments to Executor::assertSuccess() explaining
>    how we use the special properties to make the assertion. Make 'lastFile'
>    assignation latter, so it's separated from the first group of asserts.
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: use Path::of(URI) to deal with file URLs
>    
>    Instead of the previously introduced FileURLConnection::getFile(), use
>    Path::of(URI), leaving some file URL corner-cases without relative
>    imports support.
>    
>    Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: Implement security properties 'include'
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Fr...

Merged `master` to keep up to date.

Just in case it got unnoticed, in the previous commit (90df17c2781a47920dbeaa981888ddff65bfe8ad) we fixed a corner-case regression with Bash pipes.

Bash reproducer with _sub-shell_ (this works in `master` and had broken in our branch):


java -XshowSettings:security:properties                      \
     -Djava.security.properties==<(echo name=value)          \
     -Djava.security.debug=properties -version


Bash reproducer with _stdin_ (this works in `master` and had broken in our branch):


echo name=value | java -XshowSettings:security:properties    \
     -Djava.security.properties==/dev/stdin                  \
     -Djava.security.debug=properties -version


Bash reproducer with combination of _sub-shell_ and _stdin_ (this only makes sense in our branch):


echo name=value | java -XshowSettings:security:properties    \
     -Djava.security.properties==<(echo include /dev/stdin)  \
     -Djava.security.debug=properties -version

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1881663782


From mullan at openjdk.org  Mon Jan  8 19:30:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 Jan 2024 19:30:26 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
Message-ID: <oTv9qouuHvKeuiUHylI05I8E7cB7BeDLEdbanGpzJ6g=.4f8cf572-3525-4932-8532-e266e175e5ca@github.com>

On Wed, 3 Jan 2024 20:41:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
> 
> Several adjustments to the test:
> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.

test/jdk/javax/crypto/KEM/RSA_KEM.java line 128:

> 126:     // To bypass the JCE security provider signature check
> 127:     private static KEM getKemImpl(Provider p) throws Exception {
> 128:         var ctor = KEM.class.getDeclaredConstructor(

How about creating it this way only if `java.runtime.name` system property does not contain "OpenJDK"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17253#discussion_r1445230838


From rriggs at openjdk.org  Mon Jan  8 19:58:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Jan 2024 19:58:34 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
Message-ID: <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>

On Mon, 8 Jan 2024 13:48:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8275338
>  - Simplified event messages.
>    Remove ckecker allocation.
>  - Corrected @Label of event and of field.
>  - Removed @module from test.
>  - Merge branch 'master' into 8275338
>  - Renamed an event field.
>  - Minor changes.
>  - Removed event kind.
>    serialVersionUID must have type long.
>    Test now base on keyword search in event message.
>    Commented test classes about misdeclarations.
>  - Changes according to reviewer's comments.
>  - Better name for a label, corrected name of removed field.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8d57faa7...9ca1f36d

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 53:

> 51:     private static final Class<?>[] READ_OBJECT_NO_DATA_PARAM_TYPES = {};
> 52:     private static final Class<?>[] WRITE_REPLACE_PARAM_TYPES = {};
> 53:     private static final Class<?>[] READ_RESOLVE_PARAM_TYPES = {};

These could share a single zero length Class<?> array.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 70:

> 68:             privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
> 69:                     WRITE_REPLACE_PARAM_TYPES, Object.class);
> 70:             privilegedCheckAccessibleMethod(cl, READ_RESOLVE_NAME,

Thinking ahead to when the security manager is removed, can the code that needs private access to field values (SUID) be more narrowly accessed? Perhaps switch to using a VarHandle and MethodHandles.Lookup. This may be a longer term issue and beyond the scope of this PR.

In the naming of the `PrivilegedXXX` methods, I would drop the "privileged" part of the name.
The methods do not change the privilege level and operate correctly if when the caller has the privileges needed. And all of these methods are read-only so there is no/little risk in their implementations and avoid refitting the terminology later.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 87:

> 85:         }
> 86:         if (cl.isEnum()) {
> 87:             commitEvent(cl, SUID_NAME + " in an enum class is not effective");

Is there a best practice that can be included in the message? "SUID should not be declared"?

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:

> 111:         } else if (cl.isEnum()) {
> 112:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME +
> 113:                     " in an enum class is not effective");

Is there best practice to include in the message? "SPFN should not be declared"?

test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 33:

> 31: import org.junit.jupiter.params.provider.MethodSource;
> 32: 
> 33: import java.io.*;

Explicit imports are preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445102883
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445129715
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445107271
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445108891
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445137904


From weijun at openjdk.org  Mon Jan  8 20:57:21 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 Jan 2024 20:57:21 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <oTv9qouuHvKeuiUHylI05I8E7cB7BeDLEdbanGpzJ6g=.4f8cf572-3525-4932-8532-e266e175e5ca@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
 <oTv9qouuHvKeuiUHylI05I8E7cB7BeDLEdbanGpzJ6g=.4f8cf572-3525-4932-8532-e266e175e5ca@github.com>
Message-ID: <wlak0Cwsqx1ntThS1YuhVVBfgm1F5J-hljS78m1Fgfg=.88e95c84-763b-4b04-ba6c-780427c0917a@github.com>

On Mon, 8 Jan 2024 19:26:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
>> 
>> Several adjustments to the test:
>> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
>> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.
>
> test/jdk/javax/crypto/KEM/RSA_KEM.java line 128:
> 
>> 126:     // To bypass the JCE security provider signature check
>> 127:     private static KEM getKemImpl(Provider p) throws Exception {
>> 128:         var ctor = KEM.class.getDeclaredConstructor(
> 
> How about creating it this way only if `java.runtime.name` system property does not contain "OpenJDK"?

I am not sure if other OpenJDK vendors always include the "OpenJDK" name. Or, can call `getInstance()` and then fallback to this way if there is an exception?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17253#discussion_r1445320195


From mullan at openjdk.org  Mon Jan  8 21:36:24 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 Jan 2024 21:36:24 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <wlak0Cwsqx1ntThS1YuhVVBfgm1F5J-hljS78m1Fgfg=.88e95c84-763b-4b04-ba6c-780427c0917a@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
 <oTv9qouuHvKeuiUHylI05I8E7cB7BeDLEdbanGpzJ6g=.4f8cf572-3525-4932-8532-e266e175e5ca@github.com>
 <wlak0Cwsqx1ntThS1YuhVVBfgm1F5J-hljS78m1Fgfg=.88e95c84-763b-4b04-ba6c-780427c0917a@github.com>
Message-ID: <rs45o1HwRTx3Eb4KGKeIDACxR1KhS-mJdNPmDs0ep84=.49dac824-166f-4db3-bdce-8e07b26de433@github.com>

On Mon, 8 Jan 2024 20:54:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/javax/crypto/KEM/RSA_KEM.java line 128:
>> 
>>> 126:     // To bypass the JCE security provider signature check
>>> 127:     private static KEM getKemImpl(Provider p) throws Exception {
>>> 128:         var ctor = KEM.class.getDeclaredConstructor(
>> 
>> How about creating it this way only if `java.runtime.name` system property does not contain "OpenJDK"?
>
> I am not sure if other OpenJDK vendors always include the "OpenJDK" name. Or, can call `getInstance()` and then fallback to this way if there is an exception?

True, although in that case the worse that would happen is that they use reflection instead of calling `KEM.getInstance`. Actually I am ok with this code now - as long as we have other tests that test `KEM.getInstance`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17253#discussion_r1445365329


From rgiulietti at openjdk.org  Tue Jan  9 10:45:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 9 Jan 2024 10:45:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
Message-ID: <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>

On Mon, 8 Jan 2024 18:15:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8275338
>>  - Simplified event messages.
>>    Remove ckecker allocation.
>>  - Corrected @Label of event and of field.
>>  - Removed @module from test.
>>  - Merge branch 'master' into 8275338
>>  - Renamed an event field.
>>  - Minor changes.
>>  - Removed event kind.
>>    serialVersionUID must have type long.
>>    Test now base on keyword search in event message.
>>    Commented test classes about misdeclarations.
>>  - Changes according to reviewer's comments.
>>  - Better name for a label, corrected name of removed field.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/966dac39...9ca1f36d
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 53:
> 
>> 51:     private static final Class<?>[] READ_OBJECT_NO_DATA_PARAM_TYPES = {};
>> 52:     private static final Class<?>[] WRITE_REPLACE_PARAM_TYPES = {};
>> 53:     private static final Class<?>[] READ_RESOLVE_PARAM_TYPES = {};
> 
> These could share a single zero length Class<?> array.

Conceptually, these are independent types. There's no logical relationship between them. Sharing a zero length array would convey a false sense of logical sharing.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 87:
> 
>> 85:         }
>> 86:         if (cl.isEnum()) {
>> 87:             commitEvent(cl, SUID_NAME + " in an enum class is not effective");
> 
> Is there a best practice that can be included in the message? "SUID should not be declared"?

Yes, that's perhaps clearer, will do.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:
> 
>> 111:         } else if (cl.isEnum()) {
>> 112:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME +
>> 113:                     " in an enum class is not effective");
> 
> Is there best practice to include in the message? "SPFN should not be declared"?

Yes, that's perhaps clearer, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445922807
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445924385
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445924424


From rgiulietti at openjdk.org  Tue Jan  9 10:50:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 9 Jan 2024 10:50:31 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
Message-ID: <cQ1yj8jICgoS6Sl7hq-s3L3wKA5ZK9dUmMldo69JbKA=.e325aa0f-75e4-4811-863d-860a85a9bb3a@github.com>

On Mon, 8 Jan 2024 18:38:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8275338
>>  - Simplified event messages.
>>    Remove ckecker allocation.
>>  - Corrected @Label of event and of field.
>>  - Removed @module from test.
>>  - Merge branch 'master' into 8275338
>>  - Renamed an event field.
>>  - Minor changes.
>>  - Removed event kind.
>>    serialVersionUID must have type long.
>>    Test now base on keyword search in event message.
>>    Commented test classes about misdeclarations.
>>  - Changes according to reviewer's comments.
>>  - Better name for a label, corrected name of removed field.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/09cef802...9ca1f36d
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 70:
> 
>> 68:             privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
>> 69:                     WRITE_REPLACE_PARAM_TYPES, Object.class);
>> 70:             privilegedCheckAccessibleMethod(cl, READ_RESOLVE_NAME,
> 
> Thinking ahead to when the security manager is removed, can the code that needs private access to field values (SUID) be more narrowly accessed? Perhaps switch to using a VarHandle and MethodHandles.Lookup. This may be a longer term issue and beyond the scope of this PR.
> 
> In the naming of the `PrivilegedXXX` methods, I would drop the "privileged" part of the name.
> The methods do not change the privilege level and operate correctly if when the caller has the privileges needed. And all of these methods are read-only so there is no/little risk in their implementations and avoid refitting the terminology later.

They are called `privilegedXXX` because they _are_ (already) privileged, not because they change the privileges.

But yes, in view of removing the security manager, the implementation could be more "modern". Will have a look.

> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 33:
> 
>> 31: import org.junit.jupiter.params.provider.MethodSource;
>> 32: 
>> 33: import java.io.*;
> 
> Explicit imports are preferred.

Oops, this is the (overridable) IDE default choice

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445928358
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445930028


From rgiulietti at openjdk.org  Tue Jan  9 16:05:30 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 9 Jan 2024 16:05:30 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v10]
In-Reply-To: <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
Message-ID: <uykTLI6Tdxl4dU2bAxwgdqmAWI59Wik-o_kQigvFWO0=.b6a08dd6-e773-4b36-8c0b-53664d98646f@github.com>

On Tue, 2 Jan 2024 14:37:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/adcabea9...252b7378

src/java.base/share/classes/java/math/BigInteger.java line 3998:

> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
> 3997:         if (i != -1)
> 3998:             return ((m1[i] & LONG_MASK) < (m2[i] & LONG_MASK)) ? -1 : 1;

As suggested earlier, you could make us of `Integer.compareUnsigned`, which is an intrinsic not involving `long`s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1446287937


From rriggs at openjdk.org  Tue Jan  9 17:09:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 17:09:33 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v10]
In-Reply-To: <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
Message-ID: <xruV0TY5jhnLxqv9f_yhQYx8xbSN4sltlE6WvIOOGVs=.2d62efc4-a9ec-42a8-97f0-96a6bef1e938@github.com>

On Tue, 2 Jan 2024 14:37:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/c09491be...252b7378

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14630#pullrequestreview-1811620453


From dfuchs at openjdk.org  Tue Jan  9 18:35:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Jan 2024 18:35:26 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
Message-ID: <HECLeGNZfOMdoMkYhCtvkfLLvyX2CbR9jRMASwL23fE=.3780d393-9077-4be4-9c02-f9f78a254be0@github.com>

On Tue, 9 Jan 2024 10:42:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 87:
>> 
>>> 85:         }
>>> 86:         if (cl.isEnum()) {
>>> 87:             commitEvent(cl, SUID_NAME + " in an enum class is not effective");
>> 
>> Is there a best practice that can be included in the message? "SUID should not be declared"?
>
> Yes, that's perhaps clearer, will do.

Typically in other places in the JDK we use `priviledgedXxx` for naming methods that are simple wrappers that call `xxx` from within a `doPrivileged`. The method is called privileged because it doesn't require the caller to use `doPrivileged`.

That is something like:


String privilegedGetProperty(String property) {
     return AccessController.doPrivileged((...) () -> System.getProperty(property));
} 


See for instance: https://github.com/openjdk/jdk/blob/ee98d262181f5822609674c71c85ad4576ac1632/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L107

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1446460008


From mullan at openjdk.org  Tue Jan  9 20:16:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 9 Jan 2024 20:16:22 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
Message-ID: <H0UcjXSSa0cTR_pVFnfz3OpOYC2XrQEUbAnJoYB9WSw=.dd45bdfe-2adc-4663-afa3-01bd4fe65cf3@github.com>

On Wed, 3 Jan 2024 20:41:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
> 
> Several adjustments to the test:
> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17253#pullrequestreview-1811911748


From duke at openjdk.org  Tue Jan  9 21:12:48 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 9 Jan 2024 21:12:48 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v3]
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <2xlUrhw42cy8_UcZNgKYy5WMm0kupZaztNScq8TJe9w=.4c7421f7-f6be-471b-8cb9-5ced9023de65@github.com>

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

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

 - reverted zipfs changes and made adjustements for ZipInputStream comments
 - Merge branch 'master' into zip-doc-changes
 - Fixed more line breaks
 - fixed line breaks
 - document patch for JDK-8319122

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16424/files
  - new: https://git.openjdk.org/jdk/pull/16424/files/919666a0..dbecd485

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

  Stats: 831197 lines in 4897 files changed: 202043 ins; 545027 del; 84127 mod
  Patch: https://git.openjdk.org/jdk/pull/16424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16424/head:pull/16424

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


From duke at openjdk.org  Tue Jan  9 21:12:50 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 9 Jan 2024 21:12:50 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <DXJR3I2x9PeojuQ3QYQE-pZguDRQlCrg_eLvQaJIJwA=.a3ae7ebc-47c5-4e73-9dd6-6b07448b0832@github.com>
 <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com>
Message-ID: <biV5cpLE900w7Hw70FAFlG82CLTQ2PiiDsAGbp-rhuM=.3ab7e567-c3bb-4137-8f94-d61ee8bece7d@github.com>

On Wed, 22 Nov 2023 22:23:18 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 77:
>> 
>>> 75:  *
>>> 76:  * Whenever possible, {@linkplain ZipFile} should be used for parsing ZIP
>>> 77:  * archives since it correctly reads data from the central directory.
>> 
>> I think it's okay to extend the existing API note to say that the stream may contain ZIP file entries that are not are not named in the central directory.  I think I would replace the sentence "Additionally ..." with "Consequently, a ZipInputStream that reads from a ZIP file may read ZIP file entries that are not in the ZIP file's central directory". 
>> 
>> The sentence "This class might also fail to properly parse ZIP archives that have prepended data" will confuse readers as it hints of unreliability in scenarios and begs too many questions on where the data is prepended. So I think drop this unless you can come up with something better.
>> 
>> Replacing the sentence "ZipFile may be used ..." is okay but I don't think the proposed text works. The API note starts with text to say that a ZipInputStream doesn't read the CEN so saying "correctly reads from the central directory" is very confusing. ZipInputStream is a JDK 1.1 era API, it is what it is and would be disruptive to deprecate.
>
> Thank you, I will work on this

I updated the file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1446615096


From duke at openjdk.org  Tue Jan  9 21:12:51 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 9 Jan 2024 21:12:51 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com>
 <xRCA93VnAm2A587CHpU0tndPVAccgRHcSFeA_7XUmYg=.b4742d67-73f1-4cc3-91dd-48bbfbbbb64c@github.com>
 <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com>
Message-ID: <EBglJjKFK34CLUeT7ZTdrcME0LV7hQpH-ChXmN_JZ9M=.71598f29-84c9-42ee-bb18-17783cae7067@github.com>

On Mon, 13 Nov 2023 18:11:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking?
>
>> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking?
> 
> Yes, I think it should be separated, and it would be nice to drop the changes to jdk.zipfs from this PR. If/when this documentation is written then it describe the "/" character and the synthesized links that are "." and "..", which can lead to documentation that a zip file with name elements of  "." or ".." cannot be opened as a file system.

Removed from this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1446615201


From valeriep at openjdk.org  Tue Jan  9 23:46:23 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 9 Jan 2024 23:46:23 GMT
Subject: RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
Message-ID: <32azkOqGOL2yU9fKH-syI2LRMm2n6vkIgnQuZ4vb8HU=.0514137a-22d3-4db5-82d6-b8a54c8a8dba@github.com>

On Wed, 3 Jan 2024 20:41:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
> 
> Several adjustments to the test:
> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.

Looks good.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17253#pullrequestreview-1812191658


From valeriep at openjdk.org  Wed Jan 10 02:21:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 Jan 2024 02:21:24 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <NgUiKLgitCxcVGwFUPHi86ZnCHtydFciy42qW12Y0S0=.8df2bff1-5878-444d-b85a-ae075d398090@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
 <NgUiKLgitCxcVGwFUPHi86ZnCHtydFciy42qW12Y0S0=.8df2bff1-5878-444d-b85a-ae075d398090@github.com>
Message-ID: <Zocnspudks5dPP4G3hkjJfNUylZ3-0S71V44WKQUIPg=.042aa612-e2f8-4c63-b034-d0debccc3ff2@github.com>

On Thu, 4 Jan 2024 20:44:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 218:
> 
>> 216:     private static void add(ObjectIdentifier oid, boolean singleValued,
>> 217:                             Class<?> valueClass, byte... valueTags) {
>> 218:         AttributeInfo info = new AttributeInfo(valueTags,valueClass,singleValued);
> 
> Nit: add a space after ','.

nit: match the ordering of arguments here w/ the one used in record?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1446811223


From valeriep at openjdk.org  Wed Jan 10 02:29:22 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 Jan 2024 02:29:22 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
Message-ID: <3PH_75L_nvL0ZU6BaqBxpEfDlB-3vfzvX3pS3_tfrng=.d81b7c88-b944-4542-b4bb-260b4ef1f374@github.com>

On Thu, 21 Dec 2023 16:46:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 241:
> 
>> 239:     static {
>> 240:         try {
>> 241:             Class<?> str = Class.forName("[Ljava.lang.String;");
> 
> `String[].class`. In fact I wonder if it's worth define a variable for this. Just use the literal directly everywhere.

+1 for using literal directly everywhere...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1446814658


From valeriep at openjdk.org  Wed Jan 10 02:35:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 Jan 2024 02:35:24 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
Message-ID: <OPCyiXfekyMb84g2-6Hj7ulDlj-KXz-C9tjYqJSq7gY=.8e286c7a-91ff-4f7e-b2a8-fe47cd109191@github.com>

On Wed, 3 Jan 2024 20:39:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 214:

> 212:     private record AttributeInfo(byte[] valueTags, Class<?> valueClass, boolean singleValued) {}
> 213: 
> 214:     private static final Map<ObjectIdentifier,AttributeInfo> oidMap = new HashMap<>();

nit: infoMap seems to be a more appropriate name than oidMap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1446817448


From valeriep at openjdk.org  Wed Jan 10 02:50:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 Jan 2024 02:50:24 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
Message-ID: <fv_4U5HLLN2FSCPd29s21wrOjT51v9ZzicyxfiAU5w4=.14c14db7-dd29-4f52-82dc-32ab9b7f9c47@github.com>

On Wed, 3 Jan 2024 20:39:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 292:

> 290: 
> 291:     /**
> 292:      * The AttributeInfo of this attribute

nit: add "can be null if oid is unknown"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1446824478


From valeriep at openjdk.org  Wed Jan 10 02:56:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 Jan 2024 02:56:24 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <p-ZvHMWkd0WoysZpjKD5WqOl5qDK1lQfer1KyLV8aAM=.cee82871-86b3-4f26-80b1-c774ea0abaff@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
 <p-ZvHMWkd0WoysZpjKD5WqOl5qDK1lQfer1KyLV8aAM=.cee82871-86b3-4f26-80b1-c774ea0abaff@github.com>
Message-ID: <q7_q6e6mUbgH72cP8cJlaVpWpcUO7IOxe84jb-LSw1c=.5bc23163-479a-45e7-be0f-bb34a8a877c8@github.com>

On Thu, 4 Jan 2024 21:04:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 321:
> 
>> 319: 
>> 320:         this.oid = oid;
>> 321:         info = oidMap.get(oid);
> 
> What if `info` is `null` (there is no entry for the specified OID)? The prior code set the value class to `byte[]` in that case. I think we want to preserve that behavior.

So, it seems that no test is triggering a NPE? Consider adding a test for covering this scenario?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1446827158


From valeriep at openjdk.org  Wed Jan 10 04:45:23 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 Jan 2024 04:45:23 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
Message-ID: <gIjODzt4bTMFFlgTnN9yH_U0BZs7vnogCPzmC0kMMOA=.f7d30395-052d-4dba-b9c4-c4d56ee6b48e@github.com>

On Wed, 3 Jan 2024 20:39:57 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes to make the code more readable, inlined init(), removed PKCS9Attributes.getAttributes()

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 556:

> 554:             temp.writeBytes((byte[])value);
> 555:             out.write(DerValue.tag_Sequence, temp.toByteArray());
> 556:             return;

For something that should never happen, we should throw exception to indicate the problem if it were to happen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1446876878


From prappo at openjdk.org  Wed Jan 10 11:27:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 10 Jan 2024 11:27:53 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Use Integer.compareUnsigned
 - Update copyright years and headers
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Fix bugs in Shared.createSingle
 - Merge branch 'master' into 8310813
 - Group params coarser (suggested by @cl4es)
   
   - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
     Every testXYZ method invokes M operations, where M is the maximum
     number of elements in a group. Shorter groups are cyclically padded.
   - Uses the org.openjdk.jmh.infra.Blackhole API and increases
     benchmark time.
   - Fixes a bug in Shared that precluded 0 from being in a pair.
 - ... and 10 more: https://git.openjdk.org/jdk/compare/bc05893f...08e6adca

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

Changes: https://git.openjdk.org/jdk/pull/14630/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=10
  Stats: 527 lines in 6 files changed: 500 ins; 16 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

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


From jwaters at openjdk.org  Wed Jan 10 12:16:44 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 10 Jan 2024 12:16:44 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v5]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <JgGNbmtWVACkAkoWYmW7yfFMXXs0g6KSQ_nLDC1taYQ=.5240dab7-af18-46b1-bd15-f3105edadf3c@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

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

 - Merge branch 'openjdk:master' into patch-9
 - Merge branch 'openjdk:master' into patch-9
 - NULL to nullptr in sspi.cpp
 - Missed labels in sspi.cpp
 - Actually resolve issues with goto labels in sspi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/f4108192..12322501

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

  Stats: 83033 lines in 1621 files changed: 47307 ins; 29209 del; 6517 mod
  Patch: https://git.openjdk.org/jdk/pull/16682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16682/head:pull/16682

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


From jwaters at openjdk.org  Wed Jan 10 12:41:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 10 Jan 2024 12:41:48 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v6]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <-Thg2cYMBM0euyALIUo4QQxOgvZY3Ur8Lv0eyBrPj0k=.82d3cf2d-f762-48bf-9280-e4c74fd8b12b@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

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

  Fix most but not all methods in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/12322501..8b4a3005

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

  Stats: 111 lines in 1 file changed: 24 ins; 70 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/16682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16682/head:pull/16682

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


From jwaters at openjdk.org  Wed Jan 10 12:53:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 10 Jan 2024 12:53:48 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v7]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

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

  Fix the remaining case in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/8b4a3005..926bc9aa

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

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

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


From rgiulietti at openjdk.org  Wed Jan 10 13:54:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 13:54:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <HECLeGNZfOMdoMkYhCtvkfLLvyX2CbR9jRMASwL23fE=.3780d393-9077-4be4-9c02-f9f78a254be0@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
 <HECLeGNZfOMdoMkYhCtvkfLLvyX2CbR9jRMASwL23fE=.3780d393-9077-4be4-9c02-f9f78a254be0@github.com>
Message-ID: <4QouJOP9lPBgzMxFuVvxBVmlaGGAu27nQDr2RGfgQHo=.dce3c918-fe2e-4190-9c53-f31cdfbf3088@github.com>

On Tue, 9 Jan 2024 18:31:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yes, that's perhaps clearer, will do.
>
> Typically in other places in the JDK we use `priviledgedXxx` for naming methods that are simple wrappers that call `xxx` from within a `doPrivileged`. The method is called privileged because it doesn't require the caller to use `doPrivileged`.
> 
> That is something like:
> 
> 
> String privilegedGetProperty(String property) {
>      return AccessController.doPrivileged((...) () -> System.getProperty(property));
> } 
> 
> 
> See for instance: https://github.com/openjdk/jdk/blob/ee98d262181f5822609674c71c85ad4576ac1632/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L107

Ah OK, I wasn't aware of this convention.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447413819


From weijun at openjdk.org  Wed Jan 10 14:40:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 10 Jan 2024 14:40:23 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths
In-Reply-To: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
Message-ID: <0XjvDqPnoi6ixDL6AEKM1LpwpYv4ouwUfCS5yDFPw-I=.e4599c77-9000-4794-acc4-ed003c1f6ee2@github.com>

On Wed, 3 Jan 2024 16:55:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
> 
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
> 
> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

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

> 34: import sun.security.provider.certpath.PKIX.BuilderParams;
> 35: import sun.security.util.Debug;
> 36: import sun.security.x509.GeneralNameInterface;

`GeneralNameInterface` is useless now.

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

> 554:      * @return the common ancestor or null if none or an attribute of the
> 555:      *    last RDN of the common ancestor is geographical
> 556:      */

~Is it possible to return the common ancestors of all the 3 names: trusted, issuer1, issuer2?~ Also, it seems there is no need to return a list. Just a number is enough. Actually you care about the difference from the common part, so how about return the distance directly?

Update: ignore the 1st part of this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1447447541
PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1447468296


From rriggs at openjdk.org  Wed Jan 10 14:51:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 14:51:29 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
Message-ID: <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>

On Wed, 10 Jan 2024 11:27:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Use Integer.compareUnsigned
>  - Update copyright years and headers
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/bc05893f...08e6adca

src/java.base/share/classes/java/math/BigInteger.java line 3998:

> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
> 3997:         if (i != -1)
> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;

Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447488470


From rgiulietti at openjdk.org  Wed Jan 10 15:02:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 15:02:31 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
 <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>
Message-ID: <2X3g6YcSJSMN83eYD5682QY7FRs9GUKca3GULrFmQH0=.096e3518-c437-4aa5-8135-0f005bcd10e6@github.com>

On Wed, 10 Jan 2024 14:48:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Use Integer.compareUnsigned
>>  - Update copyright years and headers
>>  - Merge branch 'master' into 8310813
>>  - Merge branch 'master' into 8310813
>>  - Merge branch 'master' into 8310813
>>  - Merge branch 'master' into 8310813
>>  - Merge branch 'master' into 8310813
>>  - Fix bugs in Shared.createSingle
>>  - Merge branch 'master' into 8310813
>>  - Group params coarser (suggested by @cl4es)
>>    
>>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>>      Every testXYZ method invokes M operations, where M is the maximum
>>      number of elements in a group. Shorter groups are cyclically padded.
>>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>>      benchmark time.
>>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/bc05893f...08e6adca
>
> src/java.base/share/classes/java/math/BigInteger.java line 3998:
> 
>> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
>> 3997:         if (i != -1)
>> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;
> 
> Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
> Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.

Yes, that's what was proposed [here](https://github.com/openjdk/jdk/pull/14630#discussion_r1242245875) some time ago.

But the spec of `compareUnsigned()` does _not_ guarantee a -1, 0, 1 result, so there's a (minimal) risk when returning its value directly. (For some reason, `BigInteger` specifies a -1, 0, 1 outcome.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447502797


From rriggs at openjdk.org  Wed Jan 10 15:14:28 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 15:14:28 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <2X3g6YcSJSMN83eYD5682QY7FRs9GUKca3GULrFmQH0=.096e3518-c437-4aa5-8135-0f005bcd10e6@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
 <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>
 <2X3g6YcSJSMN83eYD5682QY7FRs9GUKca3GULrFmQH0=.096e3518-c437-4aa5-8135-0f005bcd10e6@github.com>
Message-ID: <tnjTe18cjdM5lHuXrRxx6nYfb1IFzQaf9cHf1hWLLrk=.7a0006fc-da25-4883-a0a6-07fd2f508da0@github.com>

On Wed, 10 Jan 2024 14:58:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 3998:
>> 
>>> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
>>> 3997:         if (i != -1)
>>> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;
>> 
>> Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
>> Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.
>
> Yes, that's what was proposed [here](https://github.com/openjdk/jdk/pull/14630#discussion_r1242245875) some time ago.
> 
> But the spec of `compareUnsigned()` does _not_ guarantee a -1, 0, 1 result, so there's a (minimal) risk when returning its value directly. (For some reason, `BigInteger` specifies a -1, 0, 1 outcome.)

In expressing intent, perhaps `Integer.signum(Integer.compareUnsigned(m1[i], [m2[i]))`.
Though it may all be for nothing if C2 can optimize it away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447521230


From rgiulietti at openjdk.org  Wed Jan 10 15:43:46 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 15:43:46 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v13]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>

> Adds serialization misdeclaration events to JFR.

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

  Changes according to reviewers feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/9ca1f36d..ff1b7068

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

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

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


From dfuchs at openjdk.org  Wed Jan 10 16:23:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 16:23:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <cQ1yj8jICgoS6Sl7hq-s3L3wKA5ZK9dUmMldo69JbKA=.e325aa0f-75e4-4811-863d-860a85a9bb3a@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <cQ1yj8jICgoS6Sl7hq-s3L3wKA5ZK9dUmMldo69JbKA=.e325aa0f-75e4-4811-863d-860a85a9bb3a@github.com>
Message-ID: <U-9-xTDYmRjeSPvlyLmjUAFT2mYQdQ10JlLOd8sDGS8=.2e1045b9-a248-40b6-bc24-7717f6703605@github.com>

On Tue, 9 Jan 2024 10:46:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 70:
>> 
>>> 68:             privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
>>> 69:                     WRITE_REPLACE_PARAM_TYPES, Object.class);
>>> 70:             privilegedCheckAccessibleMethod(cl, READ_RESOLVE_NAME,
>> 
>> Thinking ahead to when the security manager is removed, can the code that needs private access to field values (SUID) be more narrowly accessed? Perhaps switch to using a VarHandle and MethodHandles.Lookup. This may be a longer term issue and beyond the scope of this PR.
>> 
>> In the naming of the `PrivilegedXXX` methods, I would drop the "privileged" part of the name.
>> The methods do not change the privilege level and operate correctly if when the caller has the privileges needed. And all of these methods are read-only so there is no/little risk in their implementations and avoid refitting the terminology later.
>
> They are called `privilegedXXX` because they _are_ (already) privileged, not because they change the privileges.
> 
> But yes, in view of removing the security manager, the implementation could be more "modern". Will have a look.

> https://github.com/openjdk/jdk/pull/17129/commits/ff1b7068bd902f3030267afbc468e3244c944604

Thanks - that looks much cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447617134


From rriggs at openjdk.org  Wed Jan 10 16:52:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 16:52:26 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
Message-ID: <ESKiK251JihCIWGAGLedvBbGp2ykTAZ_oqZkYB9rUCw=.498c6447-4d80-4269-9a83-662add3e9b9a@github.com>

On Tue, 9 Jan 2024 10:41:31 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 53:
>> 
>>> 51:     private static final Class<?>[] READ_OBJECT_NO_DATA_PARAM_TYPES = {};
>>> 52:     private static final Class<?>[] WRITE_REPLACE_PARAM_TYPES = {};
>>> 53:     private static final Class<?>[] READ_RESOLVE_PARAM_TYPES = {};
>> 
>> These could share a single zero length Class<?> array.
>
> Conceptually, these are independent types. There's no logical relationship between them. Sharing a zero length array would convey a false sense of logical sharing.

true, but its wasted space and IMHO ok as a local and private implementation detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447655018


From kdriver at openjdk.org  Wed Jan 10 17:03:28 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 10 Jan 2024 17:03:28 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths
In-Reply-To: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
Message-ID: <yjT5cRw76GJ-wNseY1rUB4Nlb9brj6mwgFtwOWTrWXw=.847ddf10-57f8-497a-9751-7f6f776b92ab@github.com>

On Wed, 3 Jan 2024 16:55:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
> 
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
> 
> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

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

> 521:                 }
> 522:                 if (tAo1 != null) {
> 523:                     if (tAo2 != null) {

Maybe it's unfamiliarity with this code, but I think we could use some comments here, especially since a similar condition is tested on line 534 (except tAo1 would be null in that case?).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1447668592


From rriggs at openjdk.org  Wed Jan 10 17:05:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 17:05:26 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v13]
In-Reply-To: <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>
Message-ID: <S93z1lsfaUWNRaBy6lHTXhkukX6pi1bhdd27qPIOeoM=.ae3187dd-f702-422c-a103-b212f810d9e6@github.com>

On Wed, 10 Jan 2024 15:43:46 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to reviewers feedback.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 129:

> 127:         Object spf = objectFromStatic(f);
> 128:         if (spf == null) {
> 129:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME + " must be non-null");

"must" -> "should".

The [serialization spec](https://docs.oracle.com/en/java/javase/21/docs/specs/serialization/serial-arch.html#defining-serializable-fields-for-a-class) describes the behavior if the field is null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447662278


From rriggs at openjdk.org  Wed Jan 10 17:05:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 17:05:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
Message-ID: <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>

On Tue, 19 Dec 2023 15:58:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 185:
>> 
>>> 183:             commitEvent(PRIV_METH_NON_STATIC,
>>> 184:                     m + " must be non-static to be effective");
>>> 185:         }
>> 
>> Should there also be a check to see if this `private` method is (misdeclared) as a `native` method?
>
> I'm not sure that a `native` method is not considered effective by serialization. I have to check.

The spec is silent about methods being 'native'; it would generally be impractical to implement native methods for these purposes, but a native method can implement the behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447665831


From rgiulietti at openjdk.org  Wed Jan 10 17:25:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 17:25:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <ESKiK251JihCIWGAGLedvBbGp2ykTAZ_oqZkYB9rUCw=.498c6447-4d80-4269-9a83-662add3e9b9a@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
 <ESKiK251JihCIWGAGLedvBbGp2ykTAZ_oqZkYB9rUCw=.498c6447-4d80-4269-9a83-662add3e9b9a@github.com>
Message-ID: <ZQN6hXiJF2tQ2Bjo3Z7DEFbmlHqp0Y67fnqKozD6EdQ=.4d6780ef-1539-485f-96ba-16ea4ec4947a@github.com>

On Wed, 10 Jan 2024 16:49:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Conceptually, these are independent types. There's no logical relationship between them. Sharing a zero length array would convey a false sense of logical sharing.
>
> true, but its wasted space and IMHO ok as a local and private implementation detail.

I agree that, as a private implementation detail, this can be optimized by sharing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447693340


From rgiulietti at openjdk.org  Wed Jan 10 17:33:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 17:33:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v13]
In-Reply-To: <S93z1lsfaUWNRaBy6lHTXhkukX6pi1bhdd27qPIOeoM=.ae3187dd-f702-422c-a103-b212f810d9e6@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>
 <S93z1lsfaUWNRaBy6lHTXhkukX6pi1bhdd27qPIOeoM=.ae3187dd-f702-422c-a103-b212f810d9e6@github.com>
Message-ID: <AXvTBEAOalIZOy4Kk39NdtAvWrIz7vSBMojjInvMu2E=.20642795-b3a7-428f-b799-c81a3905b7c9@github.com>

On Wed, 10 Jan 2024 16:55:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to reviewers feedback.
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 129:
> 
>> 127:         Object spf = objectFromStatic(f);
>> 128:         if (spf == null) {
>> 129:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME + " must be non-null");
> 
> "must" -> "should".
> 
> The [serialization spec](https://docs.oracle.com/en/java/javase/21/docs/specs/serialization/serial-arch.html#defining-serializable-fields-for-a-class) describes the behavior if the field is null.

Right

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447705388


From rgiulietti at openjdk.org  Wed Jan 10 17:45:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 17:45:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
 <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>
Message-ID: <-_PvRm5zjQX1rUk3bW0CEiKJWChU0-UTcOPUhOyc2qk=.15e65620-889b-49fe-a18e-35dbde1ade39@github.com>

On Wed, 10 Jan 2024 16:58:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'm not sure that a `native` method is not considered effective by serialization. I have to check.
>
> The spec is silent about methods being 'native'; it would generally be impractical to implement native methods for these purposes, but a native method can implement the behavior.

@RogerRiggs The checks are agnostic about a method being `native` or not, so I'm not sure I get your point about `native` methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447721944


From rriggs at openjdk.org  Wed Jan 10 18:44:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 18:44:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <-_PvRm5zjQX1rUk3bW0CEiKJWChU0-UTcOPUhOyc2qk=.15e65620-889b-49fe-a18e-35dbde1ade39@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
 <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>
 <-_PvRm5zjQX1rUk3bW0CEiKJWChU0-UTcOPUhOyc2qk=.15e65620-889b-49fe-a18e-35dbde1ade39@github.com>
Message-ID: <yYu2NIELm2LdfDtuaqRPhoSH55_7Au8GZxePmE2xbuc=.9489a6b0-7740-4ead-a4d7-801fae95f45b@github.com>

On Wed, 10 Jan 2024 17:41:41 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The spec is silent about methods being 'native'; it would generally be impractical to implement native methods for these purposes, but a native method can implement the behavior.
>
> @RogerRiggs The checks are agnostic about a method being `native` or not, so I'm not sure I get your point about `native` methods.

Right, there's nothing to change; a method declared as native is not mis-declared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447785756


From rgiulietti at openjdk.org  Wed Jan 10 18:56:45 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 18:56:45 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v14]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>

> Adds serialization misdeclaration events to JFR.

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

  Small space optimization.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/ff1b7068..b76285d9

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

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

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


From mdonovan at openjdk.org  Wed Jan 10 20:20:50 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 10 Jan 2024 20:20:50 GMT
Subject: RFR: 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails with
 "Alias <246810> does not exist"
Message-ID: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>

I was unable to recreate the error but it looks like the problem could happen if two instances of the test are run on the same machine.  Also, if the deleteEntry() calls in the finally block throw an exception, they can hide any exceptions thrown earlier in the test.

I updated the test to use randomly generated alias names. I also updated the finally block so exceptions thrown by deleteEntry() are logged but not thrown.

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

Commit messages:
 - 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails with "Alias <246810> does not exist"

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

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


From duke at openjdk.org  Thu Jan 11 03:09:35 2024
From: duke at openjdk.org (duke)
Date: Thu, 11 Jan 2024 03:09:35 GMT
Subject: Withdrawn: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <Whzj27D8ZNlGQ96zERlmMzBBO5KJl_OCTHKeMiMDVYo=.d1cfba1e-5c83-401a-b057-d8ce8ed403f3@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

This pull request has been closed without being integrated.

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

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


From ascarpino at openjdk.org  Thu Jan 11 03:31:56 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 11 Jan 2024 03:31:56 GMT
Subject: RFR: JDK-8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4,
 and increase overlap testing
Message-ID: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>

Hi,

I need a review of a few simple test changes.  This fixes a failure with two manually run AES/GCM tests that depended on another test that changed with [JDK-8318756](https://bugs.openjdk.org/browse/JDK-8318756).  It also adds testing for overlapping buffers that AES/GCM has, but CC20P1305 needs after JDK-8318756 was included.

After the change, manual testing of GCMIncrementByte4 and GCMIncrementDirect4 were successfully and automated tests passed as well.

thanks

Tony

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

Commit messages:
 - fix

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

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


From prappo at openjdk.org  Thu Jan 11 10:34:45 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 10:34:45 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v12]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <5_1gzLTndIAda1lyk_zRhWZ2Kk28UL7jOLE3x9mOhf0=.394870e7-ffec-4b81-9944-4b851b98c3d6@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

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

  Revert copyright year change
  
  Those files were first published in 2023 and haven't been changed since.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/08e6adca..31e9eefd

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

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

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


From rgiulietti at openjdk.org  Thu Jan 11 10:39:26 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 11 Jan 2024 10:39:26 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v12]
In-Reply-To: <5_1gzLTndIAda1lyk_zRhWZ2Kk28UL7jOLE3x9mOhf0=.394870e7-ffec-4b81-9944-4b851b98c3d6@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <5_1gzLTndIAda1lyk_zRhWZ2Kk28UL7jOLE3x9mOhf0=.394870e7-ffec-4b81-9944-4b851b98c3d6@github.com>
Message-ID: <2qsP_pwHh9y53rn6bylDc99seoAoYXLtIgxi9P4_cig=.fd922da8-beb2-4bb0-9ee2-7d8134cdb4de@github.com>

On Thu, 11 Jan 2024 10:34:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert copyright year change
>   
>   Those files were first published in 2023 and haven't been changed since.

LGTM

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14630#pullrequestreview-1815217411


From jjiang at openjdk.org  Thu Jan 11 13:41:35 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 11 Jan 2024 13:41:35 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before using
 them
Message-ID: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>

ECDHKeyAgreement should validate the parameters before assigning them to the fields.

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

Commit messages:
 - 8320449: ECDHKeyAgreement should validate parameters before using them

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

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


From weijun at openjdk.org  Thu Jan 11 13:48:37 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 13:48:37 GMT
Subject: Integrated: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
In-Reply-To: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
References: <hL8h0J5grK_uTZEZDTzsAD-ZMy_jpXq_bZXcP320z2k=.1aa72468-609c-426b-85e6-f259c5c73654@github.com>
Message-ID: <utQDDsj1MLdQM5Mo9SK2CpATprau7ap_3FklKYWpBOw=.d6819910-1eb6-41b1-be9f-6084267617c0@github.com>

On Wed, 3 Jan 2024 20:41:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `KEM.getInstance` now checks if the implementation is from a signed provider if it's not builtin to JDK.
> 
> Several adjustments to the test:
> 1. Put one impl in `SunEC` to pretend it's builtin. This is necessary to test for provider selection.
> 2. When there is no need to choose a provider, use reflection to create a `KEM` object that bypasses the `getInstance` call.

This pull request has now been integrated.

Changeset: 9fd855ed
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fd855ed477bb0849ce5c774854844deec0f4c6b
Stats:     119 lines in 4 files changed: 74 ins; 29 del; 16 mod

8322971: KEM.getInstance() should check if a 3rd-party security provider is signed

Reviewed-by: mullan, valeriep

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

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


From mdonovan at openjdk.org  Thu Jan 11 13:53:26 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 11 Jan 2024 13:53:26 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v6]
In-Reply-To: <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
Message-ID: <BN5ssQVpX7tuCfLNaqT7wBp-3xvIPfU5U_RTokRRyII=.ab0af685-cb11-4fd6-83c7-9bc2495224bb@github.com>

On Thu, 4 Jan 2024 15:21:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - added additional class to @build tag
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - added isOracleLinux7() to IGNORED method group in TestMutuallyExclusivePlatformPredicates
>  - moved isOracleLinux7() method to Platform class
>  - simplified logic for determining OL 7
>  - Merge branch 'master' into pkcs11-ol79
>  - cleaned up MultipleLogins.java a little and added copyright date
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/2f8a619d...eaaabc25

Hello, this PR was approved but then I had to make some additional changes so I'd like to have an additional review/approval before merging it.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16547#issuecomment-1887202620


From weijun at openjdk.org  Thu Jan 11 14:01:41 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 14:01:41 GMT
Subject: [jdk22] RFR: 8322971: KEM.getInstance() should check if a 3rd-party
 security provider is signed
Message-ID: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>

8322971: KEM.getInstance() should check if a 3rd-party security provider is signed

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

Commit messages:
 - Backport 9fd855ed477bb0849ce5c774854844deec0f4c6b

Changes: https://git.openjdk.org/jdk22/pull/61/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=61&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322971
  Stats: 119 lines in 4 files changed: 74 ins; 29 del; 16 mod
  Patch: https://git.openjdk.org/jdk22/pull/61.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/61/head:pull/61

PR: https://git.openjdk.org/jdk22/pull/61


From mullan at openjdk.org  Thu Jan 11 14:09:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 14:09:37 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v2]
In-Reply-To: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
Message-ID: <kKX4vgGnv2TOhlDjOrfYcjSCqLONhLEGGy-T-CfDvaQ=.e0d699c4-eedf-49f4-80d2-7500b5eae42a@github.com>

> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
> 
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
> 
> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

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

  Add more comments. Remove unnecessary import.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17248/files
  - new: https://git.openjdk.org/jdk/pull/17248/files/7098b73c..22444c6d

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

  Stats: 59 lines in 2 files changed: 10 ins; 16 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/17248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17248/head:pull/17248

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


From mullan at openjdk.org  Thu Jan 11 14:09:40 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 14:09:40 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v2]
In-Reply-To: <0XjvDqPnoi6ixDL6AEKM1LpwpYv4ouwUfCS5yDFPw-I=.e4599c77-9000-4794-acc4-ed003c1f6ee2@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <0XjvDqPnoi6ixDL6AEKM1LpwpYv4ouwUfCS5yDFPw-I=.e4599c77-9000-4794-acc4-ed003c1f6ee2@github.com>
Message-ID: <d_18Vr_kyi7AyFPe7zaLTqJwmtYNrsZLR_ab7ERlOrU=.e726d3c4-8e22-4767-8031-f98c073be5f8@github.com>

On Wed, 10 Jan 2024 14:17:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more comments. Remove unnecessary import.
>
> src/java.base/share/classes/sun/security/provider/certpath/Builder.java line 36:
> 
>> 34: import sun.security.provider.certpath.PKIX.BuilderParams;
>> 35: import sun.security.util.Debug;
>> 36: import sun.security.x509.GeneralNameInterface;
> 
> `GeneralNameInterface` is useless now.

Fixed.

> src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 556:
> 
>> 554:      * @return the common ancestor or null if none or an attribute of the
>> 555:      *    last RDN of the common ancestor is geographical
>> 556:      */
> 
> ~Is it possible to return the common ancestors of all the 3 names: trusted, issuer1, issuer2?~ Also, it seems there is no need to return a list. Just a number is enough. Actually you care about the difference from the common part, so how about return the distance directly?
> 
> Update: ignore the 1st part of this comment.

Fixed as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1448916279
PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1448917416


From mullan at openjdk.org  Thu Jan 11 14:09:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 14:09:42 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v2]
In-Reply-To: <yjT5cRw76GJ-wNseY1rUB4Nlb9brj6mwgFtwOWTrWXw=.847ddf10-57f8-497a-9751-7f6f776b92ab@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <yjT5cRw76GJ-wNseY1rUB4Nlb9brj6mwgFtwOWTrWXw=.847ddf10-57f8-497a-9751-7f6f776b92ab@github.com>
Message-ID: <1GtlvI48KGFIyGeZPDI1rn9vkHJChvS1Hqspkq5EJxk=.b6cff392-215a-4698-8728-7ad0e1eadffa@github.com>

On Wed, 10 Jan 2024 17:00:42 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more comments. Remove unnecessary import.
>
> src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 523:
> 
>> 521:                 }
>> 522:                 if (tAo1 != null) {
>> 523:                     if (tAo2 != null) {
> 
> Maybe it's unfamiliarity with this code, but I think we could use some comments here, especially since a similar condition is tested on line 534 (except tAo1 would be null in that case?).

Added more comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1448917072


From mbaesken at openjdk.org  Thu Jan 11 14:18:30 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Jan 2024 14:18:30 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v6]
In-Reply-To: <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
Message-ID: <-oN2Jw7wxoVxmM2RkkXEfmu7s7YGoDPncqISiXtEaJ0=.1068a643-1032-4ac4-9335-391ac38eb721@github.com>

On Thu, 4 Jan 2024 15:21:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - added additional class to @build tag
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - added isOracleLinux7() to IGNORED method group in TestMutuallyExclusivePlatformPredicates
>  - moved isOracleLinux7() method to Platform class
>  - simplified logic for determining OL 7
>  - Merge branch 'master' into pkcs11-ol79
>  - cleaned up MultipleLogins.java a little and added copyright date
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/b41df88f...eaaabc25

test/lib/jdk/test/lib/Platform.java line 354:

> 352:     public static boolean isOracleLinux7() {
> 353:         if (System.getProperty("os.name").toLowerCase().contains("linux") &&
> 354:                 System.getProperty("os.version").toLowerCase().contains("el")) {

Hi,  I checked and the el ("Enterprise Linux" ?)  is shown in os.version on RHEL and Oracle Linux.  But how reliable is it? Could this show up also on some other distros in os.version (maybe in the cpu-related string of uname output?) ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1448930089


From mullan at openjdk.org  Thu Jan 11 14:26:24 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 14:26:24 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v2]
In-Reply-To: <kKX4vgGnv2TOhlDjOrfYcjSCqLONhLEGGy-T-CfDvaQ=.e0d699c4-eedf-49f4-80d2-7500b5eae42a@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <kKX4vgGnv2TOhlDjOrfYcjSCqLONhLEGGy-T-CfDvaQ=.e0d699c4-eedf-49f4-80d2-7500b5eae42a@github.com>
Message-ID: <yvipD-3VODqTO79BtPfzCjax3h2MKSozidrOaRbQPxk=.ee6df6d7-b210-4c56-a1e0-a3e86efeb9ab@github.com>

On Thu, 11 Jan 2024 14:09:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
>> 
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
>> 
>> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
>> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
>> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
>> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more comments. Remove unnecessary import.

Some additional information on this fix for future reference. I removed 3 steps from the Comparator:

     * 3) Issuer is a descendant of a trusted subject (in order of
     *    number of links to the trusted subject)
     *    a) Issuer: ou=E,ou=D,ou=C,o=B,c=A        [links=1]
     *    b) Issuer: ou=F,ou=E,ou=D,ou=C,ou=B,c=A  [links=2]
     *
     * 4) Issuer is an ancestor of a trusted subject (in order of number of
     *    links to the trusted subject)
     *    a) Issuer: ou=C,o=B,c=A [links=1]
     *    b) Issuer: o=B,c=A      [links=2]
     ...
     * 6) Issuer is an ancestor of certificate subject (in order of number
     *    of links to the certificate subject)
     *    a) Issuer:  ou=K,o=J,c=A
     *       Subject: ou=L,ou=K,o=J,c=A
     *    b) Issuer:  o=J,c=A
     *       Subject: ou=L,ou=K,0=J,c=A
     
These steps were removed because it assumes the PKI hierarchy is very rigid, and each intermediate CA is a direct child of it's parent in the DN namespace. More commonly, there is some structure, but not so exact.  For example, a CA with a subject DN of ?CN=Root CA, O=OpenJDK, C=US? may issue a certificate to a sub-CA named ?CN=JDK  CA, OU=JDK, O=OpenJDK, C=US?. Here the subCA is not a direct descendant of the root CA, but they both share a common namespace of "O=OpenJDK, C=US" (which will be found by step 5 which was retained).

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

PR Comment: https://git.openjdk.org/jdk/pull/17248#issuecomment-1887289722


From weijun at openjdk.org  Thu Jan 11 14:39:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 14:39:25 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v2]
In-Reply-To: <kKX4vgGnv2TOhlDjOrfYcjSCqLONhLEGGy-T-CfDvaQ=.e0d699c4-eedf-49f4-80d2-7500b5eae42a@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <kKX4vgGnv2TOhlDjOrfYcjSCqLONhLEGGy-T-CfDvaQ=.e0d699c4-eedf-49f4-80d2-7500b5eae42a@github.com>
Message-ID: <Di3sGyyBM_DMFlR-cwqOfNm-Qk3JYyCxplsVcSfBBcg=.a1122fc5-45ac-4af0-abe8-6eb326220006@github.com>

On Thu, 11 Jan 2024 14:09:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
>> 
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
>> 
>> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
>> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
>> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
>> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more comments. Remove unnecessary import.

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

> 583:         }
> 584: 
> 585:         return issuer.size() - anchorRdns.subList(0, i).size();

Is it exactly `issuer.size() - i`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1448958382


From mdonovan at openjdk.org  Thu Jan 11 15:11:30 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 11 Jan 2024 15:11:30 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v6]
In-Reply-To: <-oN2Jw7wxoVxmM2RkkXEfmu7s7YGoDPncqISiXtEaJ0=.1068a643-1032-4ac4-9335-391ac38eb721@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
 <-oN2Jw7wxoVxmM2RkkXEfmu7s7YGoDPncqISiXtEaJ0=.1068a643-1032-4ac4-9335-391ac38eb721@github.com>
Message-ID: <4aK2d5Lf5SfMJXPy5p5zbiP__2QAttSeHLxKwjSjIYg=.55afe27a-252e-4983-aa32-2c01b541c5f2@github.com>

On Thu, 11 Jan 2024 14:16:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - added additional class to @build tag
>>  - Merge branch 'master' into pkcs11-ol79
>>  - Merge branch 'master' into pkcs11-ol79
>>  - added isOracleLinux7() to IGNORED method group in TestMutuallyExclusivePlatformPredicates
>>  - moved isOracleLinux7() method to Platform class
>>  - simplified logic for determining OL 7
>>  - Merge branch 'master' into pkcs11-ol79
>>  - cleaned up MultipleLogins.java a little and added copyright date
>>  - Merge branch 'master' into pkcs11-ol79
>>  - Merge branch 'master' into pkcs11-ol79
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f9115761...eaaabc25
>
> test/lib/jdk/test/lib/Platform.java line 354:
> 
>> 352:     public static boolean isOracleLinux7() {
>> 353:         if (System.getProperty("os.name").toLowerCase().contains("linux") &&
>> 354:                 System.getProperty("os.version").toLowerCase().contains("el")) {
> 
> Hi,  I checked and the el ("Enterprise Linux" ?)  is shown in os.version on RHEL and Oracle Linux.  But how reliable is it? Could this show up also on some other distros in os.version (maybe in the cpu-related string of uname output?) ?

I'm not aware of any conventions in the output of uname that would prevent other operating systems from including "el" followed by a number.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1449002307


From mbaesken at openjdk.org  Thu Jan 11 15:19:27 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Jan 2024 15:19:27 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v6]
In-Reply-To: <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
Message-ID: <ZNITSmrj5x4mS6VLTZm03XwXm2eS3UAjEf3EqVOR7O4=.9bb8af62-99c2-4787-a445-e4bd6eddd708@github.com>

On Thu, 4 Jan 2024 15:21:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - added additional class to @build tag
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - added isOracleLinux7() to IGNORED method group in TestMutuallyExclusivePlatformPredicates
>  - moved isOracleLinux7() method to Platform class
>  - simplified logic for determining OL 7
>  - Merge branch 'master' into pkcs11-ol79
>  - cleaned up MultipleLogins.java a little and added copyright date
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4049f198...eaaabc25

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16547#pullrequestreview-1815840970


From mbaesken at openjdk.org  Thu Jan 11 15:19:29 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Jan 2024 15:19:29 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v6]
In-Reply-To: <4aK2d5Lf5SfMJXPy5p5zbiP__2QAttSeHLxKwjSjIYg=.55afe27a-252e-4983-aa32-2c01b541c5f2@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <vOgQkvxaeydvQJhJDkhrCe2t8Lb8KZVqUfN46Ta1_OM=.d8cb76f5-055a-40d7-a2ab-27a53d3082bb@github.com>
 <-oN2Jw7wxoVxmM2RkkXEfmu7s7YGoDPncqISiXtEaJ0=.1068a643-1032-4ac4-9335-391ac38eb721@github.com>
 <4aK2d5Lf5SfMJXPy5p5zbiP__2QAttSeHLxKwjSjIYg=.55afe27a-252e-4983-aa32-2c01b541c5f2@github.com>
Message-ID: <PNpLDzVWK34l1ugIZ2Rvsva9B4APkRzGv9eSYANS_SI=.e4da76b7-7c16-4aa5-b5d6-29cf2bad6889@github.com>

On Thu, 11 Jan 2024 15:08:28 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/lib/jdk/test/lib/Platform.java line 354:
>> 
>>> 352:     public static boolean isOracleLinux7() {
>>> 353:         if (System.getProperty("os.name").toLowerCase().contains("linux") &&
>>> 354:                 System.getProperty("os.version").toLowerCase().contains("el")) {
>> 
>> Hi,  I checked and the el ("Enterprise Linux" ?)  is shown in os.version on RHEL and Oracle Linux.  But how reliable is it? Could this show up also on some other distros in os.version (maybe in the cpu-related string of uname output?) ?
>
> I'm not aware of any conventions in the output of uname that would prevent other operating systems from including "el" followed by a number.

okay , then let's keep it the way it is now and adjust later if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1449013540


From mdonovan at openjdk.org  Thu Jan 11 15:22:31 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 11 Jan 2024 15:22:31 GMT
Subject: Integrated: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
Message-ID: <hMWJadh_gKoUSFUcOtd8hGuWkDunKby3noIXM8jksys=.15f8582b-c46e-4a7a-93a9-cb4dc0b2c5b9@github.com>

On Tue, 7 Nov 2023 20:04:11 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.

This pull request has now been integrated.

Changeset: c2e77e2f
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2e77e2f17b624e750dea8fd51bbfde99596690e
Stats:     45 lines in 6 files changed: 36 ins; 4 del; 5 mod

8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

Reviewed-by: mbaesken

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

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


From mpowers at openjdk.org  Thu Jan 11 16:34:37 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 11 Jan 2024 16:34:37 GMT
Subject: RFR: JDK-8318105 [jmh] the test java.security.HSS failed with 2
 active threads [v2]
In-Reply-To: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>
References: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>
Message-ID: <HtK9FYC7BbRWm5XRY83Rc9XHf3iMVlzfSjSICEVISNg=.a15cacce-6047-47cf-bfb7-62dc6945e7f4@github.com>

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

Mark Powers has updated the pull request incrementally with two additional commits since the last revision:

 - Copyright
 - reworked to use Benchmark and Thread State

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16435/files
  - new: https://git.openjdk.org/jdk/pull/16435/files/6f2507d2..fb0d45f3

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

  Stats: 225 lines in 1 file changed: 126 ins; 64 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/16435.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16435/head:pull/16435

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


From mullan at openjdk.org  Thu Jan 11 17:31:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 17:31:37 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v3]
In-Reply-To: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
Message-ID: <q_IKeY2OK1xusisFIogpsEtrc8q5WRp26jZB2qvYcj0=.f87ab6dc-6d0e-4b4b-b0f6-f85bf7e36929@github.com>

> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
> 
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
> 
> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

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

  Fix whitespace error. Improve debugging. Change return value of distanceToCommonAncestor().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17248/files
  - new: https://git.openjdk.org/jdk/pull/17248/files/22444c6d..7a91821b

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

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

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


From mullan at openjdk.org  Thu Jan 11 17:31:40 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 17:31:40 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v2]
In-Reply-To: <Di3sGyyBM_DMFlR-cwqOfNm-Qk3JYyCxplsVcSfBBcg=.a1122fc5-45ac-4af0-abe8-6eb326220006@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <kKX4vgGnv2TOhlDjOrfYcjSCqLONhLEGGy-T-CfDvaQ=.e0d699c4-eedf-49f4-80d2-7500b5eae42a@github.com>
 <Di3sGyyBM_DMFlR-cwqOfNm-Qk3JYyCxplsVcSfBBcg=.a1122fc5-45ac-4af0-abe8-6eb326220006@github.com>
Message-ID: <WpE2nEDrQ9QB4Cva1CMl3hCa6gcSGK-0RfcBpRO_88s=.d5437c78-b472-4486-a24e-f8979f241c85@github.com>

On Thu, 11 Jan 2024 14:36:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more comments. Remove unnecessary import.
>
> src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java line 585:
> 
>> 583:         }
>> 584: 
>> 585:         return issuer.size() - anchorRdns.subList(0, i).size();
> 
> Is it exactly `issuer.size() - i`?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1449179288


From mullan at openjdk.org  Thu Jan 11 17:41:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Jan 2024 17:41:25 GMT
Subject: [jdk22] RFR: 8322971: KEM.getInstance() should check if a
 3rd-party security provider is signed
In-Reply-To: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>
References: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>
Message-ID: <HZjSp1GBSrdTfktAqFJzPrDamiZDoYbnLQkV5eQPzow=.606def3f-b38b-4910-a4d2-91b9ab154b80@github.com>

On Thu, 11 Jan 2024 13:56:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/61#pullrequestreview-1816128893


From mdonovan at openjdk.org  Thu Jan 11 18:15:43 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 11 Jan 2024 18:15:43 GMT
Subject: RFR: 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails
 with "Alias <246810> does not exist" [v2]
In-Reply-To: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
References: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
Message-ID: <RvOTZabMQC0WAbF_f-L9m9-uckS5lrwgSVNc-tdBCp4=.8fc0ac15-6af2-47f7-af6f-7c46f562f7b1@github.com>

> I was unable to recreate the error but it looks like the problem could happen if two instances of the test are run on the same machine.  Also, if the deleteEntry() calls in the finally block throw an exception, they can hide any exceptions thrown earlier in the test.
> 
> I updated the test to use randomly generated alias names. I also updated the finally block so exceptions thrown by deleteEntry() are logged but not thrown.

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

 - Merge branch 'master' into keytool-alias
 - 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails with "Alias <246810> does not exist"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17352/files
  - new: https://git.openjdk.org/jdk/pull/17352/files/475815f3..960b7921

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

  Stats: 2844 lines in 73 files changed: 1740 ins; 704 del; 400 mod
  Patch: https://git.openjdk.org/jdk/pull/17352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17352/head:pull/17352

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


From mpowers at openjdk.org  Thu Jan 11 18:17:22 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 11 Jan 2024 18:17:22 GMT
Subject: RFR: JDK-8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4,
 and increase overlap testing
In-Reply-To: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
References: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
Message-ID: <olVFl1V9TlGxPcqm-tV243zIfWrMam6gcNdPXuAae7s=.4459f7c5-e47c-4b60-9516-258ce1798515@github.com>

On Thu, 11 Jan 2024 03:26:03 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of a few simple test changes.  This fixes a failure with two manually run AES/GCM tests that depended on another test that changed with [JDK-8318756](https://bugs.openjdk.org/browse/JDK-8318756).  It also adds testing for overlapping buffers that AES/GCM has, but CC20P1305 needs after JDK-8318756 was included.
> 
> After the change, manual testing of GCMIncrementByte4 and GCMIncrementDirect4 were successfully and automated tests passed as well.
> 
> thanks
> 
> Tony

I don't see mention of ChaCha20-Poly1305 in the bug report.

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

PR Comment: https://git.openjdk.org/jdk/pull/17362#issuecomment-1887709094


From valeriep at openjdk.org  Thu Jan 11 18:29:23 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 11 Jan 2024 18:29:23 GMT
Subject: [jdk22] RFR: 8322971: KEM.getInstance() should check if a
 3rd-party security provider is signed
In-Reply-To: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>
References: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>
Message-ID: <LUAfEl3zSpC_7Yp17eztLj6MiP55NHCgp3UpOoC8UUs=.bc07ff55-4428-4c19-8a4b-9d04da27ba9f@github.com>

On Thu, 11 Jan 2024 13:56:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/61#pullrequestreview-1816248352


From ascarpino at openjdk.org  Thu Jan 11 19:47:22 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 11 Jan 2024 19:47:22 GMT
Subject: RFR: JDK-8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4,
 and increase overlap testing
In-Reply-To: <olVFl1V9TlGxPcqm-tV243zIfWrMam6gcNdPXuAae7s=.4459f7c5-e47c-4b60-9516-258ce1798515@github.com>
References: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
 <olVFl1V9TlGxPcqm-tV243zIfWrMam6gcNdPXuAae7s=.4459f7c5-e47c-4b60-9516-258ce1798515@github.com>
Message-ID: <kSAIFcDyzp2bJEvHLOwYRVF_jjo0E5pBYuPdyfcTDJg=.6e9c3d69-e43e-4c4b-b051-77023b9fcaed@github.com>

On Thu, 11 Jan 2024 18:14:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> I don't see mention of ChaCha20-Poly1305 in the bug report.

Yes, I didn't call it out specifically. I found that missing check as I was working on the fix.  I'll add a comment in there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17362#issuecomment-1887853584


From weijun at openjdk.org  Thu Jan 11 21:00:31 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 21:00:31 GMT
Subject: [jdk22] Integrated: 8322971: KEM.getInstance() should check if a
 3rd-party security provider is signed
In-Reply-To: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>
References: <JxWfC2RMpCQVwfj4s7tj1a8xnfstw59SITdtyy7L7G0=.5d0f2be2-8cf0-471c-b20a-51eb568835a0@github.com>
Message-ID: <VizzdhEGus7R4znBOqygMkuErpBqx8n6_6XGpxvho_I=.d6de5dce-aaac-4485-818d-53ebb032dc48@github.com>

On Thu, 11 Jan 2024 13:56:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed

This pull request has now been integrated.

Changeset: 4ea14b27
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/4ea14b2720e811082ad52c21d250fc0469cdfe2a
Stats:     119 lines in 4 files changed: 74 ins; 29 del; 16 mod

8322971: KEM.getInstance() should check if a 3rd-party security provider is signed

Reviewed-by: mullan, valeriep
Backport-of: 9fd855ed477bb0849ce5c774854844deec0f4c6b

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

PR: https://git.openjdk.org/jdk22/pull/61


From prappo at openjdk.org  Thu Jan 11 21:52:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 21:52:35 GMT
Subject: Integrated: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <zODXHjRUec47GFPmSkjjI8pi6qjXblUSXhl1q3W1xRE=.a2fbf89f-33cb-457c-a9a5-b9b243f5da11@github.com>

On Fri, 23 Jun 2023 17:27:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

This pull request has now been integrated.

Changeset: 49e61213
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49e61213474b846fd081e890e5abfbbbb9b79e3c
Stats:     527 lines in 6 files changed: 500 ins; 16 del; 11 mod

8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger

Reviewed-by: rriggs, redestad, rgiulietti

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

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


From weijun at openjdk.org  Thu Jan 11 22:12:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 22:12:58 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
Message-ID: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>

Re-implement it as an `Iterable` to be safe and make debugger happy.

No regression, just a refactoring.

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

Commit messages:
 - the fix

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

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


From weijun at openjdk.org  Thu Jan 11 22:25:26 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 22:25:26 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <V4QJDMdqAmD8YeiX6PuBdKgJHy5ct5aMDKL-A3NfhYw=.ed19993c-fde8-4f6c-943d-4c3bbd8cec58@github.com>

On Thu, 11 Jan 2024 22:06:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Re-implement it as an `Iterable` to be safe and make debugger happy.
> 
> No regression, just a refactoring.

I realized even an `Iterable` can be iterated multiple times. It should be an `Iterator`. Will re-open PR once fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17381#issuecomment-1888064422


From weijun at openjdk.org  Thu Jan 11 22:25:27 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Jan 2024 22:25:27 GMT
Subject: Withdrawn: 8323624: ProviderList.ServiceList does not need to be a
 list
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <3AxiH5dlRUNHBp3kx5yIrTuNKXmT4J0mh03tCE4OII0=.7ac895ce-357e-4e83-9a28-cf8c42d40e84@github.com>

On Thu, 11 Jan 2024 22:06:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Re-implement it as an `Iterable` to be safe and make debugger happy.
> 
> No regression, just a refactoring.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.org  Thu Jan 11 22:59:19 2024
From: duke at openjdk.org (Ben Perez)
Date: Thu, 11 Jan 2024 22:59:19 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <RuJCHjzq2sYzhwbkcl64hDLA9Q6qVbthRGGtac6FUdI=.cf95ed10-3ce7-4071-b832-d27382f334db@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com>
 <rIPMY7WYts2vAJHfuTWxbucs-SUo9oNsR1lR0k1hj4Y=.f4e05c0e-7697-4938-87c3-989b49a8868c@github.com>
 <RuJCHjzq2sYzhwbkcl64hDLA9Q6qVbthRGGtac6FUdI=.cf95ed10-3ce7-4071-b832-d27382f334db@github.com>
Message-ID: <NVvLvxWBXoBwuYnr3IWk0f3DuxUvgEnEgWJ0Aokrnlc=.e3b4bfbf-425b-4006-8272-1265634a883c@github.com>

On Tue, 2 Jan 2024 21:54:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Do you think we can remove `PKCS9Attributes.getAttributes()` entirely or should we just modify it to not use `PKCS9_OIDS` anymore?
>
> I think we can remove both. There is no need to keep a useless method as long as it's not an exported API.

The test `sun/security/x509/AlgorithmId/NonStandardNames.java` uses the `getAttributes()` though it seems it does so just to verify the method works. I'll go ahead and remove that method call from the test unless you think that would be a bad idea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1449493698


From duke at openjdk.org  Thu Jan 11 23:25:19 2024
From: duke at openjdk.org (Ben Perez)
Date: Thu, 11 Jan 2024 23:25:19 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v2]
In-Reply-To: <q7_q6e6mUbgH72cP8cJlaVpWpcUO7IOxe84jb-LSw1c=.5bc23163-479a-45e7-be0f-bb34a8a877c8@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <1vt__zPlnHDgs7B6rbeE-uSzQuhfoXv2a27V_D9QkZ4=.e453b882-ec1b-42f3-bdde-67b53e622ee5@github.com>
 <p-ZvHMWkd0WoysZpjKD5WqOl5qDK1lQfer1KyLV8aAM=.cee82871-86b3-4f26-80b1-c774ea0abaff@github.com>
 <q7_q6e6mUbgH72cP8cJlaVpWpcUO7IOxe84jb-LSw1c=.5bc23163-479a-45e7-be0f-bb34a8a877c8@github.com>
Message-ID: <c_xZlc_mxUhuvpE-daS6BnuZPYp7ZpnE2gKUzs5FVFY=.62c66cec-f661-4656-acf0-02eeee184d39@github.com>

On Wed, 10 Jan 2024 02:53:15 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 321:
>> 
>>> 319: 
>>> 320:         this.oid = oid;
>>> 321:         info = oidMap.get(oid);
>> 
>> What if `info` is `null` (there is no entry for the specified OID)? The prior code set the value class to `byte[]` in that case. I think we want to preserve that behavior.
>
> So, it seems that no test is triggering a NPE? Consider adding a test for covering this scenario?

This was caught by `sun/security/pkcs/pkcs9/UnknownAttribute.java` and has been fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1449521516


From duke at openjdk.org  Thu Jan 11 23:32:14 2024
From: duke at openjdk.org (Ben Perez)
Date: Thu, 11 Jan 2024 23:32:14 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v3]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <meFqHiWiHS9KyKLtBHHr2m4OHUhkWLjqPHUiFtHeeQk=.9907d0f6-0127-4f04-a903-9868c7b312d8@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  Added encoding and value functionality to AttributeInfo to replace large switch statements.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/32a2304c..1920e000

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

  Stats: 390 lines in 3 files changed: 74 ins; 283 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/17132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17132/head:pull/17132

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


From duke at openjdk.org  Thu Jan 11 23:42:31 2024
From: duke at openjdk.org (Ben Perez)
Date: Thu, 11 Jan 2024 23:42:31 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v4]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <rkk3pKgEWEPvypH6ATzl4QdkQY52DTAX9pcluY81jbk=.1ba739d3-ab19-4d1f-9216-9df6f6f34dcc@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  removed calls to Class.forName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/1920e000..c73c2aca

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

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

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


From duke at openjdk.org  Fri Jan 12 00:04:22 2024
From: duke at openjdk.org (Ben Perez)
Date: Fri, 12 Jan 2024 00:04:22 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v4]
In-Reply-To: <rkk3pKgEWEPvypH6ATzl4QdkQY52DTAX9pcluY81jbk=.1ba739d3-ab19-4d1f-9216-9df6f6f34dcc@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <rkk3pKgEWEPvypH6ATzl4QdkQY52DTAX9pcluY81jbk=.1ba739d3-ab19-4d1f-9216-9df6f6f34dcc@github.com>
Message-ID: <m6zr7EyTrggGEsesiqMfnLAWdh2RO5mBT0AQtpcYSck=.807d39bd-bcce-4b9b-8803-a48da2b36084@github.com>

On Thu, 11 Jan 2024 23:42:31 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed calls to Class.forName

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 467:

> 465:             DerInputStream dis = new DerInputStream(elems[0].toByteArray());
> 466:             value = dis.getTime();
> 467:             break;

The current changes both: 
1. Removes the `elemTag` variable since it is never used and calling `getTag()` does not change `elems`.
2. Simply sets `value = elems[0].getTime()` so as to avoid the conversion to a `DerInputStream` and back.

Neither of these changes caused problems when testing but I wanted to double check before the PR gets merged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1449557089


From duke at openjdk.org  Fri Jan 12 00:17:32 2024
From: duke at openjdk.org (Ben Perez)
Date: Fri, 12 Jan 2024 00:17:32 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v5]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <ufXMGY6TxVljbXBCDWEGpQU_md1ReWF9xnFATOzV0u4=.02cbf74d-5c22-49ab-b83b-ac96ae7c3268@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  Added comments for new functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/c73c2aca..730979a5

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

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

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


From duke at openjdk.org  Fri Jan 12 01:17:31 2024
From: duke at openjdk.org (duke)
Date: Fri, 12 Jan 2024 01:17:31 GMT
Subject: Withdrawn: 8317538: RSA have scalability issue for high vCPU numbers
In-Reply-To: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
Message-ID: <2nG0DDeLrT9ehZpQM4GH2mGKXtJRFKGS0mwTtctaLTw=.2d3df010-6c70-462f-a394-a0d14ba209ca@github.com>

On Fri, 27 Oct 2023 14:43:56 GMT, Ben Perez <duke at openjdk.org> wrote:

> Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance

This pull request has been closed without being integrated.

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

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


From kdriver at openjdk.org  Fri Jan 12 05:45:20 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 12 Jan 2024 05:45:20 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v3]
In-Reply-To: <q_IKeY2OK1xusisFIogpsEtrc8q5WRp26jZB2qvYcj0=.f87ab6dc-6d0e-4b4b-b0f6-f85bf7e36929@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <q_IKeY2OK1xusisFIogpsEtrc8q5WRp26jZB2qvYcj0=.f87ab6dc-6d0e-4b4b-b0f6-f85bf7e36929@github.com>
Message-ID: <XAp0qUxzuBupUepcC7vSnXtMNEYbaUJHvQ4Hzu8k9ds=.5c982b75-4e41-40e6-95b0-3c0ddf12e611@github.com>

On Thu, 11 Jan 2024 17:31:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
>> 
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
>> 
>> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
>> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
>> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
>> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error. Improve debugging. Change return value of distanceToCommonAncestor().

Marked as reviewed by kdriver (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17248#pullrequestreview-1817437198


From mullan at openjdk.org  Fri Jan 12 13:49:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 12 Jan 2024 13:49:20 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <4hW1q5AVA7NvZ04ww4XD6G1VW_qNsPwRCi7q8TuCZ2E=.f1c2641c-b333-4439-8a43-5a43fb42ca83@github.com>

On Thu, 11 Jan 2024 13:33:54 GMT, John Jiang <jjiang at openjdk.org> wrote:

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

src/java.base/share/classes/sun/security/ec/ECDHKeyAgreement.java line 83:

> 81:         privateKey = null;
> 82:         privateKeyOps = null;
> 83:         publicKey = null;

The fields should be initialized to null, so I don't think you need these lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1450474761


From jjiang at openjdk.org  Fri Jan 12 15:33:22 2024
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 12 Jan 2024 15:33:22 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them
In-Reply-To: <4hW1q5AVA7NvZ04ww4XD6G1VW_qNsPwRCi7q8TuCZ2E=.f1c2641c-b333-4439-8a43-5a43fb42ca83@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <4hW1q5AVA7NvZ04ww4XD6G1VW_qNsPwRCi7q8TuCZ2E=.f1c2641c-b333-4439-8a43-5a43fb42ca83@github.com>
Message-ID: <c4WOCzfqHbEoDfCmMqs8uAmW1Xh37lyw5e36cCWw4zY=.63aee54b-5ef1-486a-ac87-b45a0adc06ac@github.com>

On Fri, 12 Jan 2024 13:46:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> ECDHKeyAgreement should validate the parameters before assigning them to the fields.
>
> src/java.base/share/classes/sun/security/ec/ECDHKeyAgreement.java line 83:
> 
>> 81:         privateKey = null;
>> 82:         privateKeyOps = null;
>> 83:         publicKey = null;
> 
> The fields should be initialized to null, so I don't think you need these lines.

KeyAgreement ka = KeyAgreement.getInstance("ECDH");
ka.init(key1);
ka.init(key2);

If no those lines, when the second `init` throws exception, and the keys set by the first `init` are not cleared.
Please consider the test case `testInitWithInvalidKey` in `ECDHKeyAgreementParamValidation`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1450607215


From weijun at openjdk.org  Fri Jan 12 17:57:45 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 Jan 2024 17:57:45 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v2]
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <3vd_qubif-JN542aRSlRFUJuXDMLqAmkd9bOnLdtMv8=.31863ced-b722-4ef6-99bf-b9220e2a08b4@github.com>

> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
> 
> No regression, just a refactoring.

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

  : iterator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17381/files
  - new: https://git.openjdk.org/jdk/pull/17381/files/ce987768..58523048

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

  Stats: 60 lines in 12 files changed: 6 ins; 16 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/17381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17381/head:pull/17381

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


From weijun at openjdk.org  Fri Jan 12 18:06:33 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 Jan 2024 18:06:33 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v3]
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <mgpIEOJk9SB4HS1I1lwAC4VFPmVU0pkvyE7OPovczlE=.2e972411-1014-4c89-8065-fbb3328705a7@github.com>

> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
> 
> No regression, just a refactoring.

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

  use consistent names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17381/files
  - new: https://git.openjdk.org/jdk/pull/17381/files/58523048..cf3d124e

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

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

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


From rriggs at openjdk.org  Fri Jan 12 19:17:23 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Jan 2024 19:17:23 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v14]
In-Reply-To: <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
Message-ID: <Oe2zMW-fiQ4i3b1fEJN3DOgNWMxgU7UgqgbDsKmvQic=.be089074-d7a1-4152-97b8-cb10d30ae26b@github.com>

On Wed, 10 Jan 2024 18:56:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small space optimization.

Thanks for the updates.  LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17129#pullrequestreview-1818884173


From mullan at openjdk.org  Fri Jan 12 20:46:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 12 Jan 2024 20:46:23 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them
In-Reply-To: <c4WOCzfqHbEoDfCmMqs8uAmW1Xh37lyw5e36cCWw4zY=.63aee54b-5ef1-486a-ac87-b45a0adc06ac@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <4hW1q5AVA7NvZ04ww4XD6G1VW_qNsPwRCi7q8TuCZ2E=.f1c2641c-b333-4439-8a43-5a43fb42ca83@github.com>
 <c4WOCzfqHbEoDfCmMqs8uAmW1Xh37lyw5e36cCWw4zY=.63aee54b-5ef1-486a-ac87-b45a0adc06ac@github.com>
Message-ID: <hK9S3qJo4ZJgNncszwOmq8NudvMZmjzyoYyhqopJFjo=.5ce3f82e-8e94-4090-993c-524afe22c4ca@github.com>

On Fri, 12 Jan 2024 15:30:33 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ec/ECDHKeyAgreement.java line 83:
>> 
>>> 81:         privateKey = null;
>>> 82:         privateKeyOps = null;
>>> 83:         publicKey = null;
>> 
>> The fields should be initialized to null, so I don't think you need these lines.
>
> KeyAgreement ka = KeyAgreement.getInstance("ECDH");
> ka.init(key1);
> ka.init(key2);
> 
> If no those lines, when the second `init` throws exception, and the keys set by the first `init` are not cleared.
> Please consider the test case `testInitWithInvalidKey` in `ECDHKeyAgreementParamValidation`.

Yes, you are right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1450907385


From mullan at openjdk.org  Fri Jan 12 20:53:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 12 Jan 2024 20:53:21 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <8-LPJodDiQ_FEy4EqIbMMNF4e5eaXyX0lJFs65_M0oc=.2482a97b-a314-4d2f-9bc9-6f61aada7981@github.com>

On Thu, 11 Jan 2024 13:33:54 GMT, John Jiang <jjiang at openjdk.org> wrote:

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 28:

> 26:  * @bug 8320449
> 27:  * @summary ECDHKeyAgreement should validate parameters before assigning them to fields.
> 28:  * @run junit ECDHKeyAgreementParamValidation

Most security regression tests don't use junit. I think it would be better to not rely on it. There is a similar asserts library for tests that you can use in `test/lib/jdk/test/lib/Asserts.java`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1450912957


From jjiang at openjdk.org  Sat Jan 13 00:52:29 2024
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 13 Jan 2024 00:52:29 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them
In-Reply-To: <8-LPJodDiQ_FEy4EqIbMMNF4e5eaXyX0lJFs65_M0oc=.2482a97b-a314-4d2f-9bc9-6f61aada7981@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <8-LPJodDiQ_FEy4EqIbMMNF4e5eaXyX0lJFs65_M0oc=.2482a97b-a314-4d2f-9bc9-6f61aada7981@github.com>
Message-ID: <OfmFVPHJoxSK4HKhoFWDIrn0LyFNU6ZzqF0GLLZw4hs=.784ffb92-a969-4a19-bc39-ce21b31f38c0@github.com>

On Fri, 12 Jan 2024 20:51:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> ECDHKeyAgreement should validate the parameters before assigning them to the fields.
>
> test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 28:
> 
>> 26:  * @bug 8320449
>> 27:  * @summary ECDHKeyAgreement should validate parameters before assigning them to fields.
>> 28:  * @run junit ECDHKeyAgreementParamValidation
> 
> Most security regression tests don't use junit. I think it would be better to not rely on it. There is a similar asserts library for tests that you can use in `test/lib/jdk/test/lib/Asserts.java`.

I originally didn't depend on JUnit. But this tool can easily execute multiple test cases independently.
A single failed case doesn't make the whole test fail fast, and all cases always be executed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1451058140


From duke at openjdk.org  Sat Jan 13 01:10:26 2024
From: duke at openjdk.org (Bernd)
Date: Sat, 13 Jan 2024 01:10:26 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <u-HU5Fuo-QcFYVvHli9Khqz7FokrLnIhfMthj_TzbZo=.da15932a-acd3-4354-abc8-d06101b789da@github.com>

On Thu, 11 Jan 2024 13:33:54 GMT, John Jiang <jjiang at openjdk.org> wrote:

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 90:

> 88:         KeyAgreement ka = KeyAgreement.getInstance("ECDH");
> 89:         ka.init(kpP256.getPrivate());
> 90:         try {

Should this be assertThrows like the other ones?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1451066698


From jjiang at openjdk.org  Sat Jan 13 02:20:50 2024
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 13 Jan 2024 02:20:50 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v2]
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <hjKzsc0DPopdpMepGD0_agaHlOdS2AXwh5WeFz0v8Nc=.543e11d8-afc6-477b-aa3e-70872378c85d@github.com>

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

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

  more assertThrows on doPhase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17373/files
  - new: https://git.openjdk.org/jdk/pull/17373/files/8a573464..68a53e89

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

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

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


From jjiang at openjdk.org  Sat Jan 13 02:28:21 2024
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 13 Jan 2024 02:28:21 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v2]
In-Reply-To: <u-HU5Fuo-QcFYVvHli9Khqz7FokrLnIhfMthj_TzbZo=.da15932a-acd3-4354-abc8-d06101b789da@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <u-HU5Fuo-QcFYVvHli9Khqz7FokrLnIhfMthj_TzbZo=.da15932a-acd3-4354-abc8-d06101b789da@github.com>
Message-ID: <20w_i_u3PqRbzh3qlYv9Ps0mRk9tdcubRU-t11FYsrU=.55eeadb8-44e6-411a-a0a7-ed3bdedb5581@github.com>

On Sat, 13 Jan 2024 01:07:20 GMT, Bernd <duke at openjdk.org> wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more assertThrows on doPhase
>
> test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 90:
> 
>> 88:         KeyAgreement ka = KeyAgreement.getInstance("ECDH");
>> 89:         ka.init(kpP256.getPrivate());
>> 90:         try {
> 
> Should this be assertThrows like the other ones?

I assumed this point must fail and my fix for this bug didn't concern it.
Maybe some test on KeyAgreement already does that, so I didn't add a check point on it.

Anyway, just added this assertion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1451105467


From mullan at openjdk.org  Sun Jan 14 19:12:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Sun, 14 Jan 2024 19:12:19 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v2]
In-Reply-To: <OfmFVPHJoxSK4HKhoFWDIrn0LyFNU6ZzqF0GLLZw4hs=.784ffb92-a969-4a19-bc39-ce21b31f38c0@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <8-LPJodDiQ_FEy4EqIbMMNF4e5eaXyX0lJFs65_M0oc=.2482a97b-a314-4d2f-9bc9-6f61aada7981@github.com>
 <OfmFVPHJoxSK4HKhoFWDIrn0LyFNU6ZzqF0GLLZw4hs=.784ffb92-a969-4a19-bc39-ce21b31f38c0@github.com>
Message-ID: <12vtnMRS8nADR8OcHlVm4hZT943dwcwYbR23vLC9bLw=.be3596a4-8a11-4f13-af27-73a70ae8469a@github.com>

On Sat, 13 Jan 2024 00:49:39 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 28:
>> 
>>> 26:  * @bug 8320449
>>> 27:  * @summary ECDHKeyAgreement should validate parameters before assigning them to fields.
>>> 28:  * @run junit ECDHKeyAgreementParamValidation
>> 
>> Most security regression tests don't use junit. I think it would be better to not rely on it. There is a similar asserts library for tests that you can use in `test/lib/jdk/test/lib/Asserts.java`.
>
> I originally didn't depend on JUnit. But this tool can easily execute multiple test cases independently.
> A single failed case doesn't make the whole test fail fast, and all cases always be executed.

Fair point, although there are ways to workaround that w/o junit.

AFAICT, this will be the first security test to depend on junit. @rhalade are you ok with this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1451787554


From jjiang at openjdk.org  Mon Jan 15 03:37:45 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 15 Jan 2024 03:37:45 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v3]
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <j3ZwBhvuxXd4tK7zEIyxbuTxclSIggPMCxTKq4mJmGk=.51e924d6-3845-4834-ae91-80c9cfe9c7d4@github.com>

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

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

  Not use JUnit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17373/files
  - new: https://git.openjdk.org/jdk/pull/17373/files/68a53e89..9a326117

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

  Stats: 35 lines in 1 file changed: 23 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17373/head:pull/17373

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


From jjiang at openjdk.org  Mon Jan 15 03:37:46 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 15 Jan 2024 03:37:46 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v3]
In-Reply-To: <12vtnMRS8nADR8OcHlVm4hZT943dwcwYbR23vLC9bLw=.be3596a4-8a11-4f13-af27-73a70ae8469a@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <8-LPJodDiQ_FEy4EqIbMMNF4e5eaXyX0lJFs65_M0oc=.2482a97b-a314-4d2f-9bc9-6f61aada7981@github.com>
 <OfmFVPHJoxSK4HKhoFWDIrn0LyFNU6ZzqF0GLLZw4hs=.784ffb92-a969-4a19-bc39-ce21b31f38c0@github.com>
 <12vtnMRS8nADR8OcHlVm4hZT943dwcwYbR23vLC9bLw=.be3596a4-8a11-4f13-af27-73a70ae8469a@github.com>
Message-ID: <374eTvvQzCIv58CKAgcePmtzdkXa1NNLnYpUQlVNFkc=.ed37498c-ad1b-4781-b05f-1e67aba0fc1b@github.com>

On Sun, 14 Jan 2024 19:09:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I originally didn't depend on JUnit. But this tool can easily execute multiple test cases independently.
>> A single failed case doesn't make the whole test fail fast, and all cases always be executed.
>
> Fair point, although there are ways to workaround that w/o junit.
> 
> AFAICT, this will be the first security test to depend on junit. @rhalade are you ok with this?

Just updated this test and not used JUnit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1451899335


From rgiulietti at openjdk.org  Mon Jan 15 10:20:24 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 Jan 2024 10:20:24 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
Message-ID: <yFXuwbG7sVzKvl9-_r57Q0th9QOH6IhffFbHRXjjLs4=.77468544-07c2-4638-9eb1-3b39891df21d@github.com>

On Tue, 19 Dec 2023 17:53:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to reviewer's comments.
>
>> You mean, in the @description annotation?
> 
> Yes.

@egahlin Are you OK with the last commit from the perspective of hotspot-jfr?

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

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1891803118


From rgiulietti at openjdk.org  Mon Jan 15 10:23:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 Jan 2024 10:23:23 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v14]
In-Reply-To: <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
Message-ID: <KBa3T5JJDPC4rlXAndcSfT5LH4Z5qJsLdzMgHKgY49w=.7bd8b294-4087-4a03-a7b7-bc50b68e9f77@github.com>

On Wed, 10 Jan 2024 18:56:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small space optimization.

Anybody from security wants to chime in?

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

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1891808292


From egahlin at openjdk.org  Mon Jan 15 13:26:25 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 15 Jan 2024 13:26:25 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
Message-ID: <rprJpWBWz5iqcQKigB8oUTryMeijWmWKuCP0wKXSlvI=.f21f1a6f-76de-47ae-9c9a-3c6eeda54ae6@github.com>

On Tue, 19 Dec 2023 17:53:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to reviewer's comments.
>
>> You mean, in the @description annotation?
> 
> Yes.

> @egahlin Are you OK with the last commit from the perspective of hotspot-jfr?

The JFR product code looks fine. 

I think the test could be simplified. There is no need to disable threshold or stack trace.

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

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1892171443


From rgiulietti at openjdk.org  Mon Jan 15 14:17:40 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 Jan 2024 14:17:40 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v15]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>

> Adds serialization misdeclaration events to JFR.

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

  Removed useless event settings in test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/b76285d9..d0f16b8d

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

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

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


From egahlin at openjdk.org  Mon Jan 15 16:30:24 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 15 Jan 2024 16:30:24 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v15]
In-Reply-To: <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
Message-ID: <AWTrYof-sFDoNiVL6F4IC3_TDUCgkYNpOrc_LvPGPtw=.9913fc61-9e23-445c-b5b3-2a7dcce451e8@github.com>

On Mon, 15 Jan 2024 14:17:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed useless event settings in test.

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17129#pullrequestreview-1821998747


From jwaters at openjdk.org  Tue Jan 16 06:25:20 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 16 Jan 2024 06:25:20 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v7]
In-Reply-To: <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
Message-ID: <XddbATTEzaWouSP2yQN0RaEbhfwG7xwrhSirS1TzmRs=.e4080a07-2aa4-40c0-8751-958248edb414@github.com>

On Wed, 10 Jan 2024 12:53:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the remaining case in sspi.cpp

I've done the next best thing, which is rearrange the label blocks so that a goto to them doesn't cross initialization of a local. Is this a better solution?

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1893137539


From mullan at openjdk.org  Tue Jan 16 13:46:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 16 Jan 2024 13:46:22 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v3]
In-Reply-To: <j3ZwBhvuxXd4tK7zEIyxbuTxclSIggPMCxTKq4mJmGk=.51e924d6-3845-4834-ae91-80c9cfe9c7d4@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <j3ZwBhvuxXd4tK7zEIyxbuTxclSIggPMCxTKq4mJmGk=.51e924d6-3845-4834-ae91-80c9cfe9c7d4@github.com>
Message-ID: <ceUkTFLy5pjX11D-ua7kKwPXNC5xGBP6a22dgEILQ9Q=.2aabdf02-a287-48f8-b503-1a15d9e38b9b@github.com>

On Mon, 15 Jan 2024 03:37:45 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> ECDHKeyAgreement should validate the parameters before assigning them to the fields.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not use JUnit

test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 72:

> 70:                 IllegalStateException.class,
> 71:                 ()->ka.doPhase(kp.getPublic(), true));
> 72:     }

How about also calling `generateSecret` and checking for `IllegalStateException`?

test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 92:

> 90:                 () -> ka.doPhase(kpP384.getPublic(), true));
> 91: 
> 92:         // Should not generate share key with SECP256R1 private key and SECP384R1 public key

Typo: s/share/shared/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1453442848
PR Review Comment: https://git.openjdk.org/jdk/pull/17373#discussion_r1453443829


From jjiang at openjdk.org  Tue Jan 16 16:42:37 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 16 Jan 2024 16:42:37 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v4]
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <hHxmR8R6koERZiUvvnV9ZATSMe0Jdk21Z6-dxNRIzxY=.4e7dc82d-b968-4298-98c5-9c1259e6b92b@github.com>

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

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

  more check on generateSecret

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17373/files
  - new: https://git.openjdk.org/jdk/pull/17373/files/9a326117..2eb5fb41

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

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

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


From weijun at openjdk.org  Tue Jan 16 17:46:26 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 16 Jan 2024 17:46:26 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v7]
In-Reply-To: <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
Message-ID: <cVSiEqXAnXckvyoKYdoYEV8rutMVxQ8JrqXCLyoEVcs=.e107fc77-8a33-4142-bbf7-44663d4c6e32@github.com>

On Wed, 10 Jan 2024 12:53:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the remaining case in sspi.cpp

Thanks a lot for your patience. I've added some comments.

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

> 380: 
> 381: execution:
> 382: 

Remove this empty line to be consistent with the `err:` branch.

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

> 420:     gss_name_struct* name = new gss_name_struct;
> 421:     if (name == nullptr) {
> 422:         goto err;

Go back? This looks more evil to me. Can we just `delete` and `return` here?

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

> 536:     goto execution;
> 537: cleanup:
> 538:     static_cast<void>(0);

What is this for?

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

> 541:         delete[] fullname;
> 542:     }
> 543:     goto finish;

Instead of `goto finish`, can we `return` here?

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

> 578:     exported_name->value = buffer;
> 579:     result = GSS_S_COMPLETE;
> 580:     goto cleanup;

Can we duplicate `delete[] fullname` and `return` here?

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

PR Review: https://git.openjdk.org/jdk/pull/16682#pullrequestreview-1824364216
PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1453756600
PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1453757389
PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1453762269
PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1453763075
PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1453764065


From henryjen at openjdk.org  Tue Jan 16 17:46:21 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 16 Jan 2024 17:46:21 GMT
Subject: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1
Message-ID: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>

CPU24_01 fixes.

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

Commit messages:
 - 8317547: Enhance TLS connection support
 - 8314307: Improve loop handling
 - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
 - 8314468: Improve Compiler loops
 - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
 - 8314295: Enhance verification of verifier
 - 8308204: Enhanced certificate processing

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/17448/files
  Stats: 736 lines in 16 files changed: 476 ins; 65 del; 195 mod
  Patch: https://git.openjdk.org/jdk/pull/17448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17448/head:pull/17448

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


From henryjen at openjdk.org  Tue Jan 16 18:02:26 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 16 Jan 2024 18:02:26 GMT
Subject: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b
Message-ID: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>

CPU24_01 fixes.

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

Commit messages:
 - 8317547: Enhance TLS connection support
 - 8314307: Improve loop handling
 - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
 - 8314468: Improve Compiler loops
 - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
 - 8314295: Enhance verification of verifier
 - 8308204: Enhanced certificate processing

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk22/pull/83/files
  Stats: 736 lines in 16 files changed: 476 ins; 65 del; 195 mod
  Patch: https://git.openjdk.org/jdk22/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/83/head:pull/83

PR: https://git.openjdk.org/jdk22/pull/83


From mullan at openjdk.org  Tue Jan 16 18:47:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 16 Jan 2024 18:47:20 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v4]
In-Reply-To: <hHxmR8R6koERZiUvvnV9ZATSMe0Jdk21Z6-dxNRIzxY=.4e7dc82d-b968-4298-98c5-9c1259e6b92b@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <hHxmR8R6koERZiUvvnV9ZATSMe0Jdk21Z6-dxNRIzxY=.4e7dc82d-b968-4298-98c5-9c1259e6b92b@github.com>
Message-ID: <eiMe_NQaMRfrwuGSu_sWgqjkODmTbuYAm2EhV1OAWnE=.81d70350-6545-4c77-bfc8-f8bd9ae3733e@github.com>

On Tue, 16 Jan 2024 16:42:37 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> ECDHKeyAgreement should validate the parameters before assigning them to the fields.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more check on generateSecret

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17373#pullrequestreview-1824616052


From henryjen at openjdk.org  Tue Jan 16 19:05:44 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 16 Jan 2024 19:05:44 GMT
Subject: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1 [v2]
In-Reply-To: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
References: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
Message-ID: <v8-Lb3uuLFxIPVK7G_MZ0881_RY30FCXsCcnJhPQOQI=.29f8b19f-5e9a-4226-9762-249678dac06a@github.com>

> CPU24_01 fixes.

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

 - Merge branch 'openjdk:master' into cpu2401
 - 8317547: Enhance TLS connection support
   
   Reviewed-by: ahgross, rhalade, weijun, valeriep
 - 8314307: Improve loop handling
   
   Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
   Co-authored-by: Roland Westrelin <rwestrel at redhat.com>
   Co-authored-by: Emanuel Peter <epeter at openjdk.org>
   Reviewed-by: mschoene, rhalade, thartmann, epeter
 - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
   
   Reviewed-by: epeter
 - 8314468: Improve Compiler loops
   
   Co-authored-by: Dean Long <dlong at openjdk.org>
   Reviewed-by: rhalade, mschoene, iveresov, kvn
 - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
   
   Backport-of: 852276d1f833d49802693f2a5a82ba6eb2722de6
 - 8314295: Enhance verification of verifier
   
   Reviewed-by: mschoene, rhalade, dholmes, dlong
 - 8308204: Enhanced certificate processing
   
   Reviewed-by: mschoene, rhalade, jnimeh

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17448/files
  - new: https://git.openjdk.org/jdk/pull/17448/files/bf7bd9a1..e4e0d987

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

  Stats: 484 lines in 21 files changed: 304 ins; 157 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17448/head:pull/17448

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


From jjiang at openjdk.org  Tue Jan 16 22:58:02 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 16 Jan 2024 22:58:02 GMT
Subject: RFR: 8320449: ECDHKeyAgreement should validate parameters before
 using them [v4]
In-Reply-To: <eiMe_NQaMRfrwuGSu_sWgqjkODmTbuYAm2EhV1OAWnE=.81d70350-6545-4c77-bfc8-f8bd9ae3733e@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
 <hHxmR8R6koERZiUvvnV9ZATSMe0Jdk21Z6-dxNRIzxY=.4e7dc82d-b968-4298-98c5-9c1259e6b92b@github.com>
 <eiMe_NQaMRfrwuGSu_sWgqjkODmTbuYAm2EhV1OAWnE=.81d70350-6545-4c77-bfc8-f8bd9ae3733e@github.com>
Message-ID: <JZt_SXnRPPscXdPq-qpgZQ7tNNhHgPVSQidNjR8qIIY=.d68e1368-785d-41d3-a99d-c41f962112fb@github.com>

On Tue, 16 Jan 2024 18:44:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more check on generateSecret
>
> Marked as reviewed by mullan (Reviewer).

@seanjmullan 
Thanks for your approval!

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

PR Comment: https://git.openjdk.org/jdk/pull/17373#issuecomment-1894650783


From jjiang at openjdk.org  Tue Jan 16 22:58:05 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 16 Jan 2024 22:58:05 GMT
Subject: Integrated: 8320449: ECDHKeyAgreement should validate parameters
 before using them
In-Reply-To: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
References: <wmcF_wsunFzJnh8zE75OZo1PFwne_RRiisVbdIx3GnQ=.c8d980e4-59e3-4409-af35-96a16403a7a8@github.com>
Message-ID: <7rijPJN-VKq-iF6GHQVqyvxrtK03YbU-YMIQwQdeigY=.fe7dbecf-305b-4ffb-aa18-6958179a7f27@github.com>

On Thu, 11 Jan 2024 13:33:54 GMT, John Jiang <jjiang at openjdk.org> wrote:

> ECDHKeyAgreement should validate the parameters before assigning them to the fields.

This pull request has now been integrated.

Changeset: 43d2d68d
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43d2d68da5f60cc45c5f9d9572020743579dc76c
Stats:     146 lines in 2 files changed: 129 ins; 9 del; 8 mod

8320449: ECDHKeyAgreement should validate parameters before using them

Reviewed-by: mullan

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

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


From erikj at openjdk.org  Wed Jan 17 01:24:51 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 01:24:51 GMT
Subject: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1 [v2]
In-Reply-To: <v8-Lb3uuLFxIPVK7G_MZ0881_RY30FCXsCcnJhPQOQI=.29f8b19f-5e9a-4226-9762-249678dac06a@github.com>
References: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
 <v8-Lb3uuLFxIPVK7G_MZ0881_RY30FCXsCcnJhPQOQI=.29f8b19f-5e9a-4226-9762-249678dac06a@github.com>
Message-ID: <r0EbQezCIfQZkN9CaEpnq4_vChupoB5Ur0AW3mvGZWo=.3df93068-5d9e-4428-adfe-603b0806f357@github.com>

On Tue, 16 Jan 2024 19:05:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> CPU24_01 fixes.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into cpu2401
>  - 8317547: Enhance TLS connection support
>    
>    Reviewed-by: ahgross, rhalade, weijun, valeriep
>  - 8314307: Improve loop handling
>    
>    Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
>    Co-authored-by: Roland Westrelin <rwestrel at redhat.com>
>    Co-authored-by: Emanuel Peter <epeter at openjdk.org>
>    Reviewed-by: mschoene, rhalade, thartmann, epeter
>  - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
>    
>    Reviewed-by: epeter
>  - 8314468: Improve Compiler loops
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: rhalade, mschoene, iveresov, kvn
>  - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
>    
>    Backport-of: 852276d1f833d49802693f2a5a82ba6eb2722de6
>  - 8314295: Enhance verification of verifier
>    
>    Reviewed-by: mschoene, rhalade, dholmes, dlong
>  - 8308204: Enhanced certificate processing
>    
>    Reviewed-by: mschoene, rhalade, jnimeh

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17448#pullrequestreview-1826181933


From erikj at openjdk.org  Wed Jan 17 01:25:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 01:25:54 GMT
Subject: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b
In-Reply-To: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
References: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
Message-ID: <mzRza8OOWjcx6RzOh9TAlJtPpvmtl0w2Rnklnef1RxU=.c5625fe7-5cb6-43a0-a685-8055b8d27c69@github.com>

On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> CPU24_01 fixes.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/83#pullrequestreview-1826185706


From jnimeh at openjdk.org  Wed Jan 17 01:43:50 2024
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 17 Jan 2024 01:43:50 GMT
Subject: RFR: JDK-8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4,
 and increase overlap testing
In-Reply-To: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
References: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
Message-ID: <TLpDw5qhnQXDYdJAfRvNndXhAnO0a1BZ7whCSQ_OmgU=.668cd4ee-56ab-4ff0-8225-1c110f9c4782@github.com>

On Thu, 11 Jan 2024 03:26:03 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of a few simple test changes.  This fixes a failure with two manually run AES/GCM tests that depended on another test that changed with [JDK-8318756](https://bugs.openjdk.org/browse/JDK-8318756).  It also adds testing for overlapping buffers that AES/GCM has, but CC20P1305 needs after JDK-8318756 was included.
> 
> After the change, manual testing of GCMIncrementByte4 and GCMIncrementDirect4 were successfully and automated tests passed as well.
> 
> thanks
> 
> Tony

LGTM

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17362#pullrequestreview-1826243669


From henryjen at openjdk.org  Wed Jan 17 01:45:03 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 17 Jan 2024 01:45:03 GMT
Subject: Integrated: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1
In-Reply-To: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
References: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
Message-ID: <3HvjxNSJNsiVEgttXj91XvlqSDmGh_ZGJxcDh0qNzgo=.51d3fa63-788a-47db-ad1c-4db8b68aae1b@github.com>

On Tue, 16 Jan 2024 16:32:27 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> CPU24_01 fixes.

This pull request has now been integrated.

Changeset: 2063bb8f
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2063bb8ffabd6096f547ec6da979cfcf68a56ba3
Stats:     736 lines in 16 files changed: 476 ins; 65 del; 195 mod

Merge

Reviewed-by: erikj

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

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


From henryjen at openjdk.org  Wed Jan 17 01:45:28 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 17 Jan 2024 01:45:28 GMT
Subject: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b [v2]
In-Reply-To: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
References: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
Message-ID: <QPQKSvhJBUqBSv7cPBwOniB0MzpJvs3GgYfEqQQ_CJk=.9f42545c-26a7-4009-b0cf-f5f530f26532@github.com>

> CPU24_01 fixes.

Henry Jen 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.

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

Changes:
  - all: https://git.openjdk.org/jdk22/pull/83/files
  - new: https://git.openjdk.org/jdk22/pull/83/files/c7f1c973..c7f1c973

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

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

PR: https://git.openjdk.org/jdk22/pull/83


From henryjen at openjdk.org  Wed Jan 17 01:45:29 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 17 Jan 2024 01:45:29 GMT
Subject: [jdk22] Integrated: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b
In-Reply-To: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
References: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
Message-ID: <GQunM3ZjKmQcjUS8Qs5-khmA4iKShEB9khxkymhEDRM=.fc527ecf-e394-4e5e-9a7c-7646254371c1@github.com>

On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> CPU24_01 fixes.

This pull request has now been integrated.

Changeset: b2cc1890
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b2cc1890ff4d2e5404e153ecba5e83f1bcdd6fa7
Stats:     736 lines in 16 files changed: 476 ins; 65 del; 195 mod

Merge

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk22/pull/83


From rgiulietti at openjdk.org  Wed Jan 17 11:04:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 Jan 2024 11:04:54 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v15]
In-Reply-To: <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
Message-ID: <WnZ-Tk9FvlewohU_YuzvM9nKmJ15WvM5MMh6jPIrs6w=.bab71357-4b26-4d15-b147-bfed604139bd@github.com>

On Mon, 15 Jan 2024 14:17:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed useless event settings in test.

I plan to integrate the last commit by tomorrow, provided `security` folks do not disagree.

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

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1895579331


From duke at openjdk.org  Wed Jan 17 14:35:09 2024
From: duke at openjdk.org (duke)
Date: Wed, 17 Jan 2024 14:35:09 GMT
Subject: Withdrawn: 4936767: Parameters for MessageDigest
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <INfcptw_9frpARCyp7DoxwvLyniO8dOsgcLGiMNBR64=.d7288ae2-8432-4fea-bb32-a5f62e21225c@github.com>

On Tue, 14 Nov 2023 17:21:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add parameters to `MessageDigest` and introduce new `MessageDigest` algorithms 'SHAKE128-LEN` and `SHAKE256-LEN` with an integer parameter.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.org  Wed Jan 17 15:37:51 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Wed, 17 Jan 2024 15:37:51 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <EFwZRRMxWfvRO6U8tpMbO7xG_d11rIfdqdPONRSacFc=.4d8fef40-7865-490b-9fb9-a747c33c62c1@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <EFwZRRMxWfvRO6U8tpMbO7xG_d11rIfdqdPONRSacFc=.4d8fef40-7865-490b-9fb9-a747c33c62c1@github.com>
Message-ID: <uaFjfO1nDvmKhqZycJdToQLFuIE2StvDqVD8w3V-BkI=.660be6d3-a114-45f2-88ad-3d2b67cacf44@github.com>

On Tue, 19 Dec 2023 11:52:01 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> This is a very trivial change fixing rather annoying bug. Can someone review it and let it merge?

> @rebarbora-mckvak - what testing was done with an elevated user opening a keystore with (CERT_STORE_MAXIMUM_ALLOWED_FLAG) and then attempting write-operations on the keystore?

I have not tested any write operations yet. My use case has always been: administrators put private keys in the store and give a service (my java app) permissions to use it e.g. to sign data.

> Also, when a keystore is read-only. What happens when one tries to write into it? Ideally a `KeyStoreException` should be thrown with a clear and precise message.

I guess you get the same "Access denied" error now as before.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1896062532


From weijun at openjdk.org  Wed Jan 17 17:22:52 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 17 Jan 2024 17:22:52 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <UV8uCX2z2A7SjoaX4u_9_PXdBFc2Ib4nUkkQxDyKhdY=.5ab6d8ad-5079-4693-97b8-6ee2a48614b9@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

Oh, I re-read the bug report. It looks like a `KeyStoreException` was thrown. That's good.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1896258695


From rhalade at openjdk.org  Wed Jan 17 18:02:50 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 17 Jan 2024 18:02:50 GMT
Subject: RFR: 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails
 with "Alias <246810> does not exist" [v2]
In-Reply-To: <RvOTZabMQC0WAbF_f-L9m9-uckS5lrwgSVNc-tdBCp4=.8fc0ac15-6af2-47f7-af6f-7c46f562f7b1@github.com>
References: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
 <RvOTZabMQC0WAbF_f-L9m9-uckS5lrwgSVNc-tdBCp4=.8fc0ac15-6af2-47f7-af6f-7c46f562f7b1@github.com>
Message-ID: <3o7uTQpLhPVosmS2xxmW7ojN7mBg5vJrV-iFBqcLcXg=.3a6b314f-5dcd-470a-ab78-a68522f6aa60@github.com>

On Thu, 11 Jan 2024 18:15:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> I was unable to recreate the error but it looks like the problem could happen if two instances of the test are run on the same machine.  Also, if the deleteEntry() calls in the finally block throw an exception, they can hide any exceptions thrown earlier in the test.
>> 
>> I updated the test to use randomly generated alias names. I also updated the finally block so exceptions thrown by deleteEntry() are logged but not thrown.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into keytool-alias
>  - 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails with "Alias <246810> does not exist"

This LGTM with minor comment to update bound and update copyright year.

test/jdk/sun/security/mscapi/KeytoolChangeAlias.java line 40:

> 38:     public static void main(String[] args) throws Exception {
> 39:         SecureRandom random = new SecureRandom();
> 40:         String alias = Integer.toString(random.nextInt(1000, 9999));

Limit this bound to the power of 2 value - 8192 to avoid re-calculation?

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

PR Comment: https://git.openjdk.org/jdk/pull/17352#issuecomment-1896320620
PR Review Comment: https://git.openjdk.org/jdk/pull/17352#discussion_r1456212192


From ascarpino at openjdk.org  Wed Jan 17 18:11:58 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 17 Jan 2024 18:11:58 GMT
Subject: Integrated: JDK-8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, 
 and increase overlap testing
In-Reply-To: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
References: <gsO0BOwVAKDu-2Z-ldkbd7IQwcvDxv4XU-yGGhM_68Q=.e170203c-68c5-4c43-8b27-91e9240a86b5@github.com>
Message-ID: <GEb58q6m768d1f9WGGpFbxrp-CQzkwGsp0Y64ujvKO4=.a98b6e9b-6b4f-42c8-807a-24056e4f96ee@github.com>

On Thu, 11 Jan 2024 03:26:03 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of a few simple test changes.  This fixes a failure with two manually run AES/GCM tests that depended on another test that changed with [JDK-8318756](https://bugs.openjdk.org/browse/JDK-8318756).  It also adds testing for overlapping buffers that AES/GCM has, but CC20P1305 needs after JDK-8318756 was included.
> 
> After the change, manual testing of GCMIncrementByte4 and GCMIncrementDirect4 were successfully and automated tests passed as well.
> 
> thanks
> 
> Tony

This pull request has now been integrated.

Changeset: 51dbd36c
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51dbd36c74c70b1b17bd73cd2c3253593300b5f0
Stats:     127 lines in 4 files changed: 99 ins; 7 del; 21 mod

8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, and increase overlap testing

Reviewed-by: jnimeh

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

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


From mdonovan at openjdk.org  Wed Jan 17 19:54:14 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 17 Jan 2024 19:54:14 GMT
Subject: RFR: 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails
 with "Alias <246810> does not exist" [v3]
In-Reply-To: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
References: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
Message-ID: <08Q5lhFGtr0yaf2Vz_HQF2NOFpFr2K94iHk6nTgSCRc=.64b0855e-2758-4b2a-b38e-e474da4a28a8@github.com>

> I was unable to recreate the error but it looks like the problem could happen if two instances of the test are run on the same machine.  Also, if the deleteEntry() calls in the finally block throw an exception, they can hide any exceptions thrown earlier in the test.
> 
> I updated the test to use randomly generated alias names. I also updated the finally block so exceptions thrown by deleteEntry() are logged but not thrown.

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

  Changed bounds on random number and updated copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17352/files
  - new: https://git.openjdk.org/jdk/pull/17352/files/960b7921..c1709f66

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

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

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


From rhalade at openjdk.org  Wed Jan 17 19:54:14 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 17 Jan 2024 19:54:14 GMT
Subject: RFR: 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails
 with "Alias <246810> does not exist" [v3]
In-Reply-To: <08Q5lhFGtr0yaf2Vz_HQF2NOFpFr2K94iHk6nTgSCRc=.64b0855e-2758-4b2a-b38e-e474da4a28a8@github.com>
References: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
 <08Q5lhFGtr0yaf2Vz_HQF2NOFpFr2K94iHk6nTgSCRc=.64b0855e-2758-4b2a-b38e-e474da4a28a8@github.com>
Message-ID: <ArGrBU226QAsnD6s8JR5QYxF16mZJ1mQV7Y-5v3dLeE=.8d2cf6be-6e1c-41c4-b599-57decfe31b69@github.com>

On Wed, 17 Jan 2024 19:51:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> I was unable to recreate the error but it looks like the problem could happen if two instances of the test are run on the same machine.  Also, if the deleteEntry() calls in the finally block throw an exception, they can hide any exceptions thrown earlier in the test.
>> 
>> I updated the test to use randomly generated alias names. I also updated the finally block so exceptions thrown by deleteEntry() are logged but not thrown.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed bounds on random number and updated copyright year.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17352#pullrequestreview-1828066739


From weijun at openjdk.org  Thu Jan 18 15:36:16 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 Jan 2024 15:36:16 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v3]
In-Reply-To: <q_IKeY2OK1xusisFIogpsEtrc8q5WRp26jZB2qvYcj0=.f87ab6dc-6d0e-4b4b-b0f6-f85bf7e36929@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <q_IKeY2OK1xusisFIogpsEtrc8q5WRp26jZB2qvYcj0=.f87ab6dc-6d0e-4b4b-b0f6-f85bf7e36929@github.com>
Message-ID: <45IsrzamAYn0RgHr3ZNDJ6UnE9MJqCd6IfrHWaeCUes=.15d3c0c8-2e6a-4eb8-b708-f7e3e4b9e529@github.com>

On Thu, 11 Jan 2024 17:31:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
>> 
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
>> 
>> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
>> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
>> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
>> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error. Improve debugging. Change return value of distanceToCommonAncestor().

LGTM. Only 2 style comments for src and another for test.

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

> 494:             String debugMsg = null;
> 495:             if (debug != null) {
> 496:                 debug.println(METHOD_NME +" SAME NAMESPACE AS TRUSTED TEST...");

Add a space after `+`.

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

> 507:                 X500Name tSubjectName = X500Name.asX500Name(tSubject);
> 508:                 int d1 = distanceToCommonAncestor(tSubjectName, cIssuer1Name);
> 509:                 int d2 = distanceToCommonAncestor(tSubjectName, cIssuer2Name);

The logic below is correct. Somehow I think it will be clearer if you print out the debug lines before all the checks. Something like:

if (debug != null) {
    if (d1 != -1) debug.println(...);
    if (d2 != -1) debug.println(...);
}

test/jdk/sun/security/provider/certpath/PKIXCertComparator/Order.java line 58:

> 56:         kpg.initialize(2048);
> 57: 
> 58:         // Create top-level root CA cert with KIDs (Subject and Auth KeyIds)

Should a root CA have AKID?

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17248#pullrequestreview-1829925340
PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1457589230
PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1457598419
PR Review Comment: https://git.openjdk.org/jdk/pull/17248#discussion_r1457613256


From rgiulietti at openjdk.org  Thu Jan 18 17:08:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 18 Jan 2024 17:08:31 GMT
Subject: Integrated: 8275338: Add JFR events for notable serialization
 situations
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <sKOsowugtOYQoOduf9GAqPMgFWQBjQy0ULOumxTf8w0=.dd27b105-05f4-4ba1-82a2-bd4e33679781@github.com>

On Fri, 15 Dec 2023 17:34:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adds serialization misdeclaration events to JFR.

This pull request has now been integrated.

Changeset: bfd2afe5
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfd2afe5adc315928fdedbfbe73049d8774400de
Stats:     781 lines in 10 files changed: 781 ins; 0 del; 0 mod

8275338: Add JFR events for notable serialization situations

Reviewed-by: rriggs, egahlin

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

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


From mdonovan at openjdk.org  Thu Jan 18 17:36:21 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 18 Jan 2024 17:36:21 GMT
Subject: Integrated: 8321925: sun/security/mscapi/KeytoolChangeAlias.java fails
 with "Alias <246810> does not exist"
In-Reply-To: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
References: <3tRjnZGbEIqdBqLPXaBx3sqJ8b0CMtUtyJpsEjVQuOw=.e90771b4-f8a3-40cc-93d1-c0ac06b06f88@github.com>
Message-ID: <8FVBxIeEUMO1N9ybUjXIc5efZGc4_IzkGUWkfzUTtp0=.ff7564a4-3d16-48eb-9cd4-a7043b2e4189@github.com>

On Wed, 10 Jan 2024 20:14:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> I was unable to recreate the error but it looks like the problem could happen if two instances of the test are run on the same machine.  Also, if the deleteEntry() calls in the finally block throw an exception, they can hide any exceptions thrown earlier in the test.
> 
> I updated the test to use randomly generated alias names. I also updated the finally block so exceptions thrown by deleteEntry() are logged but not thrown.

This pull request has now been integrated.

Changeset: b6233c3d
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6233c3de773fb57b23704f1fec05d8b2d9c11c0
Stats:     23 lines in 1 file changed: 13 ins; 0 del; 10 mod

8321925: sun/security/mscapi/KeytoolChangeAlias.java fails with "Alias <246810> does not exist"

Reviewed-by: rhalade

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

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


From ascarpino at openjdk.org  Thu Jan 18 19:17:23 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 18 Jan 2024 19:17:23 GMT
Subject: [jdk22] RFR: JDK-8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, 
 and increase overlap testing
Message-ID: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>

This is the straight backport to 22 of https://github.com/openjdk/jdk/pull/17362

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

Commit messages:
 - Backport 51dbd36c74c70b1b17bd73cd2c3253593300b5f0

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

PR: https://git.openjdk.org/jdk22/pull/93


From ascarpino at openjdk.org  Thu Jan 18 21:37:26 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 18 Jan 2024 21:37:26 GMT
Subject: [jdk22] RFR: 8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, 
 and increase overlap testing
In-Reply-To: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>
References: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>
Message-ID: <rl1EG-cH8LJ487vSa84pVfysatoK2f2QdNThgyA0iL8=.6721cb74-b9a3-483d-b28c-520039d89422@github.com>

On Thu, 18 Jan 2024 19:11:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> This is the straight backport to 22 of https://github.com/openjdk/jdk/pull/17362

All tests pass

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

PR Comment: https://git.openjdk.org/jdk22/pull/93#issuecomment-1899229307


From jnimeh at openjdk.org  Thu Jan 18 22:00:03 2024
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 18 Jan 2024 22:00:03 GMT
Subject: [jdk22] RFR: 8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, 
 and increase overlap testing
In-Reply-To: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>
References: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>
Message-ID: <heL1SynG_Z77jcSqZDvzoE2APqU-KWFhqT3XDzHAZss=.c712a508-08ac-4650-aee4-5f89fcd28492@github.com>

On Thu, 18 Jan 2024 19:11:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> This is the straight backport to 22 of https://github.com/openjdk/jdk/pull/17362

LGTM

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/93#pullrequestreview-1830622552


From ascarpino at openjdk.org  Thu Jan 18 22:10:37 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 18 Jan 2024 22:10:37 GMT
Subject: [jdk22] Integrated: 8322100: Fix GCMIncrementByte4 &
 GCMIncrementDirect4, and increase overlap testing
In-Reply-To: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>
References: <6X3El88KyWEpFkEuIOHexN8hvon4Px2HBPHpgM9eG1Y=.5bbc7a5c-9b2d-4ac5-a8b9-15073435c060@github.com>
Message-ID: <qHcI5uC8PNB3oMQR-BbDGw1a5DFcgvNSrf62uXAQtUs=.4532baee-432e-4d55-bcf9-876ff37ac920@github.com>

On Thu, 18 Jan 2024 19:11:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> This is the straight backport to 22 of https://github.com/openjdk/jdk/pull/17362

This pull request has now been integrated.

Changeset: 5a77c290
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/5a77c290328310b3c720f101b35ff7baf338a9a5
Stats:     127 lines in 4 files changed: 99 ins; 7 del; 21 mod

8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, and increase overlap testing

Reviewed-by: jnimeh
Backport-of: 51dbd36c74c70b1b17bd73cd2c3253593300b5f0

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

PR: https://git.openjdk.org/jdk22/pull/93


From jwaters at openjdk.org  Fri Jan 19 01:40:29 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 19 Jan 2024 01:40:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v7]
In-Reply-To: <cVSiEqXAnXckvyoKYdoYEV8rutMVxQ8JrqXCLyoEVcs=.e107fc77-8a33-4142-bbf7-44663d4c6e32@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
 <cVSiEqXAnXckvyoKYdoYEV8rutMVxQ8JrqXCLyoEVcs=.e107fc77-8a33-4142-bbf7-44663d4c6e32@github.com>
Message-ID: <IysQ3O2oubZ6UU3x6shRzY32p8IIFIyX3ybDSWnDPXI=.1460172e-a607-493b-8d84-ccd9f18df02f@github.com>

On Tue, 16 Jan 2024 17:36:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the remaining case in sspi.cpp
>
> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 422:
> 
>> 420:     gss_name_struct* name = new gss_name_struct;
>> 421:     if (name == nullptr) {
>> 422:         goto err;
> 
> Go back? This looks more evil to me. Can we just `delete` and `return` here?

I left it in there since it seemed inconsistent to have one site return while the rest used goto, I can replace it if needed

> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 543:
> 
>> 541:         delete[] fullname;
>> 542:     }
>> 543:     goto finish;
> 
> Instead of `goto finish`, can we `return` here?

Will do, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1458178608
PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1458178889


From jwaters at openjdk.org  Fri Jan 19 01:44:29 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 19 Jan 2024 01:44:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v7]
In-Reply-To: <cVSiEqXAnXckvyoKYdoYEV8rutMVxQ8JrqXCLyoEVcs=.e107fc77-8a33-4142-bbf7-44663d4c6e32@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
 <cVSiEqXAnXckvyoKYdoYEV8rutMVxQ8JrqXCLyoEVcs=.e107fc77-8a33-4142-bbf7-44663d4c6e32@github.com>
Message-ID: <SeX600MrHruDidSbf6KO60qHl8QwfEAhg1UvorH7Qjo=.ce28545f-4b5a-4742-9aa6-fb0536494c62@github.com>

On Tue, 16 Jan 2024 17:42:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the remaining case in sspi.cpp
>
> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 580:
> 
>> 578:     exported_name->value = buffer;
>> 579:     result = GSS_S_COMPLETE;
>> 580:     goto cleanup;
> 
> Can we duplicate `delete[] fullname` and `return` here?

Will do

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1458180971


From jwaters at openjdk.org  Fri Jan 19 01:53:22 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 19 Jan 2024 01:53:22 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v8]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <ATcFI-8x1GcYY-rpnTieq7idHCi9kYT7Ezj5WeN8Ym8=.402d53bd-70e6-4965-955c-03cfae79a027@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

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

  Address review comments in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/926bc9aa..f7bb7fb0

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

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

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


From jwaters at openjdk.org  Fri Jan 19 01:57:40 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 19 Jan 2024 01:57:40 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

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

  std:: qualifier sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/f7bb7fb0..c0084f23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=07-08

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

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


From weijun at openjdk.org  Fri Jan 19 17:34:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 19 Jan 2024 17:34:28 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
Message-ID: <98uCEb4fjJ49VMJhaYqmYQXkp8sQ2oe4EIMKghNCOKQ=.536d8281-0903-4abc-863b-05fb79ea40ce@github.com>

On Fri, 19 Jan 2024 01:57:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   std:: qualifier sspi.cpp

The code change looks better. Can you show me where I can add this compiler switch so that I can try it myself a little?

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1900813532


From jwaters at openjdk.org  Fri Jan 19 18:39:29 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 19 Jan 2024 18:39:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <98uCEb4fjJ49VMJhaYqmYQXkp8sQ2oe4EIMKghNCOKQ=.536d8281-0903-4abc-863b-05fb79ea40ce@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
 <98uCEb4fjJ49VMJhaYqmYQXkp8sQ2oe4EIMKghNCOKQ=.536d8281-0903-4abc-863b-05fb79ea40ce@github.com>
Message-ID: <9As7Z0EZVWp5RrlO5CauhmwSuChavPUd0VWeoRyy4uo=.159d11e9-5b03-4929-9fd5-2d8e925729e8@github.com>

On Fri, 19 Jan 2024 17:31:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The code change looks better. Can you show me where I can add this compiler switch so that I can try it myself a little?

Hm? I'm not too sure what compiler switch you are referring to

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1900915581


From weijun at openjdk.org  Fri Jan 19 18:46:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 19 Jan 2024 18:46:28 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
Message-ID: <I9caZ5zJi7mWdJqCmzol1E_gG50ZeQ6OPtiNyg9N_CI=.3fc2665b-fe44-4ef6-aa6b-599a76c89be0@github.com>

On Fri, 19 Jan 2024 01:57:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   std:: qualifier sspi.cpp

The permissive- option you mentioned in the previous PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1900924704


From weijun at openjdk.org  Fri Jan 19 18:46:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 19 Jan 2024 18:46:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v7]
In-Reply-To: <IysQ3O2oubZ6UU3x6shRzY32p8IIFIyX3ybDSWnDPXI=.1460172e-a607-493b-8d84-ccd9f18df02f@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <3Aub95XASa7knFZiHP9aQOpCJwyIBatzC_8OQwvor6c=.27e7323c-e205-435c-8c56-fb975397697a@github.com>
 <cVSiEqXAnXckvyoKYdoYEV8rutMVxQ8JrqXCLyoEVcs=.e107fc77-8a33-4142-bbf7-44663d4c6e32@github.com>
 <IysQ3O2oubZ6UU3x6shRzY32p8IIFIyX3ybDSWnDPXI=.1460172e-a607-493b-8d84-ccd9f18df02f@github.com>
Message-ID: <OdLhgZjL6LU8DmbaaCRHp6eQMx0qg7O45reUwhqZefQ=.94e09e05-aa6e-4c76-81b6-26c348836e69@github.com>

On Fri, 19 Jan 2024 01:37:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 422:
>> 
>>> 420:     gss_name_struct* name = new gss_name_struct;
>>> 421:     if (name == nullptr) {
>>> 422:         goto err;
>> 
>> Go back? This looks more evil to me. Can we just `delete` and `return` here?
>
> I left it in there since it seemed inconsistent to have one site return while the rest used goto, I can replace it if needed

My understanding is that this is already after the `execution` label so it's a different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16682#discussion_r1459391349


From djelinski at openjdk.org  Fri Jan 19 19:45:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Jan 2024 19:45:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
Message-ID: <4NtXVfOQeTvxkT0M9bzHyNhPD9UkxWygfXb99BIAh-M=.5bf0cbf8-f598-49b8-b8b7-923136d71ffe@github.com>

On Fri, 19 Jan 2024 01:57:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   std:: qualifier sspi.cpp

AFAICT these changes are not necessary.

### C++11 ?6.7/3:

> [...] A program that jumps from a point where a variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed **unless the variable has scalar type**, class type with a trivial default constructor and a trivial destructor, a cv-qualified version of one of these types, or an array of one of the preceding types and is declared without an initializer (8.5).

all the variables jumped over are scalars (ints and pointers), so the code is correct. Am I missing something?

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

PR Review: https://git.openjdk.org/jdk/pull/16682#pullrequestreview-1833557310


From jwaters at openjdk.org  Sun Jan 21 07:22:27 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 21 Jan 2024 07:22:27 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <I9caZ5zJi7mWdJqCmzol1E_gG50ZeQ6OPtiNyg9N_CI=.3fc2665b-fe44-4ef6-aa6b-599a76c89be0@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
 <I9caZ5zJi7mWdJqCmzol1E_gG50ZeQ6OPtiNyg9N_CI=.3fc2665b-fe44-4ef6-aa6b-599a76c89be0@github.com>
Message-ID: <tTRaZe-xQ2-rMa5dUfbdtE5W9J4jZShIzICkXPzOWf4=.d98447a7-925d-400e-846c-68fdd2388e05@github.com>

On Fri, 19 Jan 2024 18:43:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The permissive- option you mentioned in the previous PR.

Ah, it goes here: 

> The permissive- option you mentioned in the previous PR.

Ah, alright. That goes here: https://github.com/openjdk/jdk/blob/cbfbaee6eb8d8303a10128cb23ea5021cb83850c/make/autoconf/flags-cflags.m4#L566

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1902539550


From jwaters at openjdk.org  Sun Jan 21 07:26:26 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 21 Jan 2024 07:26:26 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <4NtXVfOQeTvxkT0M9bzHyNhPD9UkxWygfXb99BIAh-M=.5bf0cbf8-f598-49b8-b8b7-923136d71ffe@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
 <4NtXVfOQeTvxkT0M9bzHyNhPD9UkxWygfXb99BIAh-M=.5bf0cbf8-f598-49b8-b8b7-923136d71ffe@github.com>
Message-ID: <IFZeh00exQgs2W2rP-ghzGacng9whAPi20Lg-Qh2nug=.c891e5f9-f547-4dab-bd87-9d90b38442d2@github.com>

On Fri, 19 Jan 2024 19:42:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> AFAICT these changes are not necessary.
> 
> ### C++11 ?6.7/3:
> > [...] A program that jumps from a point where a variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed **unless the variable has scalar type**, class type with a trivial default constructor and a trivial destructor, a cv-qualified version of one of these types, or an array of one of the preceding types and is declared without an initializer (8.5).
> 
> all the variables jumped over are scalars (ints and pointers), so the code is correct. Am I missing something?

The previous fix was a bit too hacky for my liking, so I decided to rework it by fixing the order in which the labels are defined instead. Additionally, it's way too easy for the previous fix to be undone by newer commits, since it isn't obvious at all why it was done (Also motivated by Phil's rejection of the same fix within awt)

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1902540303


From djelinski at openjdk.org  Mon Jan 22 14:43:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 22 Jan 2024 14:43:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <IFZeh00exQgs2W2rP-ghzGacng9whAPi20Lg-Qh2nug=.c891e5f9-f547-4dab-bd87-9d90b38442d2@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
 <4NtXVfOQeTvxkT0M9bzHyNhPD9UkxWygfXb99BIAh-M=.5bf0cbf8-f598-49b8-b8b7-923136d71ffe@github.com>
 <IFZeh00exQgs2W2rP-ghzGacng9whAPi20Lg-Qh2nug=.c891e5f9-f547-4dab-bd87-9d90b38442d2@github.com>
Message-ID: <8j47w7VgAUtRLSGHkoACAZFIWLs1uplTW_KmRnfFV8k=.afeb4f47-ee16-4fac-b6d0-aeb8d2711f51@github.com>

On Sun, 21 Jan 2024 07:23:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The previous fix was a bit too hacky for my liking, so I decided to rework it by fixing the order in which the labels are defined instead.

Please don't. #15996 was needed to keep the compiler happy, this one is not needed. Exiting a method with `goto` method and a single label at the end of the method is a popular C idiom, but adding more `goto`s and labels is just asking for trouble. If you're looking for a pure C++ solution to this problem, check out RAII / `unique_ptr`.

Note that I'm not advocating for using RAII here. The current code works and does not use any unsupported language features. If it ain't broke, don't fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1904145590


From weijun at openjdk.org  Mon Jan 22 14:55:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 22 Jan 2024 14:55:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
Message-ID: <CWQBmRiSQZiK3lMP4B-MU6m4-H9vC6l0mLcGD4kCmnk=.887e2882-609c-4708-8fbc-205ec94d5786@github.com>

On Fri, 19 Jan 2024 01:57:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   std:: qualifier sspi.cpp

I re-read the new fix. The way you move the error block works because in some cases it *happens* that the jump does not go across a variable declaration. When it does not work you either have to jump backwards or duplicate codes. This is not worth doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1904170781


From goetz at openjdk.org  Tue Jan 23 10:28:43 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 23 Jan 2024 10:28:43 GMT
Subject: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
Message-ID: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>

I backport this to fix this issue in 22. We see it failing there in our CI.

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

Commit messages:
 - Backport c2e77e2f17b624e750dea8fd51bbfde99596690e

Changes: https://git.openjdk.org/jdk22/pull/95/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=95&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319128
  Stats: 45 lines in 6 files changed: 36 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk22/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/95/head:pull/95

PR: https://git.openjdk.org/jdk22/pull/95


From macarte at openjdk.org  Wed Jan 24 00:43:27 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 24 Jan 2024 00:43:27 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <2TJXIkiCq7uhYixL4X2_Kqz0xbrcy0fcpkrUiyhA2vo=.cfaf77ea-66db-4b0c-b48b-881c56c9433c@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

Please enable github actions so that minimal tier1 jtreg tests are run; as you're changing the behavior of KeyStore.load (for SunMSCAPI) you should really test that all available write operations fail as expected (as they did before this change).

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1907154840


From goetz at openjdk.org  Wed Jan 24 11:58:36 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 24 Jan 2024 11:58:36 GMT
Subject: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9
 aarch64
In-Reply-To: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
References: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
Message-ID: <Mu587jxeT7O7jEgU685cs-rFXK0Jg8f9OxJhwSGyEuc=.4b90636b-7cb2-44dc-b329-46f576752da3@github.com>

On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this to fix this issue in 22. We see it failing there in our CI.

Passed SAP nighlyt testing with jdk22 and jdk22u.

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

PR Comment: https://git.openjdk.org/jdk22/pull/95#issuecomment-1907981934


From lucy at openjdk.org  Wed Jan 24 13:18:32 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 24 Jan 2024 13:18:32 GMT
Subject: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9
 aarch64
In-Reply-To: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
References: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
Message-ID: <jREYbwB-y3Qr58VewMrdnThVuAn3PvuaK9qQtz4ZJDg=.42c5a9a9-e9cb-4d30-a082-7f2fe347b954@github.com>

On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this to fix this issue in 22. We see it failing there in our CI.

Looks good.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/95#pullrequestreview-1841351221


From ogillespie at openjdk.org  Wed Jan 24 15:31:41 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 24 Jan 2024 15:31:41 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor
Message-ID: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>

Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).

Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).


Before
SecureRandomBench.newSecureRandom  avgt   2930 +- 50  ns/op

After
SecureRandomBench.newSecureRandom  avgt   15  2400 +- 33  ns/op


I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.

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

Commit messages:
 - 8324646 - Avoid Class.forName in SecureRandom constructor

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

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


From ogillespie at openjdk.org  Wed Jan 24 15:46:48 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 24 Jan 2024 15:46:48 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating NativePRNG
Message-ID: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>

A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.

Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 

The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).


Before

SecureRandomBench.newSecureRandom  avgt  2930 +- 50 ns/op

After

SecureRandomBench.newSecureRandom  avgt  510 +- 16 ns/op

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

Commit messages:
 - 8324648: Avoid NoSuchMethodError when instantiating NativePRNG

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

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


From weijun at openjdk.org  Wed Jan 24 16:01:38 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 24 Jan 2024 16:01:38 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
Message-ID: <TnaOGOW7UpBLBpPgVw5eE7MRhR_XHXhWRGeJS6s3Txk=.210403b0-a246-42d3-9be5-238cfa2627c0@github.com>

On Thu, 4 Jan 2024 02:24:56 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add KeychainStore-ROOT keystore for root certificates

src/java.base/macosx/classes/apple/security/AppleProvider.java line 89:

> 87:                            "KeychainStore", "apple.security.KeychainStore.USER"));
> 88:                 putService(new ProviderService(p, "KeyStore",
> 89:                            "KeychainStore-ROOT", "apple.security.KeychainStore.ROOT"));

I think the correct class names should be `KeychainStore$USER` and `KeychainStore$ROOT`, although they might be used.

src/java.base/macosx/classes/apple/security/KeychainStore.java line 45:

> 43: 
> 44: /**
> 45:  * This class provides the keystores implementation referred to as

Or maybe "keystore implementations"? If yes, then use "They use ... their...".

src/java.base/macosx/classes/apple/security/KeychainStore.java line 52:

> 50:  */
> 51: 
> 52: abstract class KeychainStore extends KeyStoreSpi {

Make it `abstract sealed`.

src/java.base/macosx/classes/apple/security/KeychainStore.java line 216:

> 214:      */
> 215:     private String getName()
> 216:     {

Put the closing brace to the previous line. Actually, probably not worth creating a new method.

src/java.base/macosx/classes/apple/security/KeychainStore.java line 546:

> 544: 
> 545:         synchronized(entries) {
> 546: 

Useless.

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 478:

> 476:                 // Load user trustSettings into inputTrust
> 477:                 if (SecTrustSettingsCopyTrustSettings(certRef, domain, &trustSettings) == errSecSuccess && trustSettings != NULL) {
> 478:                     if(inputTrust == NULL) {

Add a space after `if`.

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 544:

> 542: 
> 543:     // Read Trust Anchors
> 544:     if(SecTrustCopyAnchorCertificates(&currAnchors) == errSecSuccess) {

Add a space after `if`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465113070
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465114949
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465124742
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465130743
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465132076
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465140314
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1465150456


From weijun at openjdk.org  Wed Jan 24 16:06:31 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 24 Jan 2024 16:06:31 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <o9COMRXoME8Uzzvfu1nVbcF7lxPrP5Rxcm9iFDbzDBg=.cae10151-f3f1-43d5-98c9-4fb8b63fd0f3@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
 <_9uUrJ2VVhS3c-iSiFTxQ40zORA0QSHCabZfsZ-oAA4=.813cf332-31b6-4cf1-bf8d-ee7460cdb2d0@github.com>
 <o9COMRXoME8Uzzvfu1nVbcF7lxPrP5Rxcm9iFDbzDBg=.cae10151-f3f1-43d5-98c9-4fb8b63fd0f3@github.com>
Message-ID: <YR88fP83DjMcH6w1S1CsKL79-HvAHhbhZimdQFhbhXY=.aad7c305-9f72-4735-bcc0-92345727baef@github.com>

On Thu, 4 Jan 2024 17:14:18 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> > What are the change for existing `addCertificatesToKeystore` for? Is there any behavior change?
> 
> Hi @wangweij . No behavior changes. Just reformatted to make it similar to addCertificatesToKeystoreRoot. Can be reverted back.

Looks so. However, [kSecTrustSettingsDomainUser](https://developer.apple.com/documentation/security/sectrustsettingsdomain/ksectrustsettingsdomainuser) is explicitly set to 0 but [kSecTrustSettingsDomainAdmin](https://developer.apple.com/documentation/security/sectrustsettingsdomain/ksectrustsettingsdomainadmin) has not. This makes me a little uncomfortable.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1908432999


From weijun at openjdk.org  Wed Jan 24 16:06:33 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 24 Jan 2024 16:06:33 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
Message-ID: <pChwGmRSsDPsDlu7kcawK6RNKt5NO3ZZ8l_m1qpmxlo=.3c5d8572-c16a-4ab5-ae66-c2800e95ad60@github.com>

On Thu, 4 Jan 2024 02:24:56 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add KeychainStore-ROOT keystore for root certificates

Is it possible to reuse some some lines from `addCertificatesToKeystore`?

BTW, I reviewed the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1908435278


From mbalao at openjdk.org  Wed Jan 24 16:27:51 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 24 Jan 2024 16:27:51 GMT
Subject: RFR: 8315487: Security Providers Filter [v4]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <5s_qXFCYd69YbixEMMwRJAWLlKFb0cbQkqKYn0R5hUQ=.b6fa8fda-323d-4377-8fa4-966be409c6cb@github.com>

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

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

 - More clear text in invalid pattern exception.
 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/ea186c25..a7b27c35

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

  Stats: 181690 lines in 3489 files changed: 100495 ins; 67363 del; 13832 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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


From mbalao at openjdk.org  Wed Jan 24 16:39:46 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 24 Jan 2024 16:39:46 GMT
Subject: RFR: 8315487: Security Providers Filter [v5]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <PcUwNyScfOlfpACImcwNIZQEYx7Fl7ig2VslyIXnGpg=.00298f7c-a413-41ee-aeda-2ca3f76a904d@github.com>

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

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

  Copyright dates update.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/a7b27c35..35516004

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

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

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


From shade at openjdk.org  Wed Jan 24 17:50:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 17:50:31 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor
In-Reply-To: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
Message-ID: <dUdI7kEO5fXS4EL4H9hOf6UDZ-mbbBLV46v4Qma-klM=.87b745e2-7e5b-4f13-9aca-0edf670a8051@github.com>

On Wed, 24 Jan 2024 15:25:28 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
> 
> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
> 
> 
> Before
> newSecureRandom  avgt  2930 ? 50  ns/op
> 
> After
> newSecureRandom  avgt  2400 ? 33  ns/op
> 
> 
> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.

This looks promising to me! But we need to polish this a bit:

src/java.base/share/classes/java/security/Provider.java line 1560:

> 1558:         final boolean supportsParameter;
> 1559:         final String constructorParameterClassName;
> 1560:         private volatile Class<?> constructorParameterClass;

Style: no need for `private` here, match what other fields are doing.

src/java.base/share/classes/java/security/Provider.java line 1568:

> 1566:         }
> 1567: 
> 1568:         Class<?> getConstructorParameterClass() throws ClassNotFoundException {

I think we want to do what `Service.getImplClass` is doing, for extra safety: retain cached class on a `WeakReference`. This would avoid accidental class leakage in this code.

src/java.base/share/classes/java/security/Provider.java line 1909:

> 1907:                 } else {
> 1908:                     ctrParamClz = cap.constructorParameterClassName == null?
> 1909:                         null : cap.getConstructorParameterClass();

Maybe we should move the ternary for `cap.constructorParameterClassName == null` into new method to begin with.

test/micro/org/openjdk/bench/java/security/SecureRandomBench.java line 1:

> 1: package org.openjdk.bench.java.security;

No copyright header?

test/micro/org/openjdk/bench/java/security/SecureRandomBench.java line 16:

> 14: 
> 15:     @Benchmark
> 16:     public SecureRandom newSecureRandom() throws Exception {

Just "create()", I think. No need to repeat it with `SecureRandomBench.newSecureRandom`.

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

PR Review: https://git.openjdk.org/jdk/pull/17559#pullrequestreview-1842025562
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465331538
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465330794
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465332784
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465332949
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465334379


From ogillespie at openjdk.org  Wed Jan 24 18:05:54 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 24 Jan 2024 18:05:54 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <dUdI7kEO5fXS4EL4H9hOf6UDZ-mbbBLV46v4Qma-klM=.87b745e2-7e5b-4f13-9aca-0edf670a8051@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <dUdI7kEO5fXS4EL4H9hOf6UDZ-mbbBLV46v4Qma-klM=.87b745e2-7e5b-4f13-9aca-0edf670a8051@github.com>
Message-ID: <fDtKv237-omANHhTm_XE8_bldBtvarFt9dOxi-xmFF8=.e8315210-6b02-4be3-9b58-0a953ee5732d@github.com>

On Wed, 24 Jan 2024 17:45:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Rename newSecureRandom -> create
>>  - Add copyright header to new file
>
> src/java.base/share/classes/java/security/Provider.java line 1560:
> 
>> 1558:         final boolean supportsParameter;
>> 1559:         final String constructorParameterClassName;
>> 1560:         private volatile Class<?> constructorParameterClass;
> 
> Style: no need for `private` here, match what other fields are doing.

I don't disagree in principle but it was like this before the revert, and is still like this in 17.

> src/java.base/share/classes/java/security/Provider.java line 1568:
> 
>> 1566:         }
>> 1567: 
>> 1568:         Class<?> getConstructorParameterClass() throws ClassNotFoundException {
> 
> I think we want to do what `Service.getImplClass` is doing, for extra safety: retain cached class on a `WeakReference`. This would avoid accidental class leakage in this code.

Thanks. I reverted it exactly from JDK-8280970 because a) that particular code was there for a long time and presumably was reasonably well used/tested without big issues and b) I want to backport the optimization to JDK17 which still has this exact implementation.

Aside: The classes saved here are limited to the 31 explicitly added in `Provider.<clinit>`. I'm not sure if that helps limit the leak potential significantly?

> src/java.base/share/classes/java/security/Provider.java line 1909:
> 
>> 1907:                 } else {
>> 1908:                     ctrParamClz = cap.constructorParameterClassName == null?
>> 1909:                         null : cap.getConstructorParameterClass();
> 
> Maybe we should move the ternary for `cap.constructorParameterClassName == null` into new method to begin with.

Thanks. Similar reasoning as above. If we decide to diverge from the original implementation then I'll update this too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465346119
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465346269
PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465347099


From ogillespie at openjdk.org  Wed Jan 24 18:05:50 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 24 Jan 2024 18:05:50 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
Message-ID: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>

> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
> 
> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
> 
> 
> Before
> newSecureRandom  avgt  2930 ? 50  ns/op
> 
> After
> newSecureRandom  avgt  2400 ? 33  ns/op
> 
> 
> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.

Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:

 - Rename newSecureRandom -> create
 - Add copyright header to new file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17559/files
  - new: https://git.openjdk.org/jdk/pull/17559/files/93f0cc7f..8d8f2d0b

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

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

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


From shade at openjdk.org  Wed Jan 24 18:20:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 18:20:25 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <fDtKv237-omANHhTm_XE8_bldBtvarFt9dOxi-xmFF8=.e8315210-6b02-4be3-9b58-0a953ee5732d@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <dUdI7kEO5fXS4EL4H9hOf6UDZ-mbbBLV46v4Qma-klM=.87b745e2-7e5b-4f13-9aca-0edf670a8051@github.com>
 <fDtKv237-omANHhTm_XE8_bldBtvarFt9dOxi-xmFF8=.e8315210-6b02-4be3-9b58-0a953ee5732d@github.com>
Message-ID: <U1nQos8Us6X5-5Bvmh8okDvRI_fTrFU4wI5cE4LGchA=.1e01151d-37fa-4ba3-9911-7b063da8d6fc@github.com>

On Wed, 24 Jan 2024 17:57:46 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Aside: The classes saved here are limited to the 31 explicitly added in Provider.<clinit>. I'm not sure if that helps limit the leak potential significantly?

True. Might not even be an issue in practice.

I think the argument for keeping the code in pre-JDK-8280970 form is a good move for future backports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465367371


From weijun at openjdk.org  Wed Jan 24 18:43:33 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 24 Jan 2024 18:43:33 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v5]
In-Reply-To: <ufXMGY6TxVljbXBCDWEGpQU_md1ReWF9xnFATOzV0u4=.02cbf74d-5c22-49ab-b83b-ac96ae7c3268@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <ufXMGY6TxVljbXBCDWEGpQU_md1ReWF9xnFATOzV0u4=.02cbf74d-5c22-49ab-b83b-ac96ae7c3268@github.com>
Message-ID: <_idlvdVqL9v9ISDyeGEg348Knud4Y1B1-lA14VSOJEI=.28d14834-1133-4312-8e59-de852b24ab8e@github.com>

On Fri, 12 Jan 2024 00:17:32 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments for new functions

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 34:

> 32: import java.util.Arrays;
> 33: import java.util.List;
> 34: import java.util.ArrayList;

Useless imports for `List` and `ArrayList`.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 104:

> 102: 
> 103:         if (infoMap.put(oid, info) != null) {
> 104:             throw new RuntimeException("Duplicate oid: " + oid);

I usually use `AssertionError`. This is a JDK implementation error.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 126:

> 124:     /* Simplifies lambda expressions when setting AttributeInfo */
> 125:     private static DerOutputStream mkDerStream(DerOutputStream t, DerOutputStream r) {
> 126:         return t.write(DerValue.tag_Set, r.toByteArray());

I think there is no need to call `toByteArray`. Just use `r` itself.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 167:

> 165:             a -> Arrays.stream(a).map(Throws.unchecked(
> 166:                 e -> new SignerInfo(e.toDerInputStream()))).toArray(),
> 167:             (v,t) -> t.putOrderedSetOf(DerValue.tag_Set, (DerEncoder[]) v),

This is not single valued and the lambda should only take care of an element and not the set. Maybe should be `t.write((DerEncoder) v)`.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java line 309:

> 307:         boolean first = true;
> 308:         for (ObjectIdentifier oid : PKCS9Attribute.getOIDs()) {
> 309:             if (oid == null) continue;

This should not happen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1465170461
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1465175997
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1465312830
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1465308164
PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1465165815


From liach at openjdk.org  Wed Jan 24 19:53:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Jan 2024 19:53:25 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <YaSD8MErk4vKqsK79M5Hk-e66Cga02rc54kRbvqDKas=.9bc9c57a-7ad9-44cb-a1fa-7464bb70361a@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

I see that the existing caller code has a check for `ctorParamClass`. Why must we declare `SecureRandomParameters.class` as the `ctorParamClass` for these 3 randoms instead of using `null`?

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1908813648


From rriggs at openjdk.org  Wed Jan 24 20:13:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 Jan 2024 20:13:26 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <fDtKv237-omANHhTm_XE8_bldBtvarFt9dOxi-xmFF8=.e8315210-6b02-4be3-9b58-0a953ee5732d@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <dUdI7kEO5fXS4EL4H9hOf6UDZ-mbbBLV46v4Qma-klM=.87b745e2-7e5b-4f13-9aca-0edf670a8051@github.com>
 <fDtKv237-omANHhTm_XE8_bldBtvarFt9dOxi-xmFF8=.e8315210-6b02-4be3-9b58-0a953ee5732d@github.com>
Message-ID: <zha20KxW7kwFg2crgutQCn3d2dWpxHkicPV022_1q8M=.9fa06e6d-ad8b-4157-8710-19b6d4b7ad0d@github.com>

On Wed, 24 Jan 2024 17:57:38 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Provider.java line 1560:
>> 
>>> 1558:         final boolean supportsParameter;
>>> 1559:         final String constructorParameterClassName;
>>> 1560:         private volatile Class<?> constructorParameterClass;
>> 
>> Style: no need for `private` here, match what other fields are doing.
>
> I don't disagree in principle but it was like this before the revert, and is still like this in 17.

Is volatile really needed? And there is some performance penalty and in practice the value will be the same even if recomputed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1465483019


From anthony.scarpino at oracle.com  Wed Jan 24 21:23:46 2024
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 24 Jan 2024 13:23:46 -0800
Subject: PEM API github repo
Message-ID: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>

Hi,

The following github link is to the PEM API as it is written in the 
draft JEP (https://openjdk.org/jeps/8300911).  There has been a few 
changes since the original posting.

https://github.com/ascarpino/jdk/tree/pem

The Encoder and PEMEncoder to now return byte[] for the encode() method. 
  A new PEMEncoder method, encodeToString(), was added.  I believe these 
make it easier for outputting data to a file and InputStreams, while 
still supporting a method that returns a String.

For decode, InputStream has replaced Reader.  There were comments 
preferring InputStream and I found that Reader's buffering quirks were 
problematic. Decoding from a byte[] is easy through an ByteArrayInputStream.

If you are interested in testing out the API, please download and 
compile the repo.  Then let me know how your experience went.

thanks

Tony


From goetz at openjdk.org  Thu Jan 25 09:06:32 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Thu, 25 Jan 2024 09:06:32 GMT
Subject: [jdk22] Integrated: 8319128: sun/security/pkcs11 tests fail on OL 7.9
 aarch64
In-Reply-To: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
References: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
Message-ID: <cCr1ABcat9FVypdMEAYj79IsxCO3DCbUAXkfYXlZqbg=.9fc077bb-ec9f-4e1a-bcf1-1bc8a695f61b@github.com>

On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this to fix this issue in 22. We see it failing there in our CI.

This pull request has now been integrated.

Changeset: 57bc96e5
Author:    Goetz Lindenmaier <goetz at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/57bc96e5cdc6b30eb5c6a3aeece2341dccc75e97
Stats:     45 lines in 6 files changed: 36 ins; 4 del; 5 mod

8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

Reviewed-by: lucy
Backport-of: c2e77e2f17b624e750dea8fd51bbfde99596690e

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

PR: https://git.openjdk.org/jdk22/pull/95


From ogillespie at openjdk.org  Thu Jan 25 12:02:34 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 25 Jan 2024 12:02:34 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <zha20KxW7kwFg2crgutQCn3d2dWpxHkicPV022_1q8M=.9fa06e6d-ad8b-4157-8710-19b6d4b7ad0d@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <dUdI7kEO5fXS4EL4H9hOf6UDZ-mbbBLV46v4Qma-klM=.87b745e2-7e5b-4f13-9aca-0edf670a8051@github.com>
 <fDtKv237-omANHhTm_XE8_bldBtvarFt9dOxi-xmFF8=.e8315210-6b02-4be3-9b58-0a953ee5732d@github.com>
 <zha20KxW7kwFg2crgutQCn3d2dWpxHkicPV022_1q8M=.9fa06e6d-ad8b-4157-8710-19b6d4b7ad0d@github.com>
Message-ID: <WSnIu-5Ta1u7NHhY9kcMst3d1rJejgVGgEbGEmiiV1M=.01fb3948-4157-4776-8918-4fda7852724f@github.com>

On Wed, 24 Jan 2024 20:09:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I don't disagree in principle but it was like this before the revert, and is still like this in 17.
>
> Is volatile really needed? And there is some performance penalty and in practice the value will be the same even if recomputed.

Same thinking as above - this is how it was before, and how it is in 17. I'd rather not diverge, unless the reason is strong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17559#discussion_r1466266515


From ogillespie at openjdk.org  Thu Jan 25 12:13:36 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 25 Jan 2024 12:13:36 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <YaSD8MErk4vKqsK79M5Hk-e66Cga02rc54kRbvqDKas=.9bc9c57a-7ad9-44cb-a1fa-7464bb70361a@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <YaSD8MErk4vKqsK79M5Hk-e66Cga02rc54kRbvqDKas=.9bc9c57a-7ad9-44cb-a1fa-7464bb70361a@github.com>
Message-ID: <X3CpRw43jnQOFtEquDVoN4EYVuTmbyGcqCLi6-fIm-0=.2e47426e-7e10-40d4-ae4b-7395ff2cee29@github.com>

On Wed, 24 Jan 2024 19:50:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> I see that the existing caller code has a check for `ctorParamClass`. Why must we declare `SecureRandomParameters.class` as the `ctorParamClass` for these 3 randoms instead of using `null`?

>From [lookup code](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957):


// Looking for the constructor with a params first and fallback
// to one without if not found. This is to support the enhanced
// SecureRandom where both styles of constructors are supported.
// Before jdk9, there was no params support (only getInstance(alg))
// and an impl only had the params-less constructor. Since jdk9,
// there is getInstance(alg,params) and an impl can contain
// an Impl(params) constructor.


The `EngineDescription` is looked up by `type` which in this case is `SecureRandom`, there's no way right now to choose specific parameters for different implementers. Are you proposing that I extend the engine lookup to include algorithm, so we can have specific `EngineDescription` for `SecureRandom->NativePRNG`? I don't know this code well enough to know if that's feasible, but it definitely seems more complex.

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1910079405


From djelinski1 at gmail.com  Thu Jan 25 17:20:57 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Thu, 25 Jan 2024 18:20:57 +0100
Subject: PEM API github repo
In-Reply-To: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>
References: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>
Message-ID: <CAMrH03J=wX-1Kp+LVasv0-R-NEWBy31_dkb+v4CFNXoksJRfwQ@mail.gmail.com>

Hi Tony,
Thanks for the links! The API looks very promising.

Out of curiosity, why aren't you using the Base64 MIME
encoder/decoder? They are supposed to produce/remove the newline
characters.
The relationship between the byte[] and String data should be
specified. Base64 explicitly specifies that the String APIs are
translated to the byte[] APIs with ISO 8859-1 encoding. The PEMDecoder
is currently using the default charset, which might produce
interesting results if the charset is set to EBCDIC. The encoder is
using UTF-8, which is reasonable, but given that the produced output
will always be ASCII, ISO 8859-1 will perform better.
There's a disparity between the decoder and the encoder APIs; both
work with strings, but Decoder accepts InputStream and not arrays, and
Encoder produces byte arrays, but does not work with streams. This
should be more uniform. I like Decoder's InputStream support (that's
currently the only way to read multiple CA certificates from a single
file - the String overload currently only returns the first one), so
I'd add OutputStream support to Encoder for parity. Karl's earlier
suggestion to support Stream<SecurityObject> also makes a lot of
sense.
I'm not a big fan of the non-static factory methods
withEncryption/withDecryption/withFactory. The problem with non-static
methods that return an instance of the same type is that you need to
check the documentation to know if the method returns a new instance
or if it mutates the current one. Can we use static factory methods
instead? Either that, or create a builder class.
I don't like the PEMEncoder.withEncryption API. It's not predictable
enough; when encoding data, it's not consistent between writing
unencrypted data (certificate, crl), throwing (PublicKey,
EncryptedPrivateKeyInfo) and writing encrypted data (unencrypted
private keys). The alternative of forcing the users to encrypt using
EncryptedPrivateKeyInfo looks better to me.
I'd love to see support for the OpenSSL private key formats; it seems
that RSAPrivateCrtKeyImpl already supports PKCS#1 format, so it may be
just a matter of exposing that functionality. Other key types like EC
might need more work. That might be added later after the API is
finalized.

Thanks,
Daniel

?r., 24 sty 2024 o 22:24 Anthony Scarpino
<anthony.scarpino at oracle.com> napisa?(a):
>
> Hi,
>
> The following github link is to the PEM API as it is written in the
> draft JEP (https://openjdk.org/jeps/8300911).  There has been a few
> changes since the original posting.
>
> https://github.com/ascarpino/jdk/tree/pem
>
> The Encoder and PEMEncoder to now return byte[] for the encode() method.
>   A new PEMEncoder method, encodeToString(), was added.  I believe these
> make it easier for outputting data to a file and InputStreams, while
> still supporting a method that returns a String.
>
> For decode, InputStream has replaced Reader.  There were comments
> preferring InputStream and I found that Reader's buffering quirks were
> problematic. Decoding from a byte[] is easy through an ByteArrayInputStream.
>
> If you are interested in testing out the API, please download and
> compile the repo.  Then let me know how your experience went.
>
> thanks
>
> Tony


From duke at openjdk.org  Thu Jan 25 18:13:37 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Thu, 25 Jan 2024 18:13:37 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <E6J-hgskGFPt_bKGtELOdnNP_gpSP6CYzdXp8Dr8GOQ=.136e4919-d86d-490d-9f51-122e00a99a9a@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

I enabled gh actions and started build of windows platforms (all other options left empty/default). Hopefully github lets you to look at the results  - https://github.com/rebarbora-mckvak/jdk/actions/runs/7658564889

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1910735808


From anthony.scarpino at oracle.com  Thu Jan 25 21:02:16 2024
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 25 Jan 2024 13:02:16 -0800
Subject: [External] : Re: PEM API github repo
In-Reply-To: <CAMrH03J=wX-1Kp+LVasv0-R-NEWBy31_dkb+v4CFNXoksJRfwQ@mail.gmail.com>
References: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>
 <CAMrH03J=wX-1Kp+LVasv0-R-NEWBy31_dkb+v4CFNXoksJRfwQ@mail.gmail.com>
Message-ID: <9c42dd2d-00a2-470f-b319-c2cfb7c10de6@oracle.com>


On 1/25/24 9:20 AM, Daniel Jeli?ski wrote:
> Hi Tony,
> Thanks for the links! The API looks very promising.
> 
> Out of curiosity, why aren't you using the Base64 MIME
> encoder/decoder? They are supposed to produce/remove the newline
> characters.

I can look it over again.  I had inconsistencies during testing with 
expected data and returned data.

> The relationship between the byte[] and String data should be
> specified. Base64 explicitly specifies that the String APIs are
> translated to the byte[] APIs with ISO 8859-1 encoding. The PEMDecoder
> is currently using the default charset, which might produce
> interesting results if the charset is set to EBCDIC. The encoder is
> using UTF-8, which is reasonable, but given that the produced output
> will always be ASCII, ISO 8859-1 will perform better.

That's fine

> There's a disparity between the decoder and the encoder APIs; both
> work with strings, but Decoder accepts InputStream and not arrays, and
> Encoder produces byte arrays, but does not work with streams. This
> should be more uniform. I like Decoder's InputStream support (that's
> currently the only way to read multiple CA certificates from a single
> file - the String overload currently only returns the first one), so
> I'd add OutputStream support to Encoder for parity.

I don't see parity as a requirement.  I see encoding and decoding as 
having unique requirements.  Decoding from a file or InputStream makes 
sense.  A decode(byte[]) method didn't seem necessary as I felt it 
unlikely a user would have a single byte[] with PEM data.  They were 
more likely to have a String or an InputStream.  The developer can wrap 
it with ByteArrayInputStream or String(byte[], Charset), which is what a 
public API method would do internally.

Encoding is a single operation on an object.  Pass in a SecurityObject 
and PEM data is returned.  Returning a byte[] is the most flexible 
without creating more methods.  In the case where meta data is 
in-between the PEM or some other data formatting.

Why should the API have an OutputStream method, something like:
   pem.encodeToOutputStream(so, outputstream);
when the API as written today, the developer can use:
   outputstream.writeBytes(pem.encode(obj));

I don't like to add API methods just for symmetry, they need to have a 
compelling reason.  I have not seen that in the OutputStream case.


> Karl's earlier
> suggestion to support Stream<SecurityObject> also makes a lot of
> sense.
I haven't counted out Stream, I just haven't seen a compelling reason. 
My tests use stream() from an array list of PEM strings.  But I haven't 
seen the situation where the API needs stream support that couldn't be 
done in a different way.  This is a preview JEP, and we still have time. 
  If there is a compelling example, point it out to me.

> I'm not a big fan of the non-static factory methods
> withEncryption/withDecryption/withFactory. The problem with non-static
> methods that return an instance of the same type is that you need to
> check the documentation to know if the method returns a new instance
> or if it mutates the current one. Can we use static factory methods
> instead? Either that, or create a builder class.

The API states the classes are immutable which was a big requirement and 
it why it's stated all over the docs.  A builder class was considered 
early in the API development, but it was too much complication for a few 
optional cases where the developer may need to specify details like 
encryption or a factory.  The API has the builder idea, without the 
extra builder construction methods.  I don't see how a static factory 
method fit here.

> I don't like the PEMEncoder.withEncryption API. It's not predictable
> enough; when encoding data, it's not consistent between writing
> unencrypted data (certificate, crl), throwing (PublicKey,
> EncryptedPrivateKeyInfo) and writing encrypted data (unencrypted
> private keys). The alternative of forcing the users to encrypt using
> EncryptedPrivateKeyInfo looks better to me.

That was a design decision to make the API easier to use.  The 
non-security export does not need to be burden with understanding 
EncryptedPrivateKeyInfo.

The API can be consistent if you choose to only pass in 
EncryptedPrivateKeyInfo and not set withEncryption().  If an 
ArrayList<SecurityObject> encodes with a stream(), it is nice to 
configure encryption for private keys and still encode public keys and 
certificates with the same encoder.


> I'd love to see support for the OpenSSL private key formats; it seems
> that RSAPrivateCrtKeyImpl already supports PKCS#1 format, so it may be
> just a matter of exposing that functionality. Other key types like EC
> might need more work. That might be added later after the API is
> finalized.

OpenSSL 3.0 is transitioning away from their format to PKCS#8.  It is an 
obsoleted format.  While I have thought about decoding support of RSA 
PKCS#1 for compatibility, I have no intention to support OpenSSL or 
PKCS#1 encoding with this PEM API.

If someone is interested in old OpenSSL or other encoding formats, that 
is why the Encoder and Decoder interfaces are included.  To give a 
structure for developing other encoding.

> 
> Thanks,
> Daniel
> 
> ?r., 24 sty 2024 o 22:24 Anthony Scarpino
> <anthony.scarpino at oracle.com> napisa?(a):
>>
>> Hi,
>>
>> The following github link is to the PEM API as it is written in the
>> draft JEP (https://openjdk.org/jeps/8300911).  There has been a few
>> changes since the original posting.
>>
>> https://urldefense.com/v3/__https://github.com/ascarpino/jdk/tree/pem__;!!ACWV5N9M2RV99hQ!NmZu22NrC2hxWJuqLHZ6l1C0KYVK0Qf_rV7tV-1uLqUb_5sFMJXyCCKVPjmEmGCeQ6US2RJquDm9AJqZXO46ju8Q$
>>
>> The Encoder and PEMEncoder to now return byte[] for the encode() method.
>>    A new PEMEncoder method, encodeToString(), was added.  I believe these
>> make it easier for outputting data to a file and InputStreams, while
>> still supporting a method that returns a String.
>>
>> For decode, InputStream has replaced Reader.  There were comments
>> preferring InputStream and I found that Reader's buffering quirks were
>> problematic. Decoding from a byte[] is easy through an ByteArrayInputStream.
>>
>> If you are interested in testing out the API, please download and
>> compile the repo.  Then let me know how your experience went.
>>
>> thanks
>>
>> Tony


From abakhtin at openjdk.org  Thu Jan 25 22:01:48 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 25 Jan 2024 22:01:48 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v4]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

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

  Reuse code from addCertificatesToKeystore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/8fdea0f2..15a28d9a

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

  Stats: 221 lines in 3 files changed: 76 ins; 83 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/16722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16722/head:pull/16722

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


From abakhtin at openjdk.org  Thu Jan 25 22:01:53 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 25 Jan 2024 22:01:53 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <TnaOGOW7UpBLBpPgVw5eE7MRhR_XHXhWRGeJS6s3Txk=.210403b0-a246-42d3-9be5-238cfa2627c0@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
 <TnaOGOW7UpBLBpPgVw5eE7MRhR_XHXhWRGeJS6s3Txk=.210403b0-a246-42d3-9be5-238cfa2627c0@github.com>
Message-ID: <-AcB8uIhRzMhEboq_yzgqYqPoiwGTduf16mntXUkZk8=.970dc8ff-9491-4141-9a56-b5306142a643@github.com>

On Wed, 24 Jan 2024 15:41:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add KeychainStore-ROOT keystore for root certificates
>
> src/java.base/macosx/classes/apple/security/AppleProvider.java line 89:
> 
>> 87:                            "KeychainStore", "apple.security.KeychainStore.USER"));
>> 88:                 putService(new ProviderService(p, "KeyStore",
>> 89:                            "KeychainStore-ROOT", "apple.security.KeychainStore.ROOT"));
> 
> I think the correct class names should be `KeychainStore$USER` and `KeychainStore$ROOT`, although they might be used.

Thank you. updated with the $ sign

> src/java.base/macosx/classes/apple/security/KeychainStore.java line 52:
> 
>> 50:  */
>> 51: 
>> 52: abstract class KeychainStore extends KeyStoreSpi {
> 
> Make it `abstract sealed`.

Good catch. Thank you. Added `sealed`

> src/java.base/macosx/classes/apple/security/KeychainStore.java line 216:
> 
>> 214:      */
>> 215:     private String getName()
>> 216:     {
> 
> Put the closing brace to the previous line. Actually, probably not worth creating a new method.

OK. Not much reason for this method. removed

> src/java.base/macosx/classes/apple/security/KeychainStore.java line 546:
> 
>> 544: 
>> 545:         synchronized(entries) {
>> 546: 
> 
> Useless.

Fixed

> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 478:
> 
>> 476:                 // Load user trustSettings into inputTrust
>> 477:                 if (SecTrustSettingsCopyTrustSettings(certRef, domain, &trustSettings) == errSecSuccess && trustSettings != NULL) {
>> 478:                     if(inputTrust == NULL) {
> 
> Add a space after `if`.

Fixed

> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 544:
> 
>> 542: 
>> 543:     // Read Trust Anchors
>> 544:     if(SecTrustCopyAnchorCertificates(&currAnchors) == errSecSuccess) {
> 
> Add a space after `if`.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1467006056
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1467006192
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1467006360
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1467006453
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1467006522
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1467006582


From abakhtin at openjdk.org  Thu Jan 25 22:05:37 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 25 Jan 2024 22:05:37 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v3]
In-Reply-To: <pChwGmRSsDPsDlu7kcawK6RNKt5NO3ZZ8l_m1qpmxlo=.3c5d8572-c16a-4ab5-ae66-c2800e95ad60@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <ZNueNugy2x4BR12gUcOQFRYMpWlCiTu7gWcjeud8MPQ=.83d2ecf7-a276-4dd2-91b1-c64a93cfc47d@github.com>
 <pChwGmRSsDPsDlu7kcawK6RNKt5NO3ZZ8l_m1qpmxlo=.3c5d8572-c16a-4ab5-ae66-c2800e95ad60@github.com>
Message-ID: <LfLIeMgqmPxnEIq9xZ7LetCfvUnHfYKpG2gUyrFCjgQ=.bdbfe932-fc20-4277-929e-a70d6380e012@github.com>

On Wed, 24 Jan 2024 16:04:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Is it possible to reuse some some lines from `addCertificatesToKeystore`?
> 
> BTW, I reviewed the CSR.

Hi @wangweij,
Thank you a lot for PR and CSR review. I have updated PR with review findings and refactored addCertificatesToKeystore/addCertificatesToKeystoreRoot to reuse some code

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1911070905


From djelinski at openjdk.org  Fri Jan 26 10:09:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 26 Jan 2024 10:09:53 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security provider
Message-ID: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>

Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.

The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.

The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).

All sun/security/pkcs11 tests still pass with NSS 3.35 and 3.91. All tier1-3 tests still pass.

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

Commit messages:
 - Free the mechanism parameters early

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

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


From valeriep at openjdk.org  Fri Jan 26 22:09:51 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 26 Jan 2024 22:09:51 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider
In-Reply-To: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
Message-ID: <BU5RyHdaglula7IOcV82tCI1cjJvpleKAbaoK63bED0=.4d5cdf20-d8eb-4beb-8b00-53fccd76f5e3@github.com>

On Fri, 26 Jan 2024 10:04:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
> 
> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
> 
> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
> 
> All sun/security/pkcs11 tests still pass with NSS 3.35 and 3.91. All tier1-3 tests still pass.

Marked as reviewed by valeriep (Reviewer).

IIRC, this may be the special handling to work around the PSS errors I observed when implementing the support. Good that we don't need them now.

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

PR Review: https://git.openjdk.org/jdk/pull/17584#pullrequestreview-1846619636
PR Comment: https://git.openjdk.org/jdk/pull/17584#issuecomment-1912757799


From weijun at openjdk.org  Sat Jan 27 02:15:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 27 Jan 2024 02:15:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
Message-ID: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>

This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.

One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.

Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

Commit messages:
 - remove exe bits
 - remove x bit
 - the patch

Changes: https://git.openjdk.org/jdk/pull/17472/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296244
  Stats: 620 lines in 14 files changed: 464 ins; 52 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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


From alanb at openjdk.org  Sat Jan 27 02:15:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Jan 2024 02:15:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <UljMASUOYPJsDz_kxVJ6lnfnGsH3PS-p6jaV66nYYm0=.770a0e3a-a471-4779-9928-5365d955c529@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-not-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

"is allowed or disallowed" but the detail presents them in the reverse order. I think it would be easier to read if the allowed case went first, this goes for all the methods. I understand that disallow is the default but I think a bit easier to present in that order.

src/java.base/share/classes/javax/security/auth/Subject.java line 298:

> 296:      * {@code AccessControlContext}. When a security manager is
> 297:      * <a href=#sm-not-allowed>not allowed</a>, this method is not supported
> 298:      * and throws an {@code UnsupportedOperationException}.

I think it might be better to say "This method is intended to be used with a security manager. It throws UOE if a security manager is not allowed".

src/java.base/share/classes/javax/security/auth/Subject.java line 379:

> 377:      * current subject binds to the period of the execution of the current
> 378:      * thread. Otherwise, it is associated with the current
> 379:      * {@code AccessControlContext}.

What would you think of "If a security manager is allowed, this method is equivalent to calling getSubject with the current ACC. If a security manager is not allowed, this returns the Subject bound to the current Thread."

src/java.base/share/classes/javax/security/auth/Subject.java line 411:

> 409:      * Finally, this method invokes {@code AccessController.doPrivileged},
> 410:      * passing it the provided {@code PrivilegedAction},
> 411:      * as well as the newly constructed {@code AccessControlContext}.

I think this method would be easier to present if the allowed and not-allowed cases were in separate paragraphs. The reason is that the SM allowed case has a lot more test. For the not allowed case then it would be clearer to say that the calls the value returning function with the current Thread bound to the given Subject.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467824941
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467826752
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467829318
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467831325


From shade at openjdk.org  Mon Jan 29 11:19:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Jan 2024 11:19:36 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <KbwcVzLPJIATb-T81wDSrPzsIqmMYDT4KM_Oq9l1I6o=.22cdcbcf-2bb0-4abe-9033-7155d9f2ff15@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

Looks good to me, given our target is to backport this to other releases which have a similar code shape. But someone who is more familiar with this code should take a look, maybe @valeriepeng?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17559#pullrequestreview-1848428823


From shade at openjdk.org  Mon Jan 29 11:20:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Jan 2024 11:20:24 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <LHXYdDO_EFf0X37yip3Y3rbujtmQAgN2VU8GJ-T2-Qo=.3d22fa4e-c1b9-4d4c-8baa-c63471644dc6@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

Seems like a good workaround. Attn @valeriepeng ;)

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17560#pullrequestreview-1848430362


From djelinski at openjdk.org  Mon Jan 29 13:12:34 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 29 Jan 2024 13:12:34 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider
In-Reply-To: <BU5RyHdaglula7IOcV82tCI1cjJvpleKAbaoK63bED0=.4d5cdf20-d8eb-4beb-8b00-53fccd76f5e3@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
 <BU5RyHdaglula7IOcV82tCI1cjJvpleKAbaoK63bED0=.4d5cdf20-d8eb-4beb-8b00-53fccd76f5e3@github.com>
Message-ID: <qmnFQTe6Iy46sPvCl5dnz-vrr1cahJ6CSlkvwmPDKV4=.26d795c9-02bb-48a4-b5b2-cb49714bf6ee@github.com>

On Fri, 26 Jan 2024 22:06:23 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
>> 
>> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
>> 
>> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
>> 
>> All sun/security/pkcs11 tests still pass with NSS 3.35 and 3.91. All tier1-3 tests still pass.
>
> IIRC, this may be the special handling to work around the PSS errors I observed when implementing the support. Good that we don't need them now.

Thanks @valeriepeng for your review. I started looking into why I wasn't able to reproduce the errors you were seeing, and found that the tests I run with NSS 3.35 were silently skipped. I had to make some adjustments to PKCS11Test.java to actually make them work. I'll document that in a separate JBS ticket shortly.

Bottom line: With NSS 3.35 the following tests fail with this change:

sun/security/pkcs11/Signature/InitAgainPSS.java
sun/security/pkcs11/Signature/SigInteropPSS.java
sun/security/pkcs11/Signature/SignatureTestPSS.java
sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java

This was a NSS problem which was fixed here:
https://hg.mozilla.org/projects/nss/diff/be386bdafeb8dcfd894af7ff151b04afe748857a/lib/softoken/pkcs11c.c#l1.639
The fix was released in NSS 3.65.

Now, the still-supported Ubuntu 20.04 ships with NSS 3.49, which does not have this fix. I suppose other distros might also have non-EOL releases with a broken NSS version. How can we alert them about the problems they may face with this fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/17584#issuecomment-1914665234


From mbalao at openjdk.org  Tue Jan 30 00:09:54 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 30 Jan 2024 00:09:54 GMT
Subject: RFR: 8315487: Security Providers Filter [v6]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <p2d5YTDfTgDwI8vkrCXPs2Wtv_Dx_4fsK9FYYA6I2qg=.7257b82f-c241-48c0-96c3-3ff5c8d5fc9c@github.com>

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

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

  Support for cipher transformations and JEP alignment
  of the java.security documentation.
  
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/35516004..f015ba87

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

  Stats: 555 lines in 9 files changed: 387 ins; 44 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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


From duke at openjdk.org  Tue Jan 30 02:01:41 2024
From: duke at openjdk.org (duke)
Date: Tue, 30 Jan 2024 02:01:41 GMT
Subject: Withdrawn: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <8xIZ6lBaroeGU4SYJ2EHufI6MC8HcLoC8gIKqWlYk5w=.28d3c17c-5bd6-4abf-80cf-086583c4775f@github.com>

On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

This pull request has been closed without being integrated.

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

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


From jpai at openjdk.org  Tue Jan 30 05:37:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 05:37:44 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <WAEbjqx3d5sYpkfzDGzKSs0ZKEUTtXqJvA_6Va2qD-g=.32ff1b84-3539-4edd-beba-bc9de26fc778@github.com>

On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

Hello Eirik, I think this is a reasonable change. I haven't had a chance to review some of these PRs due to some other priority tasks. I have these PRs on my TODO list. So if you want to pursue this further, please go ahead and reopen this and I'll review this in the coming days.

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1916110895


From dfuchs at openjdk.org  Tue Jan 30 14:01:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:01:24 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:

> 347:     @SuppressWarnings("removal")
> 348:     private Subject getSubject() {
> 349:         return Subject.current();

Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:

> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
> 306:                     public Subject run() {
> 307:                         return Subject.current();

Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471257982
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471263581


From dfuchs at openjdk.org  Tue Jan 30 14:21:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:32 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <K4rNAdIWeAQ1YRVn-4-H96Aj6nZ9JCk0vQRbwcivKo8=.3acbb46f-0d68-4904-aeac-a98a16b04e8f@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Changes requested by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1851409950


From dfuchs at openjdk.org  Tue Jan 30 14:21:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:33 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>

On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:         return Subject.current();
> 
> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:

`RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 

So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?

It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.

Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471308151


From eirbjo at openjdk.org  Tue Jan 30 16:17:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 30 Jan 2024 16:17:13 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v2]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com>

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

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

 - Update copyright years for 2024
 - Merge branch 'master' into zipentry-external-attributes
 - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16952/files
  - new: https://git.openjdk.org/jdk/pull/16952/files/87db8646..481ae754

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

  Stats: 155690 lines in 2884 files changed: 86094 ins; 58372 del; 11224 mod
  Patch: https://git.openjdk.org/jdk/pull/16952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952

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


From weijun at openjdk.org  Tue Jan 30 16:48:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:48:53 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
Message-ID: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>

On Tue, 30 Jan 2024 14:19:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
>> 
>>> 347:     @SuppressWarnings("removal")
>>> 348:     private Subject getSubject() {
>>> 349:         return Subject.current();
>> 
>> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.
>
> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
> 
> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
> 
> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
> 
> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
> 
> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

This is complicated.

The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.

I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.

I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471591997


From weijun at openjdk.org  Tue Jan 30 16:44:46 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:44:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>

On Tue, 30 Jan 2024 13:56:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
> 
>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>> 306:                     public Subject run() {
>> 307:                         return Subject.current();
> 
> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471585097


From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v2]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <lvRruRgRq_fjDZkadDnMl1l2mbn6riSOew16WnNQrok=.dc8a4d37-2300-4223-aaab-ea81ae8f7223@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - JMX needs SM
 - Resolve Alan's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/75df9b0d..a16472fb

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

  Stats: 89 lines in 10 files changed: 36 ins; 16 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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


From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v2]
In-Reply-To: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
 <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
Message-ID: <HRBW0RxGY38lLNj0o0sFguRZ8nYqLjJMVZ2jQoxZkN0=.906bccdf-5e24-4449-a142-1a40491ffd13@github.com>

On Tue, 30 Jan 2024 16:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
>> 
>> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
>> 
>> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
>> 
>> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
>> 
>> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.
>
> This is complicated.
> 
> The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.
> 
> I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.
> 
> I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

A new commit is push. The change in this class is reverted. I'm still investigating the other one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471906073


From weijun at openjdk.org  Tue Jan 30 21:58:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 21:58:28 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

  fix MBeanServerFileAccessController, more test in SM

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/a16472fb..8f270d09

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

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

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


From weijun at openjdk.org  Tue Jan 30 22:36:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 22:36:47 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
Message-ID: <QRKZc0wq2LKmqFG9rnq3h92fu3Y-u-78gYcsAlnxm2M=.436b9a55-bb43-4026-84ab-c9c3ae35e1f9@github.com>

On Tue, 30 Jan 2024 16:41:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
>> 
>>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>>> 306:                     public Subject run() {
>>> 307:                         return Subject.current();
>> 
>> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?
>
> When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

I fixed it in the latest commit. The original code change is simply wrong. `AccessController.getContext()` would return different ACCs inside and outside `doPriv`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1472043888


From valeriep at openjdk.org  Tue Jan 30 23:49:33 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 Jan 2024 23:49:33 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <sSXh7KyfmQI3WCe0mrWgIslnbxi_qD2hiJNW_aBkUBg=.923b7fce-1147-4080-9667-36a523bc1c0d@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

For NativePRNG, should the dummy constructor just ignores the parameters? If passed with a non-null parameter, should it accept it? Max and Brad is more familiar with SecureRandom than me, so it's better that they chime in on this. @bradfordwetmore @wangweij

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1918100983


From mbalao at openjdk.org  Wed Jan 31 04:18:04 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 31 Jan 2024 04:18:04 GMT
Subject: RFR: 8315487: Security Providers Filter [v7]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <9gWirtGicGY_QrkTssxaig7ITLedj4eoJjffr3CTMOE=.fc6c0cb6-f030-4cfd-bf4f-9b25b7b8d19e@github.com>

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

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

  ProvidersFilterTest extended to cover all JCA service types.
  
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/f015ba87..b231a75d

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

  Stats: 224 lines in 2 files changed: 200 ins; 1 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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


From jjiang at openjdk.org  Wed Jan 31 07:47:21 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 31 Jan 2024 07:47:21 GMT
Subject: RFR: 8325022: Incorrect error message on TLS 1.2 client authentication
Message-ID: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>

If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.

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

Commit messages:
 - 8325022: Incorrect error message on TLS 1.2 client authentication

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

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


From syan at openjdk.org  Wed Jan 31 08:27:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 31 Jan 2024 08:27:03 GMT
Subject: RFR: 8325024:
 java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment
 information
Message-ID: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>

8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information

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

Commit messages:
 - 8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information

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

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


From djelinski at openjdk.org  Wed Jan 31 10:23:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 Jan 2024 10:23:22 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider [v2]
In-Reply-To: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
Message-ID: <Hl14JG3s6-iiUtUV5Ue8SDkIkxqSODFC_N_3V2Kgwcs=.c9c52513-2490-4abd-a937-af914a0e1952@github.com>

> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
> 
> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
> 
> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
> 
> All sun/security/pkcs11 tests still pass with NSS ~3.35 and~ 3.91. All tier1-3 tests still pass.
> 
> EDIT:
> Some sun/security/pkcs11 tests fail with NSS 3.64 and older, see [comment](https://github.com/openjdk/jdk/pull/17584#issuecomment-1914665234)

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Disable RSA-PSS in known bad NSS versions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17584/files
  - new: https://git.openjdk.org/jdk/pull/17584/files/3d036c2b..87edba10

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

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

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


From djelinski at openjdk.org  Wed Jan 31 10:23:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 Jan 2024 10:23:22 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider
In-Reply-To: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
Message-ID: <AK3DJ4u2AWzl4FPsIumbvKqWBkTvdKEGaXro-OyBTU0=.c4ad5b9a-ec4c-49ab-be4d-dd8b7d58360d@github.com>

On Fri, 26 Jan 2024 10:04:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
> 
> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
> 
> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
> 
> All sun/security/pkcs11 tests still pass with NSS ~3.35 and~ 3.91. All tier1-3 tests still pass.
> 
> EDIT:
> Some sun/security/pkcs11 tests fail with NSS 3.64 and older, see [comment](https://github.com/openjdk/jdk/pull/17584#issuecomment-1914665234)

Updated the code to disable RSA-PSS on known bad NSS versions

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

PR Comment: https://git.openjdk.org/jdk/pull/17584#issuecomment-1918806644


From weijun at openjdk.org  Wed Jan 31 15:11:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 Jan 2024 15:11:06 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v4]
In-Reply-To: <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>
Message-ID: <irPToO57s4rSyEez3VWBV0awcL4sOo-5UvSW3kpTPvA=.ac819c0c-4e05-42f6-a6eb-c7e16c9e2b15@github.com>

On Thu, 25 Jan 2024 22:01:48 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse code from addCertificatesToKeystore

Great! The change looks good. Can you manage to add a test? Maybe try to load both store types. Make sure they have different contents and not empty (?).

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1919295342


From weijun at openjdk.org  Wed Jan 31 15:36:05 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 Jan 2024 15:36:05 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v4]
In-Reply-To: <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>
Message-ID: <KSy-VMJ8H2dAr5QvxxckT3jI4EG5rwKsbytkkzqg84Y=.31d24060-6c40-4b21-914f-b0c78cb378f1@github.com>

On Thu, 25 Jan 2024 22:01:48 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse code from addCertificatesToKeystore

Do you intend to call `addIdentitiesToKeystore` for both store types?

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1919350099


From jnimeh at openjdk.org  Wed Jan 31 16:59:02 2024
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 31 Jan 2024 16:59:02 GMT
Subject: RFR: 8325022: Incorrect error message on TLS 1.2 client
 authentication
In-Reply-To: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
Message-ID: <cZlMXXkqZpS-xFBZvk8gKrikPqAt_kJeC56Zd62BId8=.31b25555-4202-40c5-b95c-efb4a330f9e3@github.com>

On Wed, 31 Jan 2024 07:42:32 GMT, John Jiang <jjiang at openjdk.org> wrote:

> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.

Looks good.

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17645#pullrequestreview-1854321874


From hchao at openjdk.org  Wed Jan 31 17:05:01 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 31 Jan 2024 17:05:01 GMT
Subject: RFR: 8325022: Incorrect error message on TLS 1.2 client
 authentication
In-Reply-To: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
Message-ID: <PrNAkjeRTPEodIKf_qLIeexxqSk-SYOsoz3RlUbKhWQ=.d988158b-6e97-4884-b1f6-317b44a91ce6@github.com>

On Wed, 31 Jan 2024 07:42:32 GMT, John Jiang <jjiang at openjdk.org> wrote:

> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.

Marked as reviewed by hchao (Committer).

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/17645#pullrequestreview-1854335957
PR Comment: https://git.openjdk.org/jdk/pull/17645#issuecomment-1919529976


From weijun at openjdk.org  Wed Jan 31 17:25:04 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 Jan 2024 17:25:04 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <ZBQ_9SjCn_LkJtIwYpNmwVXUcAxtPgzBnkbdUwsscNE=.7dce7505-1fb8-41a0-b733-598607fc355f@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

I think Valerie is correct. Otherwise, `SecureRandom.getInstance("NativePRNG", DrbgParameters.instantiation(...))` will return something that it actually does not support.

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1919563670


From weijun at openjdk.org  Wed Jan 31 17:26:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 Jan 2024 17:26:03 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <ESSpXt8w5R-Z0Ps6jXVmwrI08IHVQ_Iywij4F-vhA20=.aeecb0e5-223e-4de0-8939-ba9822773152@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

How about just using class literals? There is no need to call `Class.forName`, at least not now since they are all inside `java.base`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919566516


From djelinski at openjdk.org  Wed Jan 31 17:37:01 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 Jan 2024 17:37:01 GMT
Subject: RFR: 8325022: Incorrect error message on TLS 1.2 client
 authentication
In-Reply-To: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
Message-ID: <hJ8YSO-eHT7s42aDirTfQSf11q8jtszLMOjbVIQ3Mcs=.21fcc041-6d76-4e11-844d-15fd19ac3422@github.com>

On Wed, 31 Jan 2024 07:42:32 GMT, John Jiang <jjiang at openjdk.org> wrote:

> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.

Looks good, but could you also fix the messages on line 406 and 1227?

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17645#pullrequestreview-1854426282


From ogillespie at openjdk.org  Wed Jan 31 17:38:03 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 31 Jan 2024 17:38:03 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <ESSpXt8w5R-Z0Ps6jXVmwrI08IHVQ_Iywij4F-vhA20=.aeecb0e5-223e-4de0-8939-ba9822773152@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
 <ESSpXt8w5R-Z0Ps6jXVmwrI08IHVQ_Iywij4F-vhA20=.aeecb0e5-223e-4de0-8939-ba9822773152@github.com>
Message-ID: <eOLZQDVGVdX5O3zGL7LaN0oTAS0dnM53iSHCgnYup7w=.d8254660-b96e-45f7-a849-4139ed4564c2@github.com>

On Wed, 31 Jan 2024 17:23:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> How about just using class literals? There is no need to call `Class.forName`, at least not now since they are all inside `java.base`.

Thanks :). That seems sensible if writing from scratch, but that part I'm just reviving from [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) which is nice for keeping it in sync with 17 for backports. My preference is to keep it close to the original code/17 unless there's a strong reason not to.

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919586911


From valeriep at openjdk.org  Wed Jan 31 17:45:02 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 31 Jan 2024 17:45:02 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <-BTMEi6CZVS4uF6IDFpZKJ2YnmFrlV-tCjIEUX0Wdsc=.6f9a74e9-c5ee-49af-9e6d-001f34b6b464@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

I second Max's suggestion of just using String literals. It's cleaner this way. I'd think it'd also be faster?

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919597308


From ogillespie at openjdk.org  Wed Jan 31 17:49:02 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 31 Jan 2024 17:49:02 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <DskiovkjZLv8J1b7p_tzX5BbQ8cYjmWbc5HYg6Qpra8=.986b08b6-67d9-440b-b4da-bd741981f4d2@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

Good point, thanks, I should have thought of that. I see DBRG has this for when the params are not appropriate:

>  throw new IllegalArgumentException("Unsupported params: " + params.getClass());

I'll add something similar in my dummy constructors, unless someone objects.

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1919605124


From jnimeh at openjdk.org  Wed Jan 31 17:51:02 2024
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 31 Jan 2024 17:51:02 GMT
Subject: RFR: 8325024:
 java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment
 information
In-Reply-To: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
References: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
Message-ID: <0kZiSxrq44Kpv-wTeiQK4rvfd-VCfgTfvPFf6Ti0_ls=.b07f7065-e5c0-49c0-b4d3-8ba12d96e4af@github.com>

On Wed, 31 Jan 2024 08:19:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> 8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information

Looks good, but please label the JBS bug with noreg-trivial.

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17646#pullrequestreview-1854456004


From ogillespie at openjdk.org  Wed Jan 31 17:52:02 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 31 Jan 2024 17:52:02 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <nfg1Eaummd-j8-nk_zaJnWA8d7rj7eBTNW0n1I8FDwM=.70a03794-4713-4229-8584-d5efe4e90bfa@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

The lookup only happens once per entry so I don't think performance is a big deal either way. What do you both think about my argument for re-using the code that stood for years and still stands in 17?

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919610000


From weijun at openjdk.org  Wed Jan 31 18:08:01 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 Jan 2024 18:08:01 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <8a1NwxBeb9ijSwHSqH-Ugbt1kl9QWhUn-G8MEYAISV0=.612c08a8-e572-4387-a6d9-261ba8a00352@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

You are converting from string to class anyway, and since this is only implementation detail inside one file, we can even backport it if it really helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919637384


From duke at openjdk.org  Wed Jan 31 18:14:14 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 31 Jan 2024 18:14:14 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v6]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <d3HBfPy69RfRG5m9FaPGVdLdyOPOtNFXwl2Db7szQxE=.f2ecbbab-86f1-49a5-9a2f-7e2d5ab41de1@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  Refactor to simplify lambda expressions in AttributeInfo. Added new test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/730979a5..c379f2ce

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

  Stats: 118 lines in 1 file changed: 34 ins; 39 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/17132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17132/head:pull/17132

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


From duke at openjdk.org  Wed Jan 31 18:18:30 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 31 Jan 2024 18:18:30 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v7]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <TKDAjGDi7swdpja9izf5mokfrIq-jkx7OatPzbqTovM=.feebd58a-6dd0-4233-8bb5-b5cfa3b416ae@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  Added EncodeDecode.java test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/c379f2ce..f8c68932

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

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

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


From weijun at openjdk.org  Wed Jan 31 18:21:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 Jan 2024 18:21:06 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v7]
In-Reply-To: <TKDAjGDi7swdpja9izf5mokfrIq-jkx7OatPzbqTovM=.feebd58a-6dd0-4233-8bb5-b5cfa3b416ae@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <TKDAjGDi7swdpja9izf5mokfrIq-jkx7OatPzbqTovM=.feebd58a-6dd0-4233-8bb5-b5cfa3b416ae@github.com>
Message-ID: <ALS2h-XuHWc8tRuS8r7WwSsZHCl0kEzweyO6NhtWgmQ=.e5e15ce8-e815-4ae2-b0c0-cefc51c98337@github.com>

On Wed, 31 Jan 2024 18:18:30 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added EncodeDecode.java test

test/jdk/sun/security/pkcs/pkcs9/EncodeDecode.java line 102:

> 100:         test(CMS_ALGORITHM_PROTECTION_OID, onev,
> 101:             "301b06092a864886f70d010934310e300c040a00000000000000000000");
> 102: 

Better add a comment here that the next line is about an "unsupported" type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1473273639


From valeriep at openjdk.org  Wed Jan 31 19:00:04 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 31 Jan 2024 19:00:04 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <soMifUOxA8jYqbJeg_uUJoh8OiR755tq8tM8kw86aXE=.bf217d03-71ed-47a0-b8e5-06a9c81b147f@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

I still prefer class literals as it's cleaner and more straight forward than the pre-existing approach. Why having two fields when one is enough. In most if not all aspects, class literals seems a better solution... Backport should be doable as the scope of change is limited.

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919737803


From jjiang at openjdk.org  Wed Jan 31 20:07:28 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 31 Jan 2024 20:07:28 GMT
Subject: RFR: 8325022: Incorrect error message on client authentication
 [v2]
In-Reply-To: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
Message-ID: <C9CJeK6lAAgs4vB2UdV2DU6cLHofKTXuL5SyAzG14G4=.74e47b49-781e-41d8-96e4-3bba992ebdd9@github.com>

> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.

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

  fix more error messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17645/files
  - new: https://git.openjdk.org/jdk/pull/17645/files/f11da037..06a7669d

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

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

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


From djelinski at openjdk.org  Wed Jan 31 20:15:02 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 Jan 2024 20:15:02 GMT
Subject: RFR: 8325022: Incorrect error message on client authentication
 [v2]
In-Reply-To: <C9CJeK6lAAgs4vB2UdV2DU6cLHofKTXuL5SyAzG14G4=.74e47b49-781e-41d8-96e4-3bba992ebdd9@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
 <C9CJeK6lAAgs4vB2UdV2DU6cLHofKTXuL5SyAzG14G4=.74e47b49-781e-41d8-96e4-3bba992ebdd9@github.com>
Message-ID: <FcBQEKUBYTrdzQdrCEEa_x4gT9B-qSwwJc7mp9tBg6I=.5bf4983b-fb63-4914-9aae-03674baad449@github.com>

On Wed, 31 Jan 2024 20:07:28 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix more error messages

Perfect. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17645#pullrequestreview-1854743319


From duke at openjdk.org  Wed Jan 31 20:46:02 2024
From: duke at openjdk.org (Bernd)
Date: Wed, 31 Jan 2024 20:46:02 GMT
Subject: RFR: 8325022: Incorrect error message on client authentication
 [v2]
In-Reply-To: <C9CJeK6lAAgs4vB2UdV2DU6cLHofKTXuL5SyAzG14G4=.74e47b49-781e-41d8-96e4-3bba992ebdd9@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
 <C9CJeK6lAAgs4vB2UdV2DU6cLHofKTXuL5SyAzG14G4=.74e47b49-781e-41d8-96e4-3bba992ebdd9@github.com>
Message-ID: <HRihQ6pucIpvL35XXDlBfWr9alvv1uPMmi0vAEL1NV8=.0d93579a-1e6c-4920-8c94-80e469f8995d@github.com>

On Wed, 31 Jan 2024 20:07:28 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix more error messages

src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 389:

> 387:                     // unexpected or require client authentication
> 388:                     throw shc.conContext.fatal(Alert.BAD_CERTIFICATE,
> 389:                         "Empty client certificate chain");

Hm, in tls1.3 it should be certificate_required and in 1.2 handshake_failure for required auth.

rfc8446 6.2 ?certificate_required:  Sent by servers when a client certificate is
      desired but none was provided by the client.?
rfc5246 7.4.6 ? If the client does not send any certificates, the
      server MAY at its discretion either continue the handshake without
      client authentication, or respond with a fatal handshake_failure
      alert.?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17645#discussion_r1473440462


From duke at openjdk.org  Wed Jan 31 20:47:20 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 31 Jan 2024 20:47:20 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v8]
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <xJd2eHaQoZv2N-bJF_Kzc0ZNC1iiNzlDztBlZx8nqcE=.b4f76cef-36a4-4f72-90be-5e572134a0e1@github.com>

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

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

  Added comment to EncodeDecode test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17132/files
  - new: https://git.openjdk.org/jdk/pull/17132/files/f8c68932..292668f3

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

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

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