From duke at openjdk.java.net  Wed Jun  1 07:50:58 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 1 Jun 2022 07:50:58 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v9]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

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

  8282662: Revert wrong copyright year change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7729/files
  - new: https://git.openjdk.java.net/jdk/pull/7729/files/b20c2703..7bb28667

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/7729

From rriggs at openjdk.java.net  Wed Jun  1 13:32:47 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Jun 2022 13:32:47 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v9]
In-Reply-To: <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>
Message-ID: <LhfwNIF-X5d-rCxD6zfVXINWKrcDS3JMYc9l2yEJKFQ=.72e66580-4a2c-4c7f-abdb-34898a9f333f@github.com>

On Wed, 1 Jun 2022 07:50:58 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert wrong copyright year change

Marked as reviewed by rriggs (Reviewer).

Thanks for the improvements.

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

PR: https://git.openjdk.java.net/jdk/pull/7729

From duke at openjdk.java.net  Wed Jun  1 13:35:13 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 1 Jun 2022 13:35:13 GMT
Subject: Integrated: 8282662: Use List.of() factory method to reduce memory
 consumption
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <aaJhGv-fyhi3UXKlfnYJbIhFULcZvse_BWu00DkPwHg=.fc7bc5de-4323-47ab-93ec-d955a967525d@github.com>

On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

This pull request has now been integrated.

Changeset: 168b226b
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/168b226b0f7a3b067bf11616e5a92908f63be450
Stats:     12 lines in 4 files changed: 1 ins; 2 del; 9 mod

8282662: Use List.of() factory method to reduce memory consumption

Reviewed-by: redestad, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/7729

From smarks at openjdk.java.net  Wed Jun  1 17:44:24 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 1 Jun 2022 17:44:24 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <IhiEBcMA2Zj0IWKO4jNpbCdAYbNvKP-GlA2bcbU7Yo0=.670eea02-4f1a-48db-996b-1cec9c1438e0@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From naoto at openjdk.java.net  Wed Jun  1 18:31:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 18:31:34 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewed i18n-related changes and they look good. One minor suggestion in `Calendar`, but that can be applied later.

src/java.base/share/classes/java/util/Calendar.java line 2648:

> 2646:             set.add("gregory");
> 2647:             set.add("buddhist");
> 2648:             set.add("japanese");

This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Wed Jun  1 18:42:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 18:42:36 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <dh6Twe_QhgR3NgCROm40Rj2oJfp5V0EseBOq_y5IFUE=.4179a789-9937-4779-83fc-6ba845c17667@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

`java.io` and `java.nio` look all right.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From xuelei at openjdk.java.net  Wed Jun  1 19:17:02 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 1 Jun 2022 19:17:02 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC
Message-ID: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>

This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

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

Commit messages:
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287596
  Stats: 83 lines in 10 files changed: 12 ins; 40 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.java.net/jdk/pull/8979

From aturbanov at openjdk.java.net  Wed Jun  1 20:47:59 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Jun 2022 20:47:59 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
Message-ID: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>

Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

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

Commit messages:
 - [PATCH] Avoid redundant Hashtable.containsKey call in JarVerifier

Changes: https://git.openjdk.java.net/jdk/pull/8935/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8935&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287696
  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8935.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8935/head:pull/8935

PR: https://git.openjdk.java.net/jdk/pull/8935

From mchung at openjdk.java.net  Wed Jun  1 20:49:32 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 20:49:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <2ELftDwTR4QUu5qIRT8uVYbe5YhDizwh1PAjyBhqmgg=.99c6e51e-53eb-4068-8d5a-3d05e23f4e3c@github.com>

On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

JDK-8287384 causes `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` to timeout when running with fastdebug VM.  I think this might be caused by more frequent GCs.

I tried your patch and the test fails.

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From xuelei at openjdk.java.net  Wed Jun  1 21:07:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 1 Jun 2022 21:07:16 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  back to wait 1 second

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8979/files
  - new: https://git.openjdk.java.net/jdk/pull/8979/files/a1d91596..f3d9eb82

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From xuelei at openjdk.java.net  Wed Jun  1 21:07:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 1 Jun 2022 21:07:16 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <2ELftDwTR4QUu5qIRT8uVYbe5YhDizwh1PAjyBhqmgg=.99c6e51e-53eb-4068-8d5a-3d05e23f4e3c@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <2ELftDwTR4QUu5qIRT8uVYbe5YhDizwh1PAjyBhqmgg=.99c6e51e-53eb-4068-8d5a-3d05e23f4e3c@github.com>
Message-ID: <PF7YCImYJSiNfNDKpvjs63RfmL_biEmXYVp9l_Q74BU=.00248df8-4596-4c25-9464-52de009462b5@github.com>

On Wed, 1 Jun 2022 20:45:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> JDK-8287384 causes `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` to timeout when running with fastdebug VM. I think this might be caused by more frequent GCs.
> 
> I tried your patch and the test fails.

I updated the waiting time back to 1 second.  Would you please check again?

> JDK-8287384 causes `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` to timeout when running with fastdebug VM. I think this might be caused by more frequent GCs.
> 
> I tried your patch and the test fails.

I updated the waiting time back to 1 second.  Would you please check again?

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From mchung at openjdk.java.net  Wed Jun  1 21:12:21 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 21:12:21 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
Message-ID: <-revOIfNpbv7XdgrgMTcDwev4E8Px4P6rsage5ucfp0=.61219114-3b76-4610-9faf-af49d34a87fd@github.com>

On Wed, 1 Jun 2022 21:07:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   back to wait 1 second

No, it doesn't work.  You can build a fastdebug build with `configure --enable-debug`.  I reproduce it on macOS.   If I restore to the previous version without 8287384, the test passes.

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From hchao at openjdk.java.net  Thu Jun  2 01:59:50 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 2 Jun 2022 01:59:50 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true'
Message-ID: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>

Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
Ran MACH5 tier1 and tier2 without failures.

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

Commit messages:
 - 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true'

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

PR: https://git.openjdk.java.net/jdk/pull/8985

From xuelei at openjdk.java.net  Thu Jun  2 05:35:32 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 2 Jun 2022 05:35:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
Message-ID: <nJiJ6AEz_kt36dwv6Sb0Pe8xdug2TiIjFzcTYW9V7_U=.cddd98f7-5514-4102-8226-17f34144cfdd@github.com>

On Wed, 1 Jun 2022 21:07:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   back to wait 1 second

My macOS (M1) and Linux (CentOS) may be too powerful to reproduce the failure.  I tried to set the JTREG time out to 60 seconds, and the timeout issue could be reproduced.  In `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java`, there are 6 calls to the method `assertFalse(unloader.tryUnload())`.  Each call to tryUnload() takes at least 10 seconds.  So the 6 calls takes 60 seconds at least.   If I set the regression timeout value to 70 seconds, the test still can pass.   It implies the rest part other than tryUnload() is pretty fast.

It looks like a regression introduced with the update for [JDK-8287384](https://bugs.openjdk.java.net/browse/JDK-8287384).  I did not fine the cause yet.  I will have more checking tomorrow.

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From xuelei at openjdk.java.net  Thu Jun  2 05:50:20 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 2 Jun 2022 05:50:20 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v3]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <LT8QrMpAgzhJaOouM5JNYkTRnJbBynzthmuAmaZ7jiM=.586fdb8d-2429-4894-b79f-c90819bc5da6@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  rollback JDK-8287384

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8979/files
  - new: https://git.openjdk.java.net/jdk/pull/8979/files/f3d9eb82..a8768e09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=01-02

  Stats: 55 lines in 1 file changed: 21 ins; 14 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.java.net/jdk/pull/8979

From xuelei at openjdk.java.net  Thu Jun  2 05:50:20 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 2 Jun 2022 05:50:20 GMT
Subject: Withdrawn: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <-ELnGoUjMMUsRA03S0T_LfBMH1hnO82BrJO6fcJN89c=.d38b34cb-d249-486a-b24c-97790578e5b7@github.com>

On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From dfuchs at openjdk.java.net  Thu Jun  2 10:33:19 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 2 Jun 2022 10:33:19 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <pBk0szIsy279wF9Amofquc9RB4SyYy1LkvBmdUdwFNU=.9c320114-bff4-4d0c-91ff-c56827cbf4d1@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Changes to `net` and `http` look good.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From mullan at openjdk.java.net  Thu Jun  2 19:20:19 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 2 Jun 2022 19:20:19 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true'
In-Reply-To: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
Message-ID: <fyQD6Q26FfNn1H6736vOBqmgnFhz5dwYXHLh6yJxppY=.f5cc0a08-582a-4d11-a2aa-3c103b684e08@github.com>

On Thu, 2 Jun 2022 01:53:25 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
> Ran MACH5 tier1 and tier2 without failures.

The fix looks fine. Could you add a test for this in the `test/jdk/javax/crypto/CryptoPermissions/` directory? Something that checks if a `ParsingException` is thrown if there are inconsistent entries?

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

PR: https://git.openjdk.java.net/jdk/pull/8985

From djelinski at openjdk.java.net  Thu Jun  2 20:17:37 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 2 Jun 2022 20:17:37 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions
In-Reply-To: <Nrn1zgQ_IvFvh2-UsMWx7REfshHClv_EHrf2h2tLwKI=.20f235bf-3060-4a39-a22b-fd0a8786e5a0@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
 <Nrn1zgQ_IvFvh2-UsMWx7REfshHClv_EHrf2h2tLwKI=.20f235bf-3060-4a39-a22b-fd0a8786e5a0@github.com>
Message-ID: <eNqZ69Gvr3iOv6UUgeaD8X97kJEkZ9c--sirWEHEhdA=.c023422c-5c24-4b87-88ea-1b8a50fb4b50@github.com>

On Tue, 31 May 2022 13:47:28 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 410:
> 
>> 408:                     || chc.resumingSession.getPskIdentity() == null
>> 409:                     || !Arrays.asList(ProtocolVersion.PROTOCOLS_10_12)
>> 410:                         .contains(chc.resumingSession.getProtocolVersion())) {
> 
> would  `chc.resumingSession.getProtocolVersion().useTLS13PlusSpec()` read better for your last condition ? Might save on Array allocations also ?

good point!

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

PR: https://git.openjdk.java.net/jdk/pull/8922

From djelinski at openjdk.java.net  Thu Jun  2 21:02:16 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 2 Jun 2022 21:02:16 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions [v2]
In-Reply-To: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
Message-ID: <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>

> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  different check for TLS13

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8922/files
  - new: https://git.openjdk.java.net/jdk/pull/8922/files/258930f5..ae7c68b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8922&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8922&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8922

From xuelei at openjdk.java.net  Fri Jun  3 06:18:29 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 3 Jun 2022 06:18:29 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v4]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <9WrLY42PjdlE42K-lJ3bpc7s5cn758OHcPW7mSj9xW0=.ea88d631-b250-4ce8-a2f1-d7dd12c0ae78@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  rollback is not in this branch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8979/files
  - new: https://git.openjdk.java.net/jdk/pull/8979/files/a8768e09..4a80db95

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=02-03

  Stats: 58 lines in 1 file changed: 17 ins; 24 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.java.net/jdk/pull/8979

From coffeys at openjdk.java.net  Fri Jun  3 08:52:48 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Fri, 3 Jun 2022 08:52:48 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions [v2]
In-Reply-To: <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
 <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
Message-ID: <qfkV4h3cilzhZbR5l3vsft6Ep0oZMruXbPryCQPAe8A=.36c9d354-d609-41f4-843a-bb135ef1ef89@github.com>

On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   different check for TLS13

Looks good to me

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

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8922

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>

This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).

I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).

`MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

Commit messages:
 - Add null check on Buffer::checkState
 - Add docs
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - Add @ForceInline in hot path from var handle access
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d5b6c7bd...68028fa4

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287809
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.java.net/jdk/pull/9017

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <AgqwxT-Tw5SRrC3fkr33yz5v709cCPjTuPTDYsdxpfQ=.68b76852-db8f-4aea-a185-abf8f460ece7@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Note: other cleanups are possible - such as flattening `ResourceList` into `MemorySession.State`. While that is possible, that's a tricky step, given that the session state can be registered against a cleaner. One option, which I explored, would be to use `MemorySessionImpl` for reachability - which then has an impact on `ScopedMemoryAccess`, as we would have to add reachability fences on the session, as well as on the session state. In any case, I'd like to proceed by steps, since this cleanup was already getting big enough.

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

PR: https://git.openjdk.java.net/jdk/pull/9017

From jpai at openjdk.java.net  Mon Jun  6 13:30:41 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 13:30:41 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <RlYRLnnZQdpHHHd8YqHHaFnL-zbEAnJ3hxcpcUh3Zi0=.631176fa-4d9f-4cc3-800c-e3a95ff1cf93@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

Looks fine to me. Please wait for another review before merging.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8935

From xuelei at openjdk.java.net  Mon Jun  6 20:38:20 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 6 Jun 2022 20:38:20 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v5]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <xOgN-k_MY3oiveTMmUpQivTsB_PexA1Zb5yof1of3ZY=.22bc88bf-e18f-4618-8abd-c0fe23277209@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - back to wait 1 second
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=04
  Stats: 87 lines in 10 files changed: 19 ins; 25 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.java.net/jdk/pull/8979

From xuelei at openjdk.java.net  Mon Jun  6 20:38:22 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 6 Jun 2022 20:38:22 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <-revOIfNpbv7XdgrgMTcDwev4E8Px4P6rsage5ucfp0=.61219114-3b76-4610-9faf-af49d34a87fd@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
 <-revOIfNpbv7XdgrgMTcDwev4E8Px4P6rsage5ucfp0=.61219114-3b76-4610-9faf-af49d34a87fd@github.com>
Message-ID: <d6pUAXBWdlyaG-JdcZsqdPtLRqDGHDRMRJMhzKGCybM=.c801c828-9033-4903-819e-fa7291da2ccd@github.com>

On Wed, 1 Jun 2022 21:09:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   back to wait 1 second
>
> No, it doesn't work.  You can build a fastdebug build with `configure --enable-debug`.  I reproduce it on macOS.   If I restore to the previous version without 8287384, the test passes.

Inspired by @mlchung (See https://github.com/openjdk/jdk/pull/9021), use less waiting time for  UnloadingTest and re-open this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8979

From xuelei at openjdk.java.net  Mon Jun  6 21:32:18 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 6 Jun 2022 21:32:18 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v6]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <B6hh39zblVjqpI2us39gKILVNvqU_kJ2LMlAk0yfiok=.1db9f495-f089-4fa8-89bf-513503addc01@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge master
 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - back to wait 1 second
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=05
  Stats: 86 lines in 10 files changed: 12 ins; 29 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.java.net/jdk/pull/8979

From mcimadamore at openjdk.java.net  Tue Jun  7 13:00:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 7 Jun 2022 13:00:37 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8d28734e...5b8f7246

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

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=01
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.java.net/jdk/pull/9017

From duke at openjdk.java.net  Tue Jun  7 15:37:02 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 7 Jun 2022 15:37:02 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
Message-ID: <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security
> 
> JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: 
> 
> open/src/java.base/share/classes/java/security

Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge
 - fourth iteration
 - Merge
 - Merge
 - third iteration
 - Merge
 - Merge
 - second iteration
 - Merge
 - Merge
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01

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

Changes: https://git.openjdk.java.net/jdk/pull/8319/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8319&range=04
  Stats: 628 lines in 95 files changed: 25 ins; 140 del; 463 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8319.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8319/head:pull/8319

PR: https://git.openjdk.java.net/jdk/pull/8319

From xuelei at openjdk.java.net  Tue Jun  7 18:14:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 7 Jun 2022 18:14:55 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <pqDIz146EyleM3TZeY8WcgjAG9ze7NhE7g7B0bt_K1M=.6fde489c-efb8-4726-861a-38ee6a75fc2d@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge
 - Merge master
 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - back to wait 1 second
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=06
  Stats: 86 lines in 10 files changed: 12 ins; 29 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.java.net/jdk/pull/8979

From hchao at openjdk.java.net  Tue Jun  7 20:52:33 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 7 Jun 2022 20:52:33 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v2]
In-Reply-To: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
Message-ID: <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>

> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
> Ran MACH5 tier1 and tier2 without failures.

Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:

 - Inconsistent entries test
 - Inconsistent entries test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8985/files
  - new: https://git.openjdk.java.net/jdk/pull/8985/files/a1af16e8..d8950465

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8985&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8985&range=00-01

  Stats: 100 lines in 2 files changed: 96 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8985.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8985/head:pull/8985

PR: https://git.openjdk.java.net/jdk/pull/8985

From hchao at openjdk.java.net  Tue Jun  7 20:58:25 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 7 Jun 2022 20:58:25 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v2]
In-Reply-To: <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
Message-ID: <t_MGGIGtHwhegPcTHloRrXWBF-Kv_5cogTNS6Z9HSxg=.3a9f1bf2-03af-421e-88ea-cac8a758abe9@github.com>

On Tue, 7 Jun 2022 20:52:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Inconsistent entries test
>  - Inconsistent entries test

Added a manual test for this. Fixed made to address the issue with inconsistent entries.

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

PR: https://git.openjdk.java.net/jdk/pull/8985

From ascarpino at openjdk.java.net  Wed Jun  8 05:08:23 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 8 Jun 2022 05:08:23 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions [v2]
In-Reply-To: <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
 <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
Message-ID: <7XLZuDFV4DCEYEMgRw3-4K9kOiOtv5MdGz4qKqMUUY8=.dc96bfac-4b71-464b-9769-0fd74957ce4a@github.com>

On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   different check for TLS13

The bug and the PR could have used a lot more description that the issue here is that 1.2 and 1.3 are enabled at the same time. such as via `setEnabledProtocols()`.  At first I thought this bug was incorrect because 1.3 does not display a session_ticket extension as it is only supported in the code by 1.0-1.2.  But with both enabled, it causes all the extensions to be enabled.

After thinking about it, this maybe the better way to fix this as the it a heterogeneous server environment, only sending 1.3 extension from the resumed TLS protocol may cause errors when talking to 1.2 server.  So both extensions need to be enabled globally, but since we are resuming 1.3 state, the same state does not to be passed in a 1.2 connection.  It should do a full handshake.

One could ask the reverse, if the resumption is from 1.2 should we be sending a 1.3 pre_shared_key extension.. But that can be for another bug I suppose.

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

PR: https://git.openjdk.java.net/jdk/pull/8922

From ascarpino at openjdk.java.net  Wed Jun  8 05:14:33 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 8 Jun 2022 05:14:33 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions [v2]
In-Reply-To: <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
 <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
Message-ID: <joY3boBkVtGdWg3g-7DHo6EPzYz6aJsdZJoCRh38ZTU=.d71d6a06-116f-4044-ac8c-d2e90bfb97af@github.com>

On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   different check for TLS13

Marked as reviewed by ascarpino (Reviewer).

please make sure all jdk_security tests and tier1 tests pass before integrating

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

PR: https://git.openjdk.java.net/jdk/pull/8922

From djelinski at openjdk.java.net  Wed Jun  8 06:36:28 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Jun 2022 06:36:28 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions [v2]
In-Reply-To: <7XLZuDFV4DCEYEMgRw3-4K9kOiOtv5MdGz4qKqMUUY8=.dc96bfac-4b71-464b-9769-0fd74957ce4a@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
 <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
 <7XLZuDFV4DCEYEMgRw3-4K9kOiOtv5MdGz4qKqMUUY8=.dc96bfac-4b71-464b-9769-0fd74957ce4a@github.com>
Message-ID: <X1s_4aAV1OlWp57zRndbgsY5xT7Y4LZCvrlNABjPUhs=.5a6e74ca-4e14-4401-acce-7a4f4f01fd71@github.com>

On Wed, 8 Jun 2022 05:05:13 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> The bug and the PR could have used a lot more description that the issue here is that 1.2 and 1.3 are enabled at the same time. 

As far as I can tell, 1.2 and 1.3 are both enabled by default.

> One could ask the reverse, if the resumption is from 1.2 should we be sending a 1.3 pre_shared_key extension.. But that can be for another bug I suppose.

We are not sending `pre_shared_key` when resuming TLS 1.2

> please make sure all jdk_security tests and tier1 tests pass before integrating

done. Thanks for reviewing!

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

PR: https://git.openjdk.java.net/jdk/pull/8922

From djelinski at openjdk.java.net  Wed Jun  8 06:36:30 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Jun 2022 06:36:30 GMT
Subject: Integrated: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions
In-Reply-To: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
Message-ID: <AVeL2zWK2GwnirHJQi2FrbvMVzT7QTitN-xyi4kcbeI=.d04be84a-eb69-4bac-b09e-f88c3b5cbd39@github.com>

On Fri, 27 May 2022 13:20:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.

This pull request has now been integrated.

Changeset: 4662e06b
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4662e06bff2cef7425c194a9cdd7a6fe7469179e
Stats:     19 lines in 2 files changed: 12 ins; 0 del; 7 mod

8277307: Pre shared key sent under both session_ticket and pre_shared_key extensions

Reviewed-by: coffeys, ascarpino

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

PR: https://git.openjdk.java.net/jdk/pull/8922

From ssahoo at openjdk.java.net  Wed Jun  8 10:27:38 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 8 Jun 2022 10:27:38 GMT
Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v3]
In-Reply-To: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
References: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
Message-ID: <4Ihy95kdM3NFB7WLrWtssNQ3TUSDwwV-kKV07JzKW7g=.050c4b48-8d72-4554-bdbe-bc3d3e0a7a9d@github.com>

> A Test updated to cover the getCodeSigners.

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

 - Merge remote-tracking branch 'upstream/master' into JDK-8209935
 - Update Implies.java
 - Update Implies.java
 - 8209935: Test to cover CodeSource.getCodeSigners()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8286/files
  - new: https://git.openjdk.java.net/jdk/pull/8286/files/70618a17..c6318862

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=01-02

  Stats: 359585 lines in 5089 files changed: 236066 ins; 93423 del; 30096 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8286/head:pull/8286

PR: https://git.openjdk.java.net/jdk/pull/8286

From ssahoo at openjdk.java.net  Wed Jun  8 10:30:45 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 8 Jun 2022 10:30:45 GMT
Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v4]
In-Reply-To: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
References: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
Message-ID: <efgG9x6VbBm62WU4-YIM8m-89u5ifJWWbviBlV1Yhcc=.a265902a-7a66-4371-8f43-5f55d9994d5a@github.com>

> A Test updated to cover the getCodeSigners.

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

  8209935: Test to cover CodeSource.getCodeSigners()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8286/files
  - new: https://git.openjdk.java.net/jdk/pull/8286/files/c6318862..512cb615

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=02-03

  Stats: 144 lines in 2 files changed: 144 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8286/head:pull/8286

PR: https://git.openjdk.java.net/jdk/pull/8286

From weijun at openjdk.java.net  Wed Jun  8 13:52:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 8 Jun 2022 13:52:52 GMT
Subject: RFR: 6522064: Aliases from Microsoft CryptoAPI has bad character
 encoding
Message-ID: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>

Switch to wide char version of `CertGetNameString` to get the non-ASCII name.

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

Commit messages:
 - the fix

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

PR: https://git.openjdk.java.net/jdk/pull/9085

From weijun at openjdk.java.net  Wed Jun  8 16:30:01 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 8 Jun 2022 16:30:01 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
Message-ID: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>

On Tue, 7 Jun 2022 15:37:02 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security
>> 
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: 
>> 
>> open/src/java.base/share/classes/java/security
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge
>  - fourth iteration
>  - Merge
>  - Merge
>  - third iteration
>  - Merge
>  - Merge
>  - second iteration
>  - Merge
>  - Merge
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01

Some comments. Thanks for the hard work.

src/java.base/share/classes/java/security/MessageDigest.java line 306:

> 304:         } else {
> 305:             return Delegate.of((MessageDigestSpi)objs[0], algorithm,
> 306:             (Provider)objs[1]);

Indent this line.

src/java.base/share/classes/java/security/ProtectionDomain.java line 474:

> 472:                     return true;
> 473:                 } catch (SecurityException se) {
> 474:                     // fall through and return false

How about we just `return false` here and then there is no need for the `return false` at the end?

src/java.base/share/classes/java/security/ProtectionDomain.java line 474:

> 472:                     return true;
> 473:                 } catch (SecurityException se) {
> 474:                     // fall through and return false

How about we just `return false` here and then there is no need for the `return false` at the end?

src/java.base/share/classes/java/security/ProtectionDomain.java line 492:

> 490:                 Policy p = Policy.getPolicyNoCheck();
> 491:                 return p.getPermissions(ProtectionDomain.this);
> 492:             });

First, indent these lines. (or maybe my GitHub view has not reveals the indentation?).

Second, inline `p` then there is no need to `return`. Simply `() -> P.g.g(P)`.

src/java.base/share/classes/java/security/ProtectionDomain.java line 492:

> 490:                 Policy p = Policy.getPolicyNoCheck();
> 491:                 return p.getPermissions(ProtectionDomain.this);
> 492:             });

First, indent these lines. (or maybe my GitHub view has not reveals the indentation?).

Second, inline `p` then there is no need to `return`. Simply `() -> P.g.g(P)`.

src/java.base/share/classes/java/security/Provider.java line 1098:

> 1096:         boolean matches(String type, String algorithm) {
> 1097:             return (Objects.equals(this.type, type)) &&
> 1098:                 (Objects.equals(this.originalAlgorithm, algorithm));

In fact, I'm not sure why the original code is brave enough to use `==` instead of `equals`. If you do believe it's a real bug (and can write a regression test), let's fix it in a real bug fix. Otherwise, keep using `==` and add a comment saying it's correct.

src/java.base/share/classes/java/security/Provider.java line 1098:

> 1096:         boolean matches(String type, String algorithm) {
> 1097:             return (Objects.equals(this.type, type)) &&
> 1098:                 (Objects.equals(this.originalAlgorithm, algorithm));

In fact, I'm not sure why the original code is brave enough to use `==` instead of `equals`. If you do believe it's a real bug (and can write a regression test), let's fix it in a real bug fix. Otherwise, keep using `==` and add a comment saying it's correct.

src/java.base/share/classes/java/security/SecureClassLoader.java line 221:

> 219:         // only), and the fragment is not considered.
> 220:         CodeSourceKey key = new CodeSourceKey(cs);
> 221:         /* not used */

What is not used? `key1`? How about just rename it to `unused`?

src/java.base/share/classes/java/security/SecureClassLoader.java line 221:

> 219:         // only), and the fragment is not considered.
> 220:         CodeSourceKey key = new CodeSourceKey(cs);
> 221:         /* not used */

What is not used? `key1`? How about just rename it to `unused`?

src/java.base/share/classes/java/security/SecureClassLoader.java line 235:

> 233:     }
> 234: 
> 235:     private record CodeSourceKey(CodeSource cs) {

Really necessary?

src/java.base/share/classes/java/security/SecureClassLoader.java line 235:

> 233:     }
> 234: 
> 235:     private record CodeSourceKey(CodeSource cs) {

Really necessary?

src/java.base/share/classes/java/security/SecureRandom.java line 905:

> 903:         private static final Pattern pattern =
> 904:             Pattern.compile(
> 905:                 "\\s*([\\S&&[^:,]]*)(:([\\S&&[^,]]*))?\\s*(,(.*))?");

Don't quite understand this change. Can you explain?

src/java.base/share/classes/java/security/SecureRandom.java line 905:

> 903:         private static final Pattern pattern =
> 904:             Pattern.compile(
> 905:                 "\\s*([\\S&&[^:,]]*)(:([\\S&&[^,]]*))?\\s*(,(.*))?");

Don't quite understand this change. Can you explain?

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

> 258:         }
> 259: 
> 260:         return null;

If `entry` is always null, then we don't need to declare it at all.

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

> 258:         }
> 259: 
> 260:         return null;

If `entry` is always null, then we don't need to declare it at all.

src/java.base/share/classes/java/security/Signature.java line 271:

> 269:                 (algorithm + " Signature not available");
> 270:         }
> 271:         // try services until we find a Spi or a working Signature subclass

Is `Spi` pronounced `spy` or "S-P-I"?

src/java.base/share/classes/java/security/Signature.java line 271:

> 269:                 (algorithm + " Signature not available");
> 270:         }
> 271:         // try services until we find a Spi or a working Signature subclass

Is `Spi` pronounced `spy` or "S-P-I"?

src/java.base/share/classes/java/security/UnresolvedPermission.java line 369:

> 367:             this.certs != null && that.certs == null ||
> 368:             this.certs != null &&
> 369:                this.certs.length != that.certs.length) {

I see you keep a lot of parentheses in other places. For example, `(!r)`.

src/java.base/share/classes/java/security/UnresolvedPermission.java line 369:

> 367:             this.certs != null && that.certs == null ||
> 368:             this.certs != null &&
> 369:                this.certs.length != that.certs.length) {

I see you keep a lot of parentheses in other places. For example, `(!r)`.

src/java.base/share/classes/java/security/cert/CertPathValidator.java line 335:

> 333:         String cpvtype =
> 334:             AccessController.doPrivileged((PrivilegedAction<String>) () ->
> 335:                     Security.getProperty(CPV_TYPE));

See too many, maybe we need a dedicated method in `sun.security.util.SecurityProperties`?

src/java.base/share/classes/java/security/cert/CertPathValidator.java line 335:

> 333:         String cpvtype =
> 334:             AccessController.doPrivileged((PrivilegedAction<String>) () ->
> 335:                     Security.getProperty(CPV_TYPE));

See too many, maybe we need a dedicated method in `sun.security.util.SecurityProperties`?

src/java.base/share/classes/java/security/cert/LDAPCertStoreParameters.java line 34:

> 32:  * name and port number) to implementations of the LDAP {@code CertStore}
> 33:  * algorithm. However, if you are retrieving certificates or CRLs from
> 34:  * a ldap URI as specified by RFC 5280, use the

Isn't `ldap` pronounced `L-Dap`?

src/java.base/share/classes/java/security/cert/LDAPCertStoreParameters.java line 34:

> 32:  * name and port number) to implementations of the LDAP {@code CertStore}
> 33:  * algorithm. However, if you are retrieving certificates or CRLs from
> 34:  * a ldap URI as specified by RFC 5280, use the

Isn't `ldap` pronounced `L-Dap`?

src/java.base/share/classes/java/security/cert/PKIXBuilderParameters.java line 193:

> 191:     public String toString() {
> 192:         return "[\n" +
> 193:                 super.toString() +

Is `toString` necessary?

src/java.base/share/classes/java/security/cert/PKIXBuilderParameters.java line 193:

> 191:     public String toString() {
> 192:         return "[\n" +
> 193:                 super.toString() +

Is `toString` necessary?

src/java.base/share/classes/java/security/spec/ECPoint.java line 103:

> 101:         return obj instanceof ECPoint other
> 102:                 && ((Objects.equals(x, other.x))
> 103:                 && (Objects.equals(y, other.y)));

`x` and `y` will not be null unless this is `POINT_INFINITY`, but this is already checked in both `equals` and `hashCode`.

src/java.base/share/classes/java/security/spec/ECPoint.java line 103:

> 101:         return obj instanceof ECPoint other
> 102:                 && ((Objects.equals(x, other.x))
> 103:                 && (Objects.equals(y, other.y)));

`x` and `y` will not be null unless this is `POINT_INFINITY`, but this is already checked in both `equals` and `hashCode`.

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

PR: https://git.openjdk.java.net/jdk/pull/8319

From duke at openjdk.java.net  Wed Jun  8 17:40:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:40 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v18]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <1xVR4-ZIHnyfeei_7RmrCV8g8aVvzI3aGgUHIP8fZx4=.d4206519-b280-4021-8fbd-a2f46180e8d1@github.com>

> as title.

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

 - remove null check for Capacitiable in WhiteBoxResizeTest
 - Rename type variable per CSR request; minor spec wording change.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/98bfb0e1..bacc9ca8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=16-17

  Stats: 19 lines in 3 files changed: 0 ins; 13 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:40:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
Message-ID: <vl6R4iBqQ81oJiQqySRtRgivszdAVIbjkraflV3FgvA=.c18bd636-d10d-4acc-a273-f1aef8624f53@github.com>

On Wed, 1 Jun 2022 17:34:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 441:
> 
>> 439:         }
>> 440:     }
>> 441: 
> 
> This unifies the test cases between the Set and Map factories, which accomplishes the primary goal. Good.
> 
> The unification is achieved through classic object-oriented polymorphism, which works fine, though which is rather verbose. This could probably be reduced with some tinkering on the model, but it's probably reaching the point where additional tinkering on the model isn't worth it. I'm ok with sticking with this approach for now. Maybe we can clean it up later, or maybe not -- it's at least fairly straightforward.
> 
> One issue that contributes to the verbosity is the repeated null checking. The null checking enables the test code to proceed and end up with -1 as the capacity if there's a null in there somewhere. This will cause the assertion to fail. This is good in that it will call attention to itself (as opposed to silently passing or something). However, if the test cases are set up properly, they should never run into null. If the null checking weren't done, an unexpected null will throw NPE, which will be caught be the framework and reported as an error.
> 
> That seems perfectly fine to me, so I'd suggest simply removing the null checking. That would also reduce the bulkiness of infrastructure.

@stuart-marks done.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:49:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:38 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>

> as title.

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

  clean up Calendar

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/bacc9ca8..95d59b97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17-18

  Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:49:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:40 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
Message-ID: <EahYlBb628e0d_B3qOx1YbXqBmU0s5LKut12Z0nM_Qk=.39bbbf60-b42c-40ef-af52-3984487e176c@github.com>

On Wed, 1 Jun 2022 18:26:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> src/java.base/share/classes/java/util/Calendar.java line 2648:
> 
>> 2646:             set.add("gregory");
>> 2647:             set.add("buddhist");
>> 2648:             set.add("japanese");
> 
> This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

@naotoj Yes it can. I did a further clean up to it, please have a look.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From smarks at openjdk.java.net  Wed Jun  8 20:16:33 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 8 Jun 2022 20:16:33 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <66QMts98pQNLZzxi4BlX-aj13JkeVQeB8v8MNKVrpDY=.9b8680cc-f54e-4d7f-9b25-806b367d835b@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

Running tests and awaiting review from security team. Our internal test system is backlogged and tests might not complete in time to get into JDK 19.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From ascarpino at openjdk.java.net  Wed Jun  8 20:31:43 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 8 Jun 2022 20:31:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <kqydNmdnzsVvm6ITkeY9avGcwLvwp9C4T8HeILLC12U=.6d177140-6176-44b5-9b4b-bd78570a078d@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

I gave a quick look at the security files touched and seems straightforward. I didn't see any problems

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

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 22:21:37 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Wed, 8 Jun 2022 22:21:37 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <Xg_vOQmUTA6TAjuQJOUbG2PHnbmMUfzESExFKWXe8U4=.b83e40f8-2bf4-4373-bce4-f329c043d35d@github.com>

On Wed, 8 Jun 2022 15:46:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/MessageDigest.java line 306:
> 
>> 304:         } else {
>> 305:             return Delegate.of((MessageDigestSpi)objs[0], algorithm,
>> 306:             (Provider)objs[1]);
> 
> Indent this line.

done

> src/java.base/share/classes/java/security/ProtectionDomain.java line 474:
> 
>> 472:                     return true;
>> 473:                 } catch (SecurityException se) {
>> 474:                     // fall through and return false
> 
> How about we just `return false` here and then there is no need for the `return false` at the end?

done

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

PR: https://git.openjdk.java.net/jdk/pull/8319

From duke at openjdk.java.net  Wed Jun  8 22:25:40 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Wed, 8 Jun 2022 22:25:40 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <Sk8YBiVmsZ_wyxezUW9j2L2pi2alcfJIY0ygJL7ucKI=.2ebc25de-ffec-4d03-b3a8-359afa4ef510@github.com>

On Wed, 8 Jun 2022 15:50:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/ProtectionDomain.java line 492:
> 
>> 490:                 Policy p = Policy.getPolicyNoCheck();
>> 491:                 return p.getPermissions(ProtectionDomain.this);
>> 492:             });
> 
> First, indent these lines. (or maybe my GitHub view has not reveals the indentation?).
> 
> Second, inline `p` then there is no need to `return`. Simply `() -> P.g.g(P)`.

I made your suggested change. My viewer shows the indented lines. Go figure.

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

PR: https://git.openjdk.java.net/jdk/pull/8319

From duke at openjdk.java.net  Wed Jun  8 22:29:39 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Wed, 8 Jun 2022 22:29:39 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <wBZ-J2bU5sm6YMeN04Hy6LDLPoZFX2e7JFZmvZxYOOA=.2afa0aa3-82a5-4227-96cb-807cc63b7e91@github.com>

On Wed, 8 Jun 2022 16:12:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/cert/LDAPCertStoreParameters.java line 34:
> 
>> 32:  * name and port number) to implementations of the LDAP {@code CertStore}
>> 33:  * algorithm. However, if you are retrieving certificates or CRLs from
>> 34:  * a ldap URI as specified by RFC 5280, use the
> 
> Isn't `ldap` pronounced `L-Dap`?

You are right. IntelliJ was wrong and I didn't catch it.

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

PR: https://git.openjdk.java.net/jdk/pull/8319

From duke at openjdk.java.net  Wed Jun  8 22:59:40 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Wed, 8 Jun 2022 22:59:40 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <y2M64aVGQxMjQvkV8mJrIgeiixzg30Av9om6dr_bX94=.e9952404-e48c-4b2b-bb60-8511a844c850@github.com>

On Wed, 8 Jun 2022 16:12:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/cert/PKIXBuilderParameters.java line 193:
> 
>> 191:     public String toString() {
>> 192:         return "[\n" +
>> 193:                 super.toString() +
> 
> Is `toString` necessary?

No it's not necessary. I had some discussion with Brad and others about boxing vs unboxing. The same byte code is generated either way, so to box or unbox is a matter of personal preference.

> src/java.base/share/classes/java/security/spec/ECPoint.java line 103:
> 
>> 101:         return obj instanceof ECPoint other
>> 102:                 && ((Objects.equals(x, other.x))
>> 103:                 && (Objects.equals(y, other.y)));
> 
> `x` and `y` will not be null unless this is `POINT_INFINITY`, but this is already checked in both `equals` and `hashCode`.

I'm reversing IntelliJ's suggested fix since it really doesn't fix anything.

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

PR: https://git.openjdk.java.net/jdk/pull/8319

From rhalade at openjdk.java.net  Thu Jun  9 00:41:04 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 9 Jun 2022 00:41:04 GMT
Subject: RFR: 8224768: Test ActalisCA.java fails
Message-ID: <eY0fKRqxJMK8RybxLVP-3VKnE5yWJN3bweb_gAISL2Q=.323ef75b-e65d-4e54-b3bc-f004ea222690@github.com>

Updated with new test artifacts from CA.

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

Commit messages:
 - 8224768: Test ActalisCA.java fails

Changes: https://git.openjdk.java.net/jdk/pull/9097/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9097&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8224768
  Stats: 199 lines in 2 files changed: 9 ins; 36 del; 154 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9097.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9097/head:pull/9097

PR: https://git.openjdk.java.net/jdk/pull/9097

From duke at openjdk.java.net  Thu Jun  9 01:54:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 9 Jun 2022 01:54:37 GMT
Subject: Integrated: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <uBGmXlQd9TXwXKbiDcrVcLUktKK4rTenr6JRZx7MBjA=.9a961a01-5109-4e38-8594-c3413bdf0c8c@github.com>

On Tue, 19 Apr 2022 18:00:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> as title.

This pull request has now been integrated.

Changeset: e01cd7c3
Author:    XenoAmess <xenoamess at gmail.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e01cd7c3ed923cd19509fc972ba6e4aa2991289f
Stats:     154 lines in 29 files changed: 107 ins; 7 del; 40 mod

8284780: Need methods to create pre-sized HashSet and LinkedHashSet

Reviewed-by: naoto, bpb, dfuchs, ascarpino

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From rhalade at openjdk.java.net  Thu Jun  9 17:38:52 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 9 Jun 2022 17:38:52 GMT
Subject: RFR: 8288132: Update test artifacts in QuoVadis CA interop tests
Message-ID: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>

Updated test artifacts. Test will continue to fail intermittently with what appears to be issue in CA infra. JDK-8277855 will track it.

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

Commit messages:
 - 8288132: Update test artifacts in QuoVadis CA interop tests

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

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

From wetmore at openjdk.java.net  Thu Jun  9 18:55:01 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 9 Jun 2022 18:55:01 GMT
Subject: RFR: 8277307: Pre shared key sent under both session_ticket and
 pre_shared_key extensions [v2]
In-Reply-To: <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
References: <WebKhgdHJ1mPjVfTXw5ZkgLYPYlqMy3q_fHBd9SRR2g=.9243a0d7-6a42-44e3-9aae-cd5860820770@github.com>
 <HSrBA9iBhw3Ch_Nba8qEmUyWkB8mTNCISQFbq738RK4=.41020e81-e0de-4bcb-bcce-7b99e8b41440@github.com>
Message-ID: <6G1zDaaXw1yQkRKkYmwegHMEPaUHf6VqGFHPJMULMaM=.7506e2df-a1ec-4f5b-89d1-2b58293034e0@github.com>

On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   different check for TLS13

A little late to this review as it's already been pushed, but I would have suggested leaving the `return new SessionTicketSpec().getEncoded();` as it keeps the encapsulation more clear.  Otherwise, it looks good.

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

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

From rhalade at openjdk.java.net  Thu Jun  9 19:07:38 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 9 Jun 2022 19:07:38 GMT
Subject: RFR: 8271838: AmazonCA.java interop test fails
Message-ID: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>

Updated test certificates to new from CA. I did a loop run of this test and don't see the intermittent failure anymore.

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

Commit messages:
 - 8271838: AmazonCA.java interop test fails

Changes: https://git.openjdk.org/jdk/pull/9111/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9111&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8271838
  Stats: 252 lines in 1 file changed: 7 ins; 50 del; 195 mod
  Patch: https://git.openjdk.org/jdk/pull/9111.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9111/head:pull/9111

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

From mullan at openjdk.java.net  Thu Jun  9 21:08:05 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 9 Jun 2022 21:08:05 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v2]
In-Reply-To: <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
Message-ID: <8CSSGPBXqJ_stHGZ_lxOszuj7gbZfGRREFAFxebwXdQ=.b22f70ab-6fa9-4d13-9d6a-dfaccc898588@github.com>

On Tue, 7 Jun 2022 20:52:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Inconsistent entries test
>  - Inconsistent entries test

src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 202:

> 200:             if (!processedPermissions.isEmpty()) {
> 201:                 throw new ParsingException(st.lineno(), "Inconsistent policy");
> 202:             }

Instead of setting the `allPermEntryFound` flag, what if you instead put an entry for `CryptoAllPermission.ALG_NAME` in `processedPermissions` here. Then if there are more entries after this, I think `isConsistent` will catch it in the following code:


        if (processedPermissions.containsKey(CryptoAllPermission.ALG_NAME)) {
            return false;
        }

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

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

From mullan at openjdk.java.net  Thu Jun  9 21:19:04 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 9 Jun 2022 21:19:04 GMT
Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v4]
In-Reply-To: <efgG9x6VbBm62WU4-YIM8m-89u5ifJWWbviBlV1Yhcc=.a265902a-7a66-4371-8f43-5f55d9994d5a@github.com>
References: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
 <efgG9x6VbBm62WU4-YIM8m-89u5ifJWWbviBlV1Yhcc=.a265902a-7a66-4371-8f43-5f55d9994d5a@github.com>
Message-ID: <cdV3gf9nE1l6n-4-5PFGHoxyxsCLTX_WV93SG6jihvw=.83751e06-945f-49bc-9317-dad7adc3a0e0@github.com>

On Wed, 8 Jun 2022 10:30:45 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A Test updated to cover the getCodeSigners.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8209935: Test to cover CodeSource.getCodeSigners()

Marked as reviewed by mullan (Reviewer).

test/jdk/java/security/CodeSource/CertsMatch.java line 27:

> 25:  * @test
> 26:  * @bug 6299163
> 27:  * @summary REGRESSION: java.security.CodeSource#equals not symmetric

I think you should remove this line about "REGRESSION" as the summary is supposed to be about what the test is testing. Suggest changing this to summarize what methods are being tested.

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

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

From weijun at openjdk.java.net  Thu Jun  9 21:43:32 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 9 Jun 2022 21:43:32 GMT
Subject: RFR: 8287178: IntegerModuloP::multiplicativeInverse returns 0 for 0
Message-ID: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>

Add comment to the method.

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

Commit messages:
 - add comment

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

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

From jnimeh at openjdk.java.net  Thu Jun  9 22:34:07 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 9 Jun 2022 22:34:07 GMT
Subject: RFR: 8287178: IntegerModuloP::multiplicativeInverse returns 0 for
 0
In-Reply-To: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
References: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
Message-ID: <eklAmJ_STjMmJX-tjJxJ8_jISx7mnfWc7gc54qL9_uA=.18585008-aaa7-4527-9ee9-4ebb912a9e03@github.com>

On Thu, 9 Jun 2022 21:34:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add comment to the method.

src/java.base/share/classes/sun/security/util/math/IntegerModuloP.java line 161:

> 159:         // This method is used in 2 cases:
> 160:         // 1. To calculate the inverse of a number in ECDSAOperations,
> 161:         //    this number must be non zero (modulus p).

Should that be "modulo p"?  Other than that it looks good to me.

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

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

From hchao at openjdk.java.net  Thu Jun  9 22:58:03 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 9 Jun 2022 22:58:03 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v2]
In-Reply-To: <8CSSGPBXqJ_stHGZ_lxOszuj7gbZfGRREFAFxebwXdQ=.b22f70ab-6fa9-4d13-9d6a-dfaccc898588@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
 <8CSSGPBXqJ_stHGZ_lxOszuj7gbZfGRREFAFxebwXdQ=.b22f70ab-6fa9-4d13-9d6a-dfaccc898588@github.com>
Message-ID: <9V16GIkLalytWViCmZBiwMjsSWzrQzmRD99J08QLqME=.94bc91b6-d960-4a49-9283-97bc32c052e7@github.com>

On Thu, 9 Jun 2022 21:00:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Inconsistent entries test
>>  - Inconsistent entries test
>
> src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 202:
> 
>> 200:             if (!processedPermissions.isEmpty()) {
>> 201:                 throw new ParsingException(st.lineno(), "Inconsistent policy");
>> 202:             }
> 
> Instead of setting the `allPermEntryFound` flag, what if you instead put an entry for `CryptoAllPermission.ALG_NAME` in `processedPermissions` here. Then if there are more entries after this, I think `isConsistent` will catch it in the following code:
> 
> 
>         if (processedPermissions.containsKey(CryptoAllPermission.ALG_NAME)) {
>             return false;
>         }

Yes, with the `allPermEntryFound` flag, the current fix would not require to put the `javax.crypto.CryptoAllPermission` entry in `processedPermissions`. So `processedPermissions` will be used to keep `javax.crypto.CryptoPermission` entries and is updated by `isConsistent()`, and no need to deal with `javax.crypto.CryptoAllPermission` entry. I?d like to keep it as-is if there is no objection.

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

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

From weijun at openjdk.java.net  Thu Jun  9 23:14:48 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 9 Jun 2022 23:14:48 GMT
Subject: RFR: 8287178: IntegerModuloP::multiplicativeInverse returns 0 for
 0 [v2]
In-Reply-To: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
References: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
Message-ID: <A_zB_PfSNbtsw9igbFLxD_pXNbQWdandqZ0ks8-4_6M=.6e9ac4a6-3e2d-410e-8b29-512df31451c1@github.com>

> Add comment to the method.

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

  verb

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9115/files
  - new: https://git.openjdk.org/jdk/pull/9115/files/36741bba..15ef85fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9115&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9115&range=00-01

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

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

From jnimeh at openjdk.java.net  Thu Jun  9 23:14:48 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 9 Jun 2022 23:14:48 GMT
Subject: RFR: 8287178: IntegerModuloP::multiplicativeInverse returns 0 for
 0 [v2]
In-Reply-To: <A_zB_PfSNbtsw9igbFLxD_pXNbQWdandqZ0ks8-4_6M=.6e9ac4a6-3e2d-410e-8b29-512df31451c1@github.com>
References: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
 <A_zB_PfSNbtsw9igbFLxD_pXNbQWdandqZ0ks8-4_6M=.6e9ac4a6-3e2d-410e-8b29-512df31451c1@github.com>
Message-ID: <D7nDGlBH5RwWZ2Br8gMnxzQ4X3y3i0-WpjO_yjq0Zzs=.e04c6654-c7aa-4987-9c59-9754492f2cf5@github.com>

On Thu, 9 Jun 2022 23:10:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add comment to the method.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   verb

Thanks, LGTM.

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

Marked as reviewed by jnimeh (Reviewer).

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

From weijun at openjdk.java.net  Thu Jun  9 23:14:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 9 Jun 2022 23:14:49 GMT
Subject: RFR: 8287178: IntegerModuloP::multiplicativeInverse returns 0 for
 0 [v2]
In-Reply-To: <eklAmJ_STjMmJX-tjJxJ8_jISx7mnfWc7gc54qL9_uA=.18585008-aaa7-4527-9ee9-4ebb912a9e03@github.com>
References: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
 <eklAmJ_STjMmJX-tjJxJ8_jISx7mnfWc7gc54qL9_uA=.18585008-aaa7-4527-9ee9-4ebb912a9e03@github.com>
Message-ID: <rI0BTxb2YMHO2xLoth_0qi0FjW9jYRE_plhKO9p2ne4=.3acadb73-abee-4633-8a1a-05bf6b5ac5e9@github.com>

On Thu, 9 Jun 2022 22:29:36 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   verb
>
> src/java.base/share/classes/sun/security/util/math/IntegerModuloP.java line 161:
> 
>> 159:         // This method is used in 2 cases:
>> 160:         // 1. To calculate the inverse of a number in ECDSAOperations,
>> 161:         //    this number must be non zero (modulus p).
> 
> Should that be "modulo p"?  Other than that it looks good to me.

Yes, it's a verb here.

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

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

From ssahoo at openjdk.java.net  Fri Jun 10 05:28:35 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 10 Jun 2022 05:28:35 GMT
Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v5]
In-Reply-To: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
References: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
Message-ID: <yFc4V1nKEMiwyM8PaKgE2_8aveYDly9hrrXWs_-cAU0=.60a85a72-e53f-4c12-8ea9-418eec5ef6db@github.com>

> A Test updated to cover the getCodeSigners.

Sibabrata Sahoo has updated the pull request incrementally with two additional commits since the last revision:

 - 8209935: Test to cover CodeSource.getCodeSigners()
 - 8209935: Test to cover CodeSource.getCodeSigners()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8286/files
  - new: https://git.openjdk.org/jdk/pull/8286/files/512cb615..a0c1d070

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=03-04

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

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

From ssahoo at openjdk.java.net  Fri Jun 10 05:28:35 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 10 Jun 2022 05:28:35 GMT
Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v4]
In-Reply-To: <cdV3gf9nE1l6n-4-5PFGHoxyxsCLTX_WV93SG6jihvw=.83751e06-945f-49bc-9317-dad7adc3a0e0@github.com>
References: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
 <efgG9x6VbBm62WU4-YIM8m-89u5ifJWWbviBlV1Yhcc=.a265902a-7a66-4371-8f43-5f55d9994d5a@github.com>
 <cdV3gf9nE1l6n-4-5PFGHoxyxsCLTX_WV93SG6jihvw=.83751e06-945f-49bc-9317-dad7adc3a0e0@github.com>
Message-ID: <F2eS0ibjGXPEoI49Eo5toJYAuSnriagU5Jsx09VLBfE=.35aaa884-448f-405d-9d0f-54af94449706@github.com>

On Thu, 9 Jun 2022 21:12:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8209935: Test to cover CodeSource.getCodeSigners()
>
> test/jdk/java/security/CodeSource/CertsMatch.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 6299163
>> 27:  * @summary REGRESSION: java.security.CodeSource#equals not symmetric
> 
> I think you should remove this line about "REGRESSION" as the summary is supposed to be about what the test is testing. Suggest changing this to summarize what methods are being tested.

Updated the summary.

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

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

From tanksherman27 at gmail.com  Fri Jun 10 07:01:30 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 10 Jun 2022 15:01:30 +0800
Subject: Redefined EXIT_FAILURE macro in
 /java.security.jgss/windows/native/libw2k_lsa_auth/NativeCreds.c
Message-ID: <CAP2b4GM8tjcoKtQobs2a0C6nRKGYkuvRAvw7_A8z=wh1taVEEA@mail.gmail.com>

In NativeCreds.c there seems to be a redefined macro for EXIT_FAILURE (line
51)

#undef LSA_SUCCESS
#define LSA_SUCCESS(Status) ((Status) >= 0)
#define EXIT_FAILURE -1 // mdu <-----

As far as I can see, it's a redundant definition not used anywhere other
than in a call to ExitProcess that's been commented out on line 826:

if (0 == dwRes) {
    printf("LSA: FormatMessage failed with %d\n", GetLastError());
    // ExitProcess(EXIT_FAILURE);
}

This definition is also not correct, since EXIT_FAILURE on Windows is
defined as 1, not -1. Would it be safe to remove this unused macro
definition?

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220610/457d7ff4/attachment.htm>

From lancea at openjdk.java.net  Fri Jun 10 10:09:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 10 Jun 2022 10:09:05 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <TR5_xxZU3neGX93MjEkHC9l9rg9pHA5T0SSh8Km62sQ=.beac14b4-604c-45e7-b446-e73cee8d7fea@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

The changes to doneWithMeta() seem reasonable and the other changes remove unused code so look OK to me

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

Marked as reviewed by lancea (Reviewer).

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

From alanb at openjdk.java.net  Fri Jun 10 13:18:59 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 13:18:59 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

We have to be cautious about leaking security sensitive configuration in exception messages. Can you look at the security property jdk.includeInException (conf/security/java.security) and usages in the JDK for ideas on how this might be implemented as opt-in?

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

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

From mullan at openjdk.java.net  Fri Jun 10 13:20:01 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 13:20:01 GMT
Subject: RFR: 8271838: AmazonCA.java interop test fails
In-Reply-To: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>
References: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>
Message-ID: <YCkdUayRd-dj4eniM2fLH8wV7RffN_fnK9DbPNOYVTo=.596bc53f-66fe-4bf2-8908-d35f3b4439b6@github.com>

On Thu, 9 Jun 2022 18:59:36 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated test certificates to new from CA. I did a loop run of this test and don't see the intermittent failure anymore.

Marked as reviewed by mullan (Reviewer).

test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java line 107:

> 105:     // Serial number: 75a5dd4b767bedc94a4239da65ed9dfef8218
> 106:     // Valid from: Fri Dec 17 12:21:50 PST 2021 until: Tue Jan 17 12:21:50
> 107:     // PST 2023

Can you put the "PST 2023" at the end of the previous line instead of on a new line? I think it would be more readable. Same comment applies to all the test certificates.

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

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

From mbaesken at openjdk.java.net  Fri Jun 10 13:44:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Jun 2022 13:44:58 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>
Message-ID: <HZqbf5hZnPvSktuITPwsL0fqy_JUQVajPwoCbt587aE=.26378aa5-ac65-4b14-9109-3e0b29df0763@github.com>

On Fri, 10 Jun 2022 13:15:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We have to be cautious about leaking security sensitive configuration in exception messages. Can you look at the security property jdk.includeInException (conf/security/java.security) and usages in the JDK for ideas on how this might be implemented as opt-in?

Hi Alan ,   sure we could use something like the already existing hostInfo of property jdk.includeInException 
      private static final boolean enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo");
and make the enhancement optional/switchable this way.
On the other hand we already print the url  (_**Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz**_ )  in the existing exception text so I wonder what additional problem the added info would bring? That's why I  did not use the property so far.
But if you think there could be special cases were it would be problematic to have the enhancement, I'll add the usage of the property.

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

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

From alanb at openjdk.java.net  Fri Jun 10 14:03:00 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 14:03:00 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <HZqbf5hZnPvSktuITPwsL0fqy_JUQVajPwoCbt587aE=.26378aa5-ac65-4b14-9109-3e0b29df0763@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>
 <HZqbf5hZnPvSktuITPwsL0fqy_JUQVajPwoCbt587aE=.26378aa5-ac65-4b14-9109-3e0b29df0763@github.com>
Message-ID: <f0SyiH6_o7EpnNJDi4xTEHopgZKhryJumz7Ky9fLScQ=.5243a696-2250-4c29-b2cd-0dcc0e5f96ce@github.com>

On Fri, 10 Jun 2022 13:41:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan , sure we could use something like the already existing hostInfo of property jdk.includeInException private static final boolean enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo"); and make the enhancement optional/switchable this way. On the other hand we already print the url (_**Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz**_ ) in the existing exception text so I wonder what additional problem the added info would bring? That's why I did not use the property so far. But if you think there could be special cases were it would be problematic to have the enhancement, I'll add the usage of the property.

This is a security sensitive area and not possible to discuss all issues in JBS or in this PR. If this code is changed then it will require someone from security-dev to review.

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

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

From dfuchs at openjdk.java.net  Fri Jun 10 14:22:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 10 Jun 2022 14:22:58 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

`URISyntaxException`/`MalformedURLException` usually contains the whole URL - so in this case, because we're parsing a URL, I believe the added information would not leak more sensitive data - especially since I'd expect URI.getHost() to be always `null` and `URI.getPort()` to be always `-1` in this case. 
That is - this exception is thrown when the authority is parsed as a reg_name, as opposed to server-base, because the provided host name (or what looks like a host name) contains a character that is not allowed by java.net.URI in a host name.


jshell> URI.create("ldap://a_b.com:389/foo");
$1 ==> ldap://a_b.com:389/foo

jshell> $1.getAuthority()
$2 ==> "a_b.com:389"

jshell> $1.getHost()
$3 ==> null


As a point of comparison, here is what URISyntaxException looks like if the authority contains a character which is not legal at all in authority:


jshell> new URI("ldap://a_%b.com:389/foo");
|  Exception java.net.URISyntaxException: Malformed escape pair at index 9: ldap://a_%b.com:389/foo
|        at URI$Parser.fail (URI.java:2973)


I agree we should wait for someone from security-dev to chime in though.

I might question whether the added "null:-1" information is really helpful, or just as confusing however.

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

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

From mullan at openjdk.java.net  Fri Jun 10 14:35:04 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 14:35:04 GMT
Subject: RFR: 8288132: Update test artifacts in QuoVadis CA interop tests
In-Reply-To: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>
References: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>
Message-ID: <DTLB3daZLTxEfQyOv8T8BAR_84sCyzaAU3WALduOIAE=.ca51a177-4290-4af3-9b28-6e00cdcabf3d@github.com>

On Thu, 9 Jun 2022 17:31:29 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated test artifacts. Test will continue to fail intermittently with what appears to be issue in CA infra. JDK-8277855 will track it.

Marked as reviewed by mullan (Reviewer).

test/jdk/security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java line 62:

> 60: 
> 61:     // Owner: CN=DigiCert QuoVadis TLS ICA QV Root CA 1 G3, O="DigiCert,
> 62:     // Inc", C=US

Can you put the "Inc", C=US" at the end of the previous line instead of on a new line, or alternatively indent it so it is under "CN:"? I think it would be more readable. Same comment applies to all the test certificates.

test/jdk/security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java line 66:

> 64:     // Serial number: 2837d5c3c2b57294becf99afe8bbdcd1bb0b20f1
> 65:     // Valid from: Wed Jan 06 12:50:51 PST 2021 until: Sat Jan 04 12:50:51
> 66:     // PST 2031

Can you put the "PST 2031" at the end of the previous line instead of on a new line? I think it would be more readable. Same comment applies to all the test certificates.

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

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

From rhalade at openjdk.java.net  Fri Jun 10 14:53:26 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 14:53:26 GMT
Subject: RFR: 8271838: AmazonCA.java interop test fails [v2]
In-Reply-To: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>
References: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>
Message-ID: <J0enmkOoTPrK7yWHzPy2B2jMg2W6wYzwncOh1GOMFMk=.dc90cffb-2c0e-4bb2-9b97-9ad6749f040f@github.com>

> Updated test certificates to new from CA. I did a loop run of this test and don't see the intermittent failure anymore.

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

  adjust hard wrap to 90 chars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9111/files
  - new: https://git.openjdk.org/jdk/pull/9111/files/4a248529..592679bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9111&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9111&range=00-01

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

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

From rhalade at openjdk.java.net  Fri Jun 10 14:53:26 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 14:53:26 GMT
Subject: Integrated: 8271838: AmazonCA.java interop test fails
In-Reply-To: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>
References: <-UyTEdSuz0zshsH8Do09y5t7tg-cD-x7xAopnHsLvPk=.99607849-b47c-4df9-9632-82135d420b10@github.com>
Message-ID: <7vAKQOxjtdmPCULE3TJateH6tbhBy-sP8RIa2o_OoRo=.a9eb6c80-b904-4394-b1f4-c30d125f1379@github.com>

On Thu, 9 Jun 2022 18:59:36 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated test certificates to new from CA. I did a loop run of this test and don't see the intermittent failure anymore.

This pull request has now been integrated.

Changeset: 512db0ff
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/512db0ff31a0a1a2bd8805964ba3d06e2cbfb9e9
Stats:     245 lines in 1 file changed: 0 ins; 51 del; 194 mod

8271838: AmazonCA.java interop test fails

Reviewed-by: mullan

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

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

From rhalade at openjdk.java.net  Fri Jun 10 15:00:47 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 15:00:47 GMT
Subject: RFR: 8288132: Update test artifacts in QuoVadis CA interop tests
 [v2]
In-Reply-To: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>
References: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>
Message-ID: <TyBPDiGjDYdp05_ECF8n-JLsyVenL1uoMrgxGo5OPUg=.a344c8fe-6198-4831-8ae2-9e96377a7c1d@github.com>

> Updated test artifacts. Test will continue to fail intermittently with what appears to be issue in CA infra. JDK-8277855 will track it.

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

  Adjust hard wrap to 90 chars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9110/files
  - new: https://git.openjdk.org/jdk/pull/9110/files/c21d7fb2..74159299

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9110&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9110&range=00-01

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

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

From rhalade at openjdk.java.net  Fri Jun 10 15:03:58 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 15:03:58 GMT
Subject: Integrated: 8288132: Update test artifacts in QuoVadis CA interop
 tests
In-Reply-To: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>
References: <za_AkqgFg8Vu09kx2V0cqXoRrWoXkVJR4_m1iT3aNJM=.cf309906-e792-4662-9858-3a3c05a3a1c5@github.com>
Message-ID: <hfY95SYHPEDQ5POw3evJ4PXBsOf8HDfRCNla7tv4JNY=.c6cf082b-5393-4536-aa12-b5cd7dc598c7@github.com>

On Thu, 9 Jun 2022 17:31:29 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated test artifacts. Test will continue to fail intermittently with what appears to be issue in CA infra. JDK-8277855 will track it.

This pull request has now been integrated.

Changeset: 3ee1e605
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ee1e60595171be0dd8bda47d96e0a1268cdc461
Stats:     191 lines in 1 file changed: 21 ins; 0 del; 170 mod

8288132: Update test artifacts in QuoVadis CA interop tests

Reviewed-by: mullan

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

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

From rhalade at openjdk.java.net  Fri Jun 10 15:09:58 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 15:09:58 GMT
Subject: RFR: 8224768: Test ActalisCA.java fails [v2]
In-Reply-To: <eY0fKRqxJMK8RybxLVP-3VKnE5yWJN3bweb_gAISL2Q=.323ef75b-e65d-4e54-b3bc-f004ea222690@github.com>
References: <eY0fKRqxJMK8RybxLVP-3VKnE5yWJN3bweb_gAISL2Q=.323ef75b-e65d-4e54-b3bc-f004ea222690@github.com>
Message-ID: <u7NWqNiPUmFtcBDy2GV1FJN5OxaFnuEMWVWL5ZW8Ki0=.be7b1fc6-1981-4efa-b462-3bbe0e55c67b@github.com>

> Updated with new test artifacts from CA.

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

  Adjust hard wrap to 90 chars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9097/files
  - new: https://git.openjdk.org/jdk/pull/9097/files/d800a30d..5bb68432

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9097&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9097&range=00-01

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

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

From mullan at openjdk.java.net  Fri Jun 10 15:31:05 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 15:31:05 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v2]
In-Reply-To: <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
Message-ID: <kN0ltJo_Q7W_2Z2QTY9DLQsxyh9cwjKkHVRIstjPHlE=.ef23b2e7-4ab7-40e1-bfcd-15347bb30884@github.com>

On Tue, 7 Jun 2022 20:52:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Inconsistent entries test
>  - Inconsistent entries test

Marked as reviewed by mullan (Reviewer).

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 2:

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

Update year to 2022.

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

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

From mullan at openjdk.java.net  Fri Jun 10 15:31:07 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 15:31:07 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v2]
In-Reply-To: <9V16GIkLalytWViCmZBiwMjsSWzrQzmRD99J08QLqME=.94bc91b6-d960-4a49-9283-97bc32c052e7@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <NZ9tmIF_Y0uqHtf4qk3iAftl0dz3pBEys738uhZMrwc=.b1ccbd43-9b18-4c64-b61f-a587550fd902@github.com>
 <8CSSGPBXqJ_stHGZ_lxOszuj7gbZfGRREFAFxebwXdQ=.b22f70ab-6fa9-4d13-9d6a-dfaccc898588@github.com>
 <9V16GIkLalytWViCmZBiwMjsSWzrQzmRD99J08QLqME=.94bc91b6-d960-4a49-9283-97bc32c052e7@github.com>
Message-ID: <NZ_r-jQK3Efopq8nlum4MA252MwPLFP4dsn_ExhSbU4=.8e722208-1b97-4c4f-9adc-240bef0e9b86@github.com>

On Thu, 9 Jun 2022 22:54:20 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 202:
>> 
>>> 200:             if (!processedPermissions.isEmpty()) {
>>> 201:                 throw new ParsingException(st.lineno(), "Inconsistent policy");
>>> 202:             }
>> 
>> Instead of setting the `allPermEntryFound` flag, what if you instead put an entry for `CryptoAllPermission.ALG_NAME` in `processedPermissions` here. Then if there are more entries after this, I think `isConsistent` will catch it in the following code:
>> 
>> 
>>         if (processedPermissions.containsKey(CryptoAllPermission.ALG_NAME)) {
>>             return false;
>>         }
>
> Yes, with the `allPermEntryFound` flag, the current fix would not require to put the `javax.crypto.CryptoAllPermission` entry in `processedPermissions`. So `processedPermissions` will be used to keep `javax.crypto.CryptoPermission` entries and is updated by `isConsistent()`, and no need to deal with `javax.crypto.CryptoAllPermission` entry. I?d like to keep it as-is if there is no objection.

Sure, I think that's reasonable.

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

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

From hchao at openjdk.java.net  Fri Jun 10 16:19:05 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 10 Jun 2022 16:19:05 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v3]
In-Reply-To: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
Message-ID: <9whOl5uVwwewMVEdl4xzhx0sbztWUl1YpgtLGtkvNVg=.ff2b9bf5-c9fc-4544-bca4-dc1746b8d55e@github.com>

> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
> Ran MACH5 tier1 and tier2 without failures.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Fixed copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8985/files
  - new: https://git.openjdk.org/jdk/pull/8985/files/d8950465..2e8f5d95

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8985&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8985&range=01-02

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

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

From mullan at openjdk.java.net  Fri Jun 10 17:10:04 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 17:10:04 GMT
Subject: RFR: 8224768: Test ActalisCA.java fails [v2]
In-Reply-To: <u7NWqNiPUmFtcBDy2GV1FJN5OxaFnuEMWVWL5ZW8Ki0=.be7b1fc6-1981-4efa-b462-3bbe0e55c67b@github.com>
References: <eY0fKRqxJMK8RybxLVP-3VKnE5yWJN3bweb_gAISL2Q=.323ef75b-e65d-4e54-b3bc-f004ea222690@github.com>
 <u7NWqNiPUmFtcBDy2GV1FJN5OxaFnuEMWVWL5ZW8Ki0=.be7b1fc6-1981-4efa-b462-3bbe0e55c67b@github.com>
Message-ID: <nOct-aaMbap5LzMZMKSp92XI9bDKuEFVFJIvRnWdvws=.ab6bc44a-6b28-45d2-a31d-42cd2b904daf@github.com>

On Fri, 10 Jun 2022 15:09:58 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Updated with new test artifacts from CA.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust hard wrap to 90 chars

Marked as reviewed by mullan (Reviewer).

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

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

From rhalade at openjdk.java.net  Fri Jun 10 17:30:05 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 17:30:05 GMT
Subject: Integrated: 8224768: Test ActalisCA.java fails
In-Reply-To: <eY0fKRqxJMK8RybxLVP-3VKnE5yWJN3bweb_gAISL2Q=.323ef75b-e65d-4e54-b3bc-f004ea222690@github.com>
References: <eY0fKRqxJMK8RybxLVP-3VKnE5yWJN3bweb_gAISL2Q=.323ef75b-e65d-4e54-b3bc-f004ea222690@github.com>
Message-ID: <G0li9qktccgClh6_alvNLhOxaIlDUT7NaCs8yV8TuVM=.1764d75d-c3ed-49a9-8442-41db9bea2225@github.com>

On Thu, 9 Jun 2022 00:33:27 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated with new test artifacts from CA.

This pull request has now been integrated.

Changeset: c6dd2ab9
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6dd2ab9d72298b1e25ee811b1e200f6a0fdc933
Stats:     198 lines in 2 files changed: 8 ins; 38 del; 152 mod

8224768: Test ActalisCA.java fails

Reviewed-by: mullan

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

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

From rhalade at openjdk.java.net  Fri Jun 10 17:36:03 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 17:36:03 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v3]
In-Reply-To: <9whOl5uVwwewMVEdl4xzhx0sbztWUl1YpgtLGtkvNVg=.ff2b9bf5-c9fc-4544-bca4-dc1746b8d55e@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <9whOl5uVwwewMVEdl4xzhx0sbztWUl1YpgtLGtkvNVg=.ff2b9bf5-c9fc-4544-bca4-dc1746b8d55e@github.com>
Message-ID: <FCLaFQJdt-ZkVeGL0Ld67uy1GXI1z7iM9pJS3gowF4A=.da4a7975-559d-4475-bb4e-502db62f56fe@github.com>

On Fri, 10 Jun 2022 16:19:05 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 38:

> 36: import java.security.Security;
> 37: 
> 38: // This is a manual test to test a custom ?default_local.policy" containing inconsistent entries

Thanks for the instructions. For manual test, I would rather have these as a System.out on test start than a comment here. This helps engineers who look at jtr file for failure analysis as they generally won't refer test source code to understand missing steps.

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

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

From mullan at openjdk.java.net  Fri Jun 10 18:35:00 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 18:35:00 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <ZLUrevxM3pod59jvPmZcD6EncfEJR6iMlEPpH2U7cWI=.60608b01-8254-42eb-bdb4-81fe0949b023@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

I'll take a look from the security side but may need a few days to review and possibly collaborate with others if I have concerns.

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

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

From duke at openjdk.java.net  Fri Jun 10 20:56:10 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 10 Jun 2022 20:56:10 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <SG-YlIuSwTkJP5caJG4MpUXQN5ED0QSXt5_zxqkIxCg=.14896070-77e7-444f-8698-b622aed05a29@github.com>

On Wed, 8 Jun 2022 15:53:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/Provider.java line 1098:
> 
>> 1096:         boolean matches(String type, String algorithm) {
>> 1097:             return (Objects.equals(this.type, type)) &&
>> 1098:                 (Objects.equals(this.originalAlgorithm, algorithm));
> 
> In fact, I'm not sure why the original code is brave enough to use `==` instead of `equals`. If you do believe it's a real bug (and can write a regression test), let's fix it in a real bug fix. Otherwise, keep using `==` and add a comment saying it's correct.

The `ServiceKey` class has `equals` and `matches` methods. The `matches` method returns true if two objects contain identical String pointers. The `equals` method returns true if String pointers are different but have the same value. This is by design, so it would be a mistake to take IntelliJ's suggestion here.

Keeping the `==` and adding a comment.
Good catch.

> src/java.base/share/classes/java/security/SecureClassLoader.java line 221:
> 
>> 219:         // only), and the fragment is not considered.
>> 220:         CodeSourceKey key = new CodeSourceKey(cs);
>> 221:         /* not used */
> 
> What is not used? `key1`? How about just rename it to `unused`?

Renamed `key1` to `unused`.

> src/java.base/share/classes/java/security/SecureClassLoader.java line 235:
> 
>> 233:     }
>> 234: 
>> 235:     private record CodeSourceKey(CodeSource cs) {
> 
> Really necessary?

No. It was just an IntelliJ suggestion. I have no preference.

> src/java.base/share/classes/java/security/SecureRandom.java line 905:
> 
>> 903:         private static final Pattern pattern =
>> 904:             Pattern.compile(
>> 905:                 "\\s*([\\S&&[^:,]]*)(:([\\S&&[^,]]*))?\\s*(,(.*))?");
> 
> Don't quite understand this change. Can you explain?

The author must have thought `:` and `,` were metacharacters that needed to be escaped to turn them into ordinary characters. I verified with a small java program that` \:` and` \,` are equivalent to `;` and `,`.
The IntelliJ complaint is "Redundant character escape `'\:'`".

> src/java.base/share/classes/java/security/UnresolvedPermission.java line 369:
> 
>> 367:             this.certs != null && that.certs == null ||
>> 368:             this.certs != null &&
>> 369:                this.certs.length != that.certs.length) {
> 
> I see you keep a lot of parentheses in other places. For example, `(!r)`.

This is an IntelliJ suggestion. I don't know why it complains about some cases and ignores others. Perhaps it has something to do with readability.

> src/java.base/share/classes/java/security/cert/CertPathValidator.java line 335:
> 
>> 333:         String cpvtype =
>> 334:             AccessController.doPrivileged((PrivilegedAction<String>) () ->
>> 335:                     Security.getProperty(CPV_TYPE));
> 
> See too many, maybe we need a dedicated method in `sun.security.util.SecurityProperties`?

A privilegedGetProperty method? That would be the subject of a new bug I think.

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

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

From duke at openjdk.java.net  Fri Jun 10 21:10:06 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 10 Jun 2022 21:10:06 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <vYbxFiDZ1aAPM62-UtfKQv4WiY80dw_mMeZ4sNBH6K0=.2c7dea0a-3641-4d4c-92de-6f9caa16c999@github.com>

On Wed, 8 Jun 2022 16:06:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/Signature.java line 271:
> 
>> 269:                 (algorithm + " Signature not available");
>> 270:         }
>> 271:         // try services until we find a Spi or a working Signature subclass
> 
> Is `Spi` pronounced `spy` or "S-P-I"?

Reversing change: "an Spi" is correct.

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

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

From duke at openjdk.java.net  Fri Jun 10 21:15:05 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 10 Jun 2022 21:15:05 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
Message-ID: <yYcNyuvHq3tn5o-56EMReTxUisiDeCmC9q1z3spzdXk=.34b81919-c356-4a6d-9162-652b5a7f2304@github.com>

On Wed, 8 Jun 2022 16:01:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - fourth iteration
>>  - Merge
>>  - Merge
>>  - third iteration
>>  - Merge
>>  - Merge
>>  - second iteration
>>  - Merge
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4d6fb515...44140a01
>
> src/java.base/share/classes/java/security/Security.java line 260:
> 
>> 258:         }
>> 259: 
>> 260:         return null;
> 
> If `entry` is always null, then we don't need to declare it at all.

Agreed.

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

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

From duke at openjdk.java.net  Fri Jun 10 21:27:58 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 10 Jun 2022 21:27:58 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v6]
In-Reply-To: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
Message-ID: <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security
> 
> JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: 
> 
> open/src/java.base/share/classes/java/security

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

 - bad grammar
 - Max comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8319/files
  - new: https://git.openjdk.org/jdk/pull/8319/files/44140a01..59b2383e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8319&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8319&range=04-05

  Stats: 24 lines in 8 files changed: 3 ins; 9 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/8319.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8319/head:pull/8319

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

From hchao at openjdk.java.net  Fri Jun 10 21:41:50 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 10 Jun 2022 21:41:50 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v4]
In-Reply-To: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
Message-ID: <NNjbqo3ZNH-P-ft_91qbYBchePf8bFuAS9IPodeQRto=.d0bc7874-74cc-460d-b17a-a7407851f3cb@github.com>

> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
> Ran MACH5 tier1 and tier2 without failures.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Manual test instr using System.out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8985/files
  - new: https://git.openjdk.org/jdk/pull/8985/files/2e8f5d95..9f94f620

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8985&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8985&range=02-03

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

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

From hchao at openjdk.java.net  Fri Jun 10 21:41:50 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 10 Jun 2022 21:41:50 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v3]
In-Reply-To: <FCLaFQJdt-ZkVeGL0Ld67uy1GXI1z7iM9pJS3gowF4A=.da4a7975-559d-4475-bb4e-502db62f56fe@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <9whOl5uVwwewMVEdl4xzhx0sbztWUl1YpgtLGtkvNVg=.ff2b9bf5-c9fc-4544-bca4-dc1746b8d55e@github.com>
 <FCLaFQJdt-ZkVeGL0Ld67uy1GXI1z7iM9pJS3gowF4A=.da4a7975-559d-4475-bb4e-502db62f56fe@github.com>
Message-ID: <NqUJVheCgsMvfdX2R_7gOtH92dDyEnFFf0FYq2QZ_Ic=.f046a3d2-ec11-4731-b743-dca305f32851@github.com>

On Fri, 10 Jun 2022 17:31:56 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed copyright
>
> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 38:
> 
>> 36: import java.security.Security;
>> 37: 
>> 38: // This is a manual test to test a custom ?default_local.policy" containing inconsistent entries
> 
> Thanks for the instructions. For manual test, I would rather have these as a System.out on test start than a comment here. This helps engineers who look at jtr file for failure analysis as they generally won't refer test source code to understand missing steps.

Good point. Made the changes as suggested. Thanks for the review.

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

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

From weijun at openjdk.java.net  Fri Jun 10 21:52:08 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 10 Jun 2022 21:52:08 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v6]
In-Reply-To: <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>
Message-ID: <6wzfdv-iCGkovZaULYnGBorr8-SQxSrh7mJbnWkkpb0=.d0de5c7a-1a01-4e96-a0b2-3c3f9eac348c@github.com>

On Fri, 10 Jun 2022 21:27:58 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security
>> 
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: 
>> 
>> open/src/java.base/share/classes/java/security
>
> Mark Powers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - bad grammar
>  - Max comments

Looks good to me now. For `Provider$ServiceKey::matches`, maybe you can add a comment on why `==` is correct. For other changes suggested by IntelliJ, maybe just follow them to make the IDE silent. You decide it.

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

Marked as reviewed by weijun (Reviewer).

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

From weijun at openjdk.java.net  Fri Jun 10 21:52:12 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 10 Jun 2022 21:52:12 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <SG-YlIuSwTkJP5caJG4MpUXQN5ED0QSXt5_zxqkIxCg=.14896070-77e7-444f-8698-b622aed05a29@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
 <SG-YlIuSwTkJP5caJG4MpUXQN5ED0QSXt5_zxqkIxCg=.14896070-77e7-444f-8698-b622aed05a29@github.com>
Message-ID: <IyQC8TvzmQIlzUPKzJNAgzMns88OrBb-GNRssmX2_yI=.cc808b4f-d74f-439a-8bb2-767d310de2f3@github.com>

On Fri, 10 Jun 2022 00:35:16 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/security/SecureRandom.java line 905:
>> 
>>> 903:         private static final Pattern pattern =
>>> 904:             Pattern.compile(
>>> 905:                 "\\s*([\\S&&[^:,]]*)(:([\\S&&[^,]]*))?\\s*(,(.*))?");
>> 
>> Don't quite understand this change. Can you explain?
>
> The author must have thought `:` and `,` were metacharacters that needed to be escaped to turn them into ordinary characters. I verified with a small java program that` \:` and` \,` are equivalent to `;` and `,`.
> The IntelliJ complaint is "Redundant character escape `'\:'`".

I see. Thanks for the explanation.

>> src/java.base/share/classes/java/security/cert/CertPathValidator.java line 335:
>> 
>>> 333:         String cpvtype =
>>> 334:             AccessController.doPrivileged((PrivilegedAction<String>) () ->
>>> 335:                     Security.getProperty(CPV_TYPE));
>> 
>> See too many, maybe we need a dedicated method in `sun.security.util.SecurityProperties`?
>
> A privilegedGetProperty method? That would be the subject of a new bug I think.

Yes.

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

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

From weijun at openjdk.java.net  Fri Jun 10 22:28:48 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 10 Jun 2022 22:28:48 GMT
Subject: Integrated: 8287178: IntegerModuloP::multiplicativeInverse returns 0
 for 0
In-Reply-To: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
References: <Md3kPa9LNrS7bkAqPnq-QsChoE73vFRcjC0j2OvFM28=.1d5dda87-ea97-420b-a00d-d41c87de46e3@github.com>
Message-ID: <VPJF7_2uvqhJJnp1NrZjs2oibWTPJZHwCKGxkwkKHQA=.f609aedd-472d-4b8e-9440-2ae8046c105f@github.com>

On Thu, 9 Jun 2022 21:34:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add comment to the method.

This pull request has now been integrated.

Changeset: d4b473d8
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b473d89046874f25aa6f65f3ae96f7d8397d50
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8287178: IntegerModuloP::multiplicativeInverse returns 0 for 0

Reviewed-by: jnimeh

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

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

From duke at openjdk.java.net  Fri Jun 10 22:48:07 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 10 Jun 2022 22:48:07 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
In-Reply-To: <IyQC8TvzmQIlzUPKzJNAgzMns88OrBb-GNRssmX2_yI=.cc808b4f-d74f-439a-8bb2-767d310de2f3@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <mxW4Q1W5iKgS2RHWQN5kgcJkCohi3oCIJ2J8ObSxsas=.9ebaf123-a2ae-403c-bc0b-479a740c093c@github.com>
 <W4kNvEuPkm2hx0WgBiULHfFKerYoaSfBoP7vkxmuIWY=.7c3f1114-6054-4518-b7c6-720c05a00aee@github.com>
 <SG-YlIuSwTkJP5caJG4MpUXQN5ED0QSXt5_zxqkIxCg=.14896070-77e7-444f-8698-b622aed05a29@github.com>
 <IyQC8TvzmQIlzUPKzJNAgzMns88OrBb-GNRssmX2_yI=.cc808b4f-d74f-439a-8bb2-767d310de2f3@github.com>
Message-ID: <cXBKuLzZ12rVKK2opO7eikzA3LxKhqdMHDXvGaxDxkM=.32eb0701-980e-4ea2-95a7-9f850a7cb826@github.com>

On Fri, 10 Jun 2022 21:44:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> A privilegedGetProperty method? That would be the subject of a new bug I think.
>
> Yes.

JDK-8288271 has been created

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

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

From rhalade at openjdk.java.net  Fri Jun 10 22:56:54 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 10 Jun 2022 22:56:54 GMT
Subject: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always
 returns 'true' [v4]
In-Reply-To: <NNjbqo3ZNH-P-ft_91qbYBchePf8bFuAS9IPodeQRto=.d0bc7874-74cc-460d-b17a-a7407851f3cb@github.com>
References: <VXVD98KE21z257DM5a8Ik1jK7rJwFmiKQHfDXtwH_pI=.593cc5f6-2db9-4f07-837c-1e70db859b4e@github.com>
 <NNjbqo3ZNH-P-ft_91qbYBchePf8bFuAS9IPodeQRto=.d0bc7874-74cc-460d-b17a-a7407851f3cb@github.com>
Message-ID: <b-T9RLFsMF6ExxTbPk_Hbn-NytcNA98tBuxY4cEh8IA=.5bccfb1e-7b59-436a-bf99-75993c36e112@github.com>

On Fri, 10 Jun 2022 21:41:50 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review a small fix in CryptoPolicyParser class that it should not pass ?processedPermissions? parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Manual test instr using System.out

Marked as reviewed by rhalade (Reviewer).

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

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

From duke at openjdk.java.net  Fri Jun 10 23:01:08 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 10 Jun 2022 23:01:08 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v6]
In-Reply-To: <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>
Message-ID: <ho1KYhLFEzvMZCNk3GzEJE5B6NGmCilfCWRBXx0gFrE=.3af6013c-d03b-4dd0-866d-292696d9251b@github.com>

On Fri, 10 Jun 2022 21:27:58 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security
>> 
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: 
>> 
>> open/src/java.base/share/classes/java/security
>
> Mark Powers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - bad grammar
>  - Max comments

Thanks!!! You did a great job reviewing 94 files!!! Do you ever sleep?

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

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

From hchao at openjdk.java.net  Sat Jun 11 00:03:22 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Sat, 11 Jun 2022 00:03:22 GMT
Subject: Integrated: 8288270: Tier1 build failures after JDK-8287178
Message-ID: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>

Please review the small fix in comment.

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

Commit messages:
 - 8288270: Tier1 build failures after JDK-8287178

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

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

From weijun at openjdk.java.net  Sat Jun 11 00:03:22 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 11 Jun 2022 00:03:22 GMT
Subject: Integrated: 8288270: Tier1 build failures after JDK-8287178
In-Reply-To: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
References: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
Message-ID: <byb7EsXfRjtqrd7GAq6gQ37bE-e-XRs-peODuj9C7Gc=.ca05582b-0e5f-445e-a638-62879019d5f2@github.com>

On Fri, 10 Jun 2022 23:49:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the small fix in comment.

LGTM. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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

From jiefu at openjdk.java.net  Sat Jun 11 00:03:23 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 11 Jun 2022 00:03:23 GMT
Subject: Integrated: 8288270: Tier1 build failures after JDK-8287178
In-Reply-To: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
References: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
Message-ID: <ckHFeZ8T-0O1o4qOfwS6XVMIBc0FQ5wDIR8RXcFqFrs=.9b8446e6-f72e-4beb-b6b1-c834bead70b3@github.com>

On Fri, 10 Jun 2022 23:49:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the small fix in comment.

Looks good and trivial.
Thanks.

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

Marked as reviewed by jiefu (Reviewer).

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

From hchao at openjdk.java.net  Sat Jun 11 00:03:24 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Sat, 11 Jun 2022 00:03:24 GMT
Subject: Integrated: 8288270: Tier1 build failures after JDK-8287178
In-Reply-To: <ckHFeZ8T-0O1o4qOfwS6XVMIBc0FQ5wDIR8RXcFqFrs=.9b8446e6-f72e-4beb-b6b1-c834bead70b3@github.com>
References: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
 <ckHFeZ8T-0O1o4qOfwS6XVMIBc0FQ5wDIR8RXcFqFrs=.9b8446e6-f72e-4beb-b6b1-c834bead70b3@github.com>
Message-ID: <ejfyRQpxxBslpsevgoaaCmYzTMcVDALYVJBYIvN1s1k=.2da8028c-76d3-4b48-a2b3-1d61c6186d8e@github.com>

On Fri, 10 Jun 2022 23:53:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Please review the small fix in comment.
>
> Looks good and trivial.
> Thanks.

@DamonFool @wangweij Thanks for the review!

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

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

From hchao at openjdk.java.net  Sat Jun 11 00:03:25 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Sat, 11 Jun 2022 00:03:25 GMT
Subject: Integrated: 8288270: Tier1 build failures after JDK-8287178
In-Reply-To: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
References: <sNOjx72_YmG2WnV1VGqa31feP1CA8QGfcMDtkWl-qEk=.14f456c3-0719-42e7-8b6f-c5a8dda81af3@github.com>
Message-ID: <LVjP4_DtvUbwN87Wt2d1RiWsAdr9o-KFL7IXTMSKakg=.1e7f0d54-b74b-486f-9c13-2ad921b56fa8@github.com>

On Fri, 10 Jun 2022 23:49:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the small fix in comment.

This pull request has now been integrated.

Changeset: f7a4be75
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7a4be75fbe9e703dea94459285c72094d4d8646
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288270: Tier1 build failures after JDK-8287178

Reviewed-by: weijun, jiefu

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

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

From duke at openjdk.java.net  Sat Jun 11 03:07:24 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Sat, 11 Jun 2022 03:07:24 GMT
Subject: RFR: 8267860: Off-by-one bug when searching arrays in AlpnGreaseTest
Message-ID: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>

This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860

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

Commit messages:
 - Update AlpnGreaseTest.java
 - JDK-8267860: off-by-one error

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

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

From wetmore at openjdk.java.net  Sat Jun 11 03:07:25 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sat, 11 Jun 2022 03:07:25 GMT
Subject: RFR: 8267860: Off-by-one bug when searching arrays in
 AlpnGreaseTest
In-Reply-To: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
References: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
Message-ID: <k40TnELR-iNpnwan0DO1vkfpZyvj8smrMU97jc8u3jc=.f20a9bd7-9723-4a66-a02f-ef7682201a01@github.com>

On Fri, 10 Jun 2022 17:12:30 GMT, Kevin Driver <duke at openjdk.java.net> wrote:

> This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860

LGTM.

test/jdk/sun/security/ssl/ALPN/AlpnGreaseTest.java line 86:

> 84: 
> 85:     private static void findGreaseInClientHello(byte[] bytes) throws Exception {
> 86:         for (int i = 0; i < bytes.length - greaseBytes.length + 1; i++) {

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

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

From duke at openjdk.java.net  Sat Jun 11 03:07:26 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Sat, 11 Jun 2022 03:07:26 GMT
Subject: RFR: 8267860: Off-by-one bug when searching arrays in
 AlpnGreaseTest
In-Reply-To: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
References: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
Message-ID: <m7Tn8ta5RGNhbAuWGkbP2Ap2717rdH5-DazHf50ge_E=.80bfdcc4-68ef-4c99-ab1e-f0e08ad3a21c@github.com>

On Fri, 10 Jun 2022 17:12:30 GMT, Kevin Driver <duke at openjdk.java.net> wrote:

> This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860

Sorry for the noisy comment section... I was just trying to trigger jcheck. It looks to have been triggered.

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

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

From weijun at openjdk.java.net  Sat Jun 11 03:07:54 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 11 Jun 2022 03:07:54 GMT
Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v6]
In-Reply-To: <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>
References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com>
 <zs3ixLPkzmTTd2lFJ3vQX477_TrPqaoS-kVi9gd7Sz0=.e22ad17e-27e7-44c6-857c-89f64b2681b1@github.com>
Message-ID: <V6_9Z38x-80s2UQzG3TC07RBBNm6EcrBkBF7u2HF5Yk=.0dbeab04-becb-4ede-ba6d-467cd19a61a5@github.com>

On Fri, 10 Jun 2022 21:27:58 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security
>> 
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: 
>> 
>> open/src/java.base/share/classes/java/security
>
> Mark Powers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - bad grammar
>  - Max comments

Most of the changes are trivial, like those no-more-public for interfaces. Reviewing 94 files is still easier than fixing 94 out of ...er... 185 files.

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

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

From duke at openjdk.java.net  Sat Jun 11 03:30:45 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Sat, 11 Jun 2022 03:30:45 GMT
Subject: RFR: 8267860: Off-by-one bug when searching arrays in
 AlpnGreaseTest [v2]
In-Reply-To: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
References: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
Message-ID: <wpDgr4QpT_m8Dfypmko50Epc1okDDf1TuJ4kzlYBaxE=.edef65f2-850c-4ed9-88ce-2b3d824d83c3@github.com>

> This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860

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

 - Merge branch 'openjdk:master' into JDK-8267860
 - Update AlpnGreaseTest.java
 - JDK-8267860: off-by-one error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9131/files
  - new: https://git.openjdk.org/jdk/pull/9131/files/507abec6..11379da8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9131&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9131&range=00-01

  Stats: 901 lines in 25 files changed: 616 ins; 53 del; 232 mod
  Patch: https://git.openjdk.org/jdk/pull/9131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9131/head:pull/9131

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

From aturbanov at openjdk.java.net  Sat Jun 11 10:57:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 11 Jun 2022 10:57:00 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <sGCu_RFjCgZ2wV2jlL2WCQsl6hvgVVCMtz_vf03jmD4=.afe2b601-2eac-42f6-ac42-31b94d1048d3@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

Thank you for review!

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

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

From aturbanov at openjdk.java.net  Sat Jun 11 10:57:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 11 Jun 2022 10:57:00 GMT
Subject: Integrated: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <kVuRMEW0BX6QbH5kgH6PVmZWUsvNKSrncJwnAoIUKiE=.9c5e0e92-1e58-458a-b1cb-67deedf27c3f@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

This pull request has now been integrated.

Changeset: f1143b1b
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1143b1b57683665c81d24ff192a9babc30f28ea
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

Reviewed-by: jpai, lancea

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

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

From duke at openjdk.java.net  Sun Jun 12 17:05:57 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Sun, 12 Jun 2022 17:05:57 GMT
Subject: RFR: 8267860: Off-by-one bug when searching arrays in
 AlpnGreaseTest [v2]
In-Reply-To: <k40TnELR-iNpnwan0DO1vkfpZyvj8smrMU97jc8u3jc=.f20a9bd7-9723-4a66-a02f-ef7682201a01@github.com>
References: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
 <k40TnELR-iNpnwan0DO1vkfpZyvj8smrMU97jc8u3jc=.f20a9bd7-9723-4a66-a02f-ef7682201a01@github.com>
Message-ID: <rtUkwvgi5hCPcDEI8QbF9rc64oyw1tRfX58VdXQIAcY=.445e9ad9-be9a-430f-875e-cf3a8c3b8317@github.com>

On Fri, 10 Jun 2022 17:55:04 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8267860
>>  - Update AlpnGreaseTest.java
>>  - JDK-8267860: off-by-one error
>
> LGTM.

@bradfordwetmore you'll have to do /sponsor again, it looks like.

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

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

From ssahoo at openjdk.java.net  Mon Jun 13 05:22:08 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Mon, 13 Jun 2022 05:22:08 GMT
Subject: Integrated: 8209935: Test to cover CodeSource.getCodeSigners()
In-Reply-To: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
References: <zw3vIJnORKecPtbz3wlZ0sxeys6oqIsHMypF9kjwFVk=.53a5ba63-b7c6-40fc-9550-25005864f2eb@github.com>
Message-ID: <1hM9_B_-Q_keVNgfP3CvjIXnDxmEyuUMhHF7poMs3l4=.4c68b4ef-6ea5-43cb-9b9b-c709fb450748@github.com>

On Mon, 18 Apr 2022 09:46:06 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> A Test updated to cover the getCodeSigners.

This pull request has now been integrated.

Changeset: 0cb0ecf4
Author:    Sibabrata Sahoo <ssahoo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cb0ecf4433f1054ba2f0fbdabee01323893e0fe
Stats:     157 lines in 3 files changed: 149 ins; 1 del; 7 mod

8209935: Test to cover CodeSource.getCodeSigners()

Reviewed-by: mullan

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

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

From mbaesken at openjdk.java.net  Mon Jun 13 07:30:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:30:06 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
Message-ID: <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>

On Fri, 10 Jun 2022 14:19:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I might question whether the added "null:-1" information is really helpful, or just as confusing however.

Hi Daniel, should we maybe better print something like "check for not allowed characters" in the exception ? Do you have an easy and cheap way in mind to the get the unsupported character (in this case "_") to add it to the output ? Would maybe be more helpful than the proposed host:port and better regarding security concerns.

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

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

From mullan at openjdk.java.net  Mon Jun 13 13:09:08 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 13 Jun 2022 13:09:08 GMT
Subject: RFR: 8267860: Off-by-one bug when searching arrays in
 AlpnGreaseTest [v2]
In-Reply-To: <wpDgr4QpT_m8Dfypmko50Epc1okDDf1TuJ4kzlYBaxE=.edef65f2-850c-4ed9-88ce-2b3d824d83c3@github.com>
References: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
 <wpDgr4QpT_m8Dfypmko50Epc1okDDf1TuJ4kzlYBaxE=.edef65f2-850c-4ed9-88ce-2b3d824d83c3@github.com>
Message-ID: <0I0Tg6d-Svx2AgAAV66VIKzNqjfcXi72XS0BGxGh5-I=.3386e5e3-4bb6-4cdd-9ec6-94557b889091@github.com>

On Sat, 11 Jun 2022 03:30:45 GMT, Kevin Driver <duke at openjdk.java.net> wrote:

>> This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8267860
>  - Update AlpnGreaseTest.java
>  - JDK-8267860: off-by-one error

Please also add a "noreg-self" label to the bug to indicate that the fix is to the test itself and doesn't need a regression test. See https://openjdk.java.net/guide/#jbs-label-dictionary for the definition of this and other JBS labels.

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

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

From jpai at openjdk.java.net  Mon Jun 13 14:33:07 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 13 Jun 2022 14:33:07 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
 <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>
Message-ID: <sA6MAh72FfFYsCKjumYqh2lPdKj6AOUsdvcV253_PTw=.a4720d1d-1bfa-4080-8dc4-b8dc36ed49a5@github.com>

On Mon, 13 Jun 2022 07:26:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Daniel, should we maybe better print something like "check for not allowed characters" in the exception ? Do you have an easy and cheap way in mind to the get the unsupported character (in this case "_") to add it to the output ? Would maybe be more helpful than the proposed host:port and better regarding security concerns.

Hello Matthias, the current error message is:

> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389

Are you suggesting that the error message should include some additional wording which states why the authority isn't supported (in this case because of the presence of that `_` character)?

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

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

From mbaesken at openjdk.java.net  Mon Jun 13 14:48:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 14:48:06 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <sA6MAh72FfFYsCKjumYqh2lPdKj6AOUsdvcV253_PTw=.a4720d1d-1bfa-4080-8dc4-b8dc36ed49a5@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
 <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>
 <sA6MAh72FfFYsCKjumYqh2lPdKj6AOUsdvcV253_PTw=.a4720d1d-1bfa-4080-8dc4-b8dc36ed49a5@github.com>
Message-ID: <tyhwzJh9f6-okGMGwjh2fr1yGeNQY1Li7U1KXtB4fc0=.4775ad73-fa4b-41fc-b511-109c594fe9de@github.com>

On Mon, 13 Jun 2022 14:29:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > Hi Daniel, should we maybe better print something like "check for not allowed characters" in the exception ? Do you have an easy and cheap way in mind to the get the unsupported character (in this case "_") to add it to the output ? Would maybe be more helpful than the proposed host:port and better regarding security concerns.
> 
> Hello Matthias, the current error message is:
> 
> > java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> 
> Are you suggesting that the error message should include some additional wording which states why the authority isn't supported (in this case because of the presence of that `_` character)?

Yes , this is what I meant.  Ideally (and if it is not much overhead/easy to get) we show the 'bad'  character in the message.  Otherwise just some additional wording.

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

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

From duke at openjdk.java.net  Mon Jun 13 14:43:19 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Mon, 13 Jun 2022 14:43:19 GMT
Subject: Integrated: 8267860: Off-by-one bug when searching arrays in
 AlpnGreaseTest
In-Reply-To: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
References: <Nzjtr-TxZPzldAnMe4JIglxr2kNoepiEX1ipNuRFlJQ=.d376e2aa-0f49-4866-a162-54f8c9328125@github.com>
Message-ID: <Y6B4CcuF9JVAK6ePxP9-FZzClt8Ul8VMKqHLzpjqI-Y=.3e9c0e26-d48c-412a-aee5-983421f20ced@github.com>

On Fri, 10 Jun 2022 17:12:30 GMT, Kevin Driver <duke at openjdk.java.net> wrote:

> This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860

This pull request has now been integrated.

Changeset: 2adef6a1
Author:    Kevin Driver <largeprimes at proton.me>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2adef6a1f84d478bb38b179795f08ffa43680e36
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8267860: Off-by-one bug when searching arrays in AlpnGreaseTest

Co-authored-by: Bradford Wetmore <wetmore at openjdk.org>
Reviewed-by: wetmore

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

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

From weijun at openjdk.java.net  Mon Jun 13 15:01:32 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 13 Jun 2022 15:01:32 GMT
Subject: RFR: 8288209: SSL debug message wrong about unsupported authentication
 scheme
Message-ID: <4pgkx8kgS4mJZJwbWS0ObyGGwXAK0SoDcWpuGSQnwtU=.e79b8336-d066-4da8-96b6-39458fc41be7@github.com>

At the beginning, this bug was about the incorrect warning message "Unsupported authentication scheme" on line 1051 which should have been "This key algorithm has been checked, skip it".

Now, it's a code refactoring that emphasizes only the key algorithm inside a signature scheme is checked in these two methods, and therefore the ignore-if-checked logic in the old code is correct.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/9140/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288209
  Stats: 106 lines in 5 files changed: 9 ins; 57 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/9140.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9140/head:pull/9140

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

From mbaesken at openjdk.java.net  Tue Jun 14 10:43:54 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:43:54 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v2]
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <wRLbs_glsg65C2B7dIgDh3XA76e4VlsQef5N_Rx7WsI=.c4db0734-05ca-4506-ba02-e1fbfa8eeab2@github.com>

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

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

  Adjust exception text to the suggestion of Daniel Fuchs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/2454d4e5..1050c724

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=00-01

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

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

From mbaesken at openjdk.java.net  Tue Jun 14 10:43:54 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:43:54 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <Vt1OP6p1e5V3sbSpmrRKW4N-unfQNCtRbZ-UfMGttbU=.01976899-1e9d-4184-b0d8-25a6a9426673@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

Thanks Daniel, I adjusted the exception message to what you suggested.

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

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

From mbaesken at openjdk.java.net  Tue Jun 14 11:36:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 11:36:36 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v3]
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

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

  fix copy paste error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01-02

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

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

From mbaesken at openjdk.java.net  Tue Jun 14 11:36:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 11:36:36 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v2]
In-Reply-To: <wRLbs_glsg65C2B7dIgDh3XA76e4VlsQef5N_Rx7WsI=.c4db0734-05ca-4506-ba02-e1fbfa8eeab2@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <wRLbs_glsg65C2B7dIgDh3XA76e4VlsQef5N_Rx7WsI=.c4db0734-05ca-4506-ba02-e1fbfa8eeab2@github.com>
Message-ID: <MffL-6bzxXsvRJw9_AT1sA_DDUYsHFBjmKCLQROA1uM=.5606bc3a-43e3-47a3-ac16-a9f1c493e36d@github.com>

On Tue, 14 Jun 2022 10:43:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust exception text to the suggestion of Daniel Fuchs

> I guess there's been some copy paste mistake here :-)

Yes, had to fix that!

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

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

From alanb at openjdk.java.net  Tue Jun 14 11:40:54 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 11:40:54 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v3]
In-Reply-To: <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
Message-ID: <9_WX5OtZS2cN9mIs4crx5KtyKrAKOVPFtQyT5ZAZoC4=.7cb36ff0-8b61-408e-9558-ab14732b6bb3@github.com>

On Tue, 14 Jun 2022 11:36:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copy paste error

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 368:

> 366:                         // throw if we have user info or regname
> 367:                         throw new MalformedURLException("Authority component is not server-based, or contains user info. Unsupported authority: " + auth);
> 368:                     }

This looks okay but you may have to split up the line to avoid adding a 150+ char line (most of the file seems to keep the lines under 100 or so).

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

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

From ecki at zusammenkunft.net  Tue Jun 14 11:46:33 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 14 Jun 2022 11:46:33 +0000
Subject: RFR: JDK-8288207: Enhance MalformedURLException in
 Uri.parseCompat [v3]
In-Reply-To: <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
Message-ID: <AM9P193MB11429A2B062FA6D723D84901FFAA9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

The change does not seem to be related to your description, and the description does not match the shown exception. In fact the example stacktrace contains the authority value twice and your change adds a diagnostic which is not really helpful for the case of the underscore? I would not be too specific for such general parsing rules.


--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Matthias Baesken <mbaesken at openjdk.java.net>
Gesendet: Tuesday, June 14, 2022 1:36:36 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
>
>
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

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

  fix copy paste error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01-02

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

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

From mbaesken at openjdk.java.net  Tue Jun 14 12:18:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 12:18:52 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v4]
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

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

  avoid very long line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/bdbe2204..8f528226

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02-03

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

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

From dfuchs at openjdk.java.net  Tue Jun 14 12:49:05 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 14 Jun 2022 12:49:05 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v4]
In-Reply-To: <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
Message-ID: <3dtTh1P6TGT6hX2KjvFtUwMt6NDh0CL0u1LKbTDL7RY=.8b6e29d4-54f8-4410-8855-b073b7dc4535@github.com>

On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid very long line

The last changes LGTM.

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

Marked as reviewed by dfuchs (Reviewer).

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

From alanb at openjdk.java.net  Tue Jun 14 12:53:04 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 12:53:04 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v4]
In-Reply-To: <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
Message-ID: <WINtNT3RWvvY9EU5w-HNFq_Y4Fo6_4QhjCStP3ETp-M=.abd0d6b5-5665-4d2c-a48f-363ba44ad594@github.com>

On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid very long line

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.java.net  Tue Jun 14 16:46:23 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Tue, 14 Jun 2022 16:46:23 GMT
Subject: RFR: 8220732: setSeed(long) java api doc is missing warning about
 provided seed quality
Message-ID: <l5YYV1Rf1lQB4Vno4tCx_qfggfiCZKwg7jRPgWuVdDQ=.8d7bd369-031a-4c9c-8df9-a800f6a34292@github.com>

Resolves [JDK-8220732](https://bugs.openjdk.org/browse/JDK-8220732?filter=42718). The additional guidance as been added to the javadoc for `setSeed(long)`

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

Commit messages:
 - Resolves JDK-8220732. The additional guidance as been added to the javadoc for setSeed(long)

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

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

From weijun at openjdk.java.net  Tue Jun 14 18:05:38 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 14 Jun 2022 18:05:38 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the heap
Message-ID: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>

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

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

Commit messages:
 - the fix

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

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

From wetmore at openjdk.java.net  Tue Jun 14 22:44:40 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 14 Jun 2022 22:44:40 GMT
Subject: RFR: 8220732: setSeed(long) java api doc is missing warning about
 provided seed quality
In-Reply-To: <l5YYV1Rf1lQB4Vno4tCx_qfggfiCZKwg7jRPgWuVdDQ=.8d7bd369-031a-4c9c-8df9-a800f6a34292@github.com>
References: <l5YYV1Rf1lQB4Vno4tCx_qfggfiCZKwg7jRPgWuVdDQ=.8d7bd369-031a-4c9c-8df9-a800f6a34292@github.com>
Message-ID: <8cYK21AkoSKnpRwOVq2VE-Zen16OD7EDUz4CysdOx38=.61e9fa41-5c77-476d-932e-b57dd9e7bd1a@github.com>

On Tue, 14 Jun 2022 16:37:59 GMT, Kevin Driver <duke at openjdk.java.net> wrote:

> Resolves [JDK-8220732](https://bugs.openjdk.org/browse/JDK-8220732?filter=42718). The additional guidance as been added to the javadoc for `setSeed(long)`

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

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

From jnimeh at openjdk.java.net  Tue Jun 14 22:50:43 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 14 Jun 2022 22:50:43 GMT
Subject: RFR: 8288209: SSL debug message wrong about unsupported
 authentication scheme [v2]
In-Reply-To: <mNgANlhyOjrucoogn-2CvmOJhfRwYQD-ooBQppX5kyo=.c67cf60e-823b-48fc-8462-9ae47e26eac2@github.com>
References: <4pgkx8kgS4mJZJwbWS0ObyGGwXAK0SoDcWpuGSQnwtU=.e79b8336-d066-4da8-96b6-39458fc41be7@github.com>
 <2hItx-6albkOAuyDUSW2AtkjSiWBZqjeC77aZzK5StM=.8a366382-ecf8-4cfa-b19c-8163ab8964c3@github.com>
 <mNgANlhyOjrucoogn-2CvmOJhfRwYQD-ooBQppX5kyo=.c67cf60e-823b-48fc-8462-9ae47e26eac2@github.com>
Message-ID: <sT8X1whAHB7gMqWPIvCprjRCQab7tt4ZjbODuoKdkhA=.0d72bef0-f822-49bb-9944-2b03f3b08f6a@github.com>

On Mon, 13 Jun 2022 16:30:36 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1045:
> 
>> 1043:             }
>> 1044: 
>> 1045:             String[] supportedKeyTypes = hc.peerRequestedCertSignSchemes
> 
> Preexisting, but shouldn't we use `peerRequestedSignatureSchemes` here? If I read [RFC 8446](https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2) correctly, `peerRequestedCertSignSchemes` only applies to how the certificates were signed; it does not limit the end-entity key type in any way.

It does appear that there is an issue here.  Weijun and I have done a little playtesting with this and there are some cases where it isn't behaving as expected.  I don't know if this can be solved as simply as using `peerRequestedSignatureSchemes` though.  It might be that simple, but I think the selection code is complex enough and there are enough edge cases to test that this PR might not be the place to address this.  We probably need a separate bug to deal with this one.

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

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

From mbaesken at openjdk.java.net  Wed Jun 15 06:55:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Jun 2022 06:55:58 GMT
Subject: Integrated: JDK-8288207: Enhance MalformedURLException in
 Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <J7XCcsmtWUkvRjZe3qSuf19ZsSbeC5OwCqwLTOeNIA8=.aaf3796c-164c-45d1-8780-e09445440ecc@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

This pull request has now been integrated.

Changeset: 33f34d54
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33f34d540e01db7e64da97d518e9dd88d014fb23
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8288207: Enhance MalformedURLException in Uri.parseCompat

Reviewed-by: dfuchs, alanb

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

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

From job at kimmeringer.de  Wed Jun 15 09:15:27 2022
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Wed, 15 Jun 2022 11:15:27 +0200
Subject: Private Keys are cached "forever" leading to inop HTTP-TLS-servers
Message-ID: <f0283220-38b0-6d9b-82f3-c5556c00e4c7@kimmeringer.de>

Hi,

I first thought this to be a bug in Jetty[1] but it seems to be within the JVM.

I have the situation that the Jetty HTTP server is configured to use a
cloud-based HSM as KeyStore for Private Keys. This works but if the
connector stays idle for some time, subsequent handshakes fail with
a ProviderException:

2022-06-10 20:18:29,595 DEBUG [qtp705913731-178] SslConnection: DecryptedEndPoint at 1b2a1192[{l=/127.0.0.1:4433,r=/127.0.0.1:3254,OPEN,fill=-,flush=-,to=24/180000}] stored flush exception
java.security.ProviderException: Initialization failed
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.initialize(P11PSSSignature.java:310)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.ensureInitialized(P11PSSSignature.java:216)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.engineUpdate(P11PSSSignature.java:507)
	at java.base/java.security.Signature$Delegate.engineUpdate(Signature.java:1394)
	at java.base/java.security.Signature.update(Signature.java:903)
	at java.base/java.security.Signature.update(Signature.java:872)
	at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.updateSignature(ECDHServerKeyExchange.java:462)
	at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.<init>(ECDHServerKeyExchange.java:173)
	at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeProducer.produce(ECDHServerKeyExchange.java:488)
	at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1091)
	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:843)
	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:802)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
	at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:629)
[...]
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
	at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.initialize(P11PSSSignature.java:303)
	... 34 common frames omitted

Used Java: java -version
openjdk version "11.0.14" 2022-01-18 LTS
OpenJDK Runtime Environment Zulu11.54+23-CA (build 11.0.14+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.54+23-CA (build 11.0.14+9-LTS, mixed mode)

I assume that the driver or the HSM-server is running into a timeout invalidating
some session and thus make the key no longer usable. The KeyStore itself can
still be used. If the same key is retrieved by "getKey" somewhere else the
returned key doesn't get "invalidated", either. I've created a test class where
this can be seen:

------------------- snip
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.nio.charset.StandardCharsets;
import java.security.AuthProvider;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.Provider;
import java.security.Security;
import java.security.Signature;
import java.util.Arrays;
import java.util.Date;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
import javax.security.auth.login.LoginException;

import com.ebd.util.text.TextTools;

public class HSMAccessTest {
     
     public final static void main(String[] args) throws Exception {
         String config =
                 "name = TestUtimaco\r\n" +
                 "library = D:/Program Files/Utimaco/CryptoServer/Lib/cs_pkcs11_R2.dll\r\n" +
                 "";
         
         File tempConfig = File.createTempFile("hsmconfig_", ".properties");
         try {
             try (FileWriter fw = new FileWriter(tempConfig, StandardCharsets.ISO_8859_1)) {
                 fw.write(config);
                 fw.flush();
             }
             
             Provider p = Security.getProvider("SunPKCS11");
             AuthProvider prov = (AuthProvider) p.configure(tempConfig.getAbsolutePath());
             KeyStore ks = KeyStore.getInstance("PKCS11", prov);
             char[] pswd = "654321".toCharArray();
             ks.load(null, pswd);
             String certAlias = ks.aliases().nextElement();
             System.out.println(certAlias);
             
             PrivateKey key = (PrivateKey) ks.getKey(certAlias, null);
             for (long wait = 16 * 60000; wait < 3600000; ) {
//                performWorkaround(prov, pswd);
                 performSign(prov, key);
                 System.out.println("wait " + (wait / 60000) + " mins");
                 Thread.sleep(wait);
             }
         }
         finally {
             tempConfig.delete();
         }
         
     }

     static void performSign(AuthProvider prov, PrivateKey key) throws GeneralSecurityException, UnsupportedEncodingException {
         System.out.println(new Date() + ": Sign data. Key is destroyed: " + key.isDestroyed());
         Signature sig = Signature.getInstance("SHA1WithRSA", prov);
         sig.initSign(key);
         sig.update("signdata".getBytes("8859_1"));
         
         System.out.println(new Date() + ": " + TextTools.join(sig.sign(), ""));
     }

     static void performWorkaround(AuthProvider prov, char[] pswd) throws LoginException {
         prov.login(null, new CallbackHandler() {
             @Override
             public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
                 Arrays.stream(callbacks)
                     .filter(cb -> cb instanceof PasswordCallback)
                     .map(cb -> (PasswordCallback) cb)
                     .forEach(cb -> cb.setPassword(pswd));
             }
         });
     }
}
------------------- snip

The class in this version will run into an error after 16 minutes (32 minutes at the latest)

------------------- snip
testcert
Mon Jun 13 17:01:33 CEST 2022: Sign data. Key is destroyed: false
Mon Jun 13 17:01:33 CEST 2022: a8726a4ed3c3f77aced24b078931167214a7f64b1dac2e7774874aec7ec973d289bf72920b342b52c6b799ebee793332332f531994f1fd9ec77a986ac253e54771d410acc4c3dc71ca97b8c5ac445262b9da1177db0eaedb66b9a0af5dfc2f5c761ab514dde5ab90afc53aa7bcd54edfb93f247855794c127e6cff86562652ab5a3493c7e49756cc0d309495b5d365bbfc8eeeb30d46e4419727421c4eec5011560fe17fa6894ea967280470ec62366d56839ece086502471bb537a27a708a4654df2ba0a0234bd20f0d80519843e7ed4ca5beb76af5d66e886977a07092e20e73478c4bbdf1742475092b79b53c9a202d072a70ee112ef405138df7c1368b16
wait 16 mins
Mon Jun 13 17:17:33 CEST 2022: Sign data. Key is destroyed: false
Mon Jun 13 17:17:33 CEST 2022: a8726a4ed3c3f77aced24b078931167214a7f64b1dac2e7774874aec7ec973d289bf72920b342b52c6b799ebee793332332f531994f1fd9ec77a986ac253e54771d410acc4c3dc71ca97b8c5ac445262b9da1177db0eaedb66b9a0af5dfc2f5c761ab514dde5ab90afc53aa7bcd54edfb93f247855794c127e6cff86562652ab5a3493c7e49756cc0d309495b5d365bbfc8eeeb30d46e4419727421c4eec5011560fe17fa6894ea967280470ec62366d56839ece086502471bb537a27a708a4654df2ba0a0234bd20f0d80519843e7ed4ca5beb76af5d66e886977a07092e20e73478c4bbdf1742475092b79b53c9a202d072a70ee112ef405138df7c1368b16
wait 16 mins
Mon Jun 13 17:33:33 CEST 2022: Sign data. Key is destroyed: false
Exception in thread "main" java.security.ProviderException: Initialization failed
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.initialize(P11Signature.java:375)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineInitSign(P11Signature.java:502)
	at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1351)
	at java.base/java.security.Signature.initSign(Signature.java:636)
	at HSMAccessTest.performSign(HSMAccessTest.java:76)
	at HSMAccessTest.main(HSMAccessTest.java:50)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
	at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.initialize(P11Signature.java:366)
	... 5 more
------------------- snip

Putting the getKey-call inside the for-loop solves the problem. A workaround is
regularily calling authprovider.login. This can be seen if the commented-line
in the for-loop is activated.

Not sure if this should be considered a bug in the PKCS#11-DLL of the HSM-provider
but if a key-instance must be valid forever, shouldn't that be mentioned in the
interface's Javadoc?


Thanks and best regards,

Lothar Kimmeringer

[1] https://github.com/eclipse/jetty.project/issues/8157

From ecki at zusammenkunft.net  Wed Jun 15 11:32:20 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 15 Jun 2022 11:32:20 +0000
Subject: Private Keys are cached "forever" leading to inop HTTP-TLS-servers
In-Reply-To: <f0283220-38b0-6d9b-82f3-c5556c00e4c7@kimmeringer.de>
References: <f0283220-38b0-6d9b-82f3-c5556c00e4c7@kimmeringer.de>
Message-ID: <AM9P193MB1142F9975D6239B948707FA0FFAD9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

This look to me like a bug in the PKCS11 code or - if it is documented - in the application. Why do you think it is in JCE?

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at mail.openjdk.org> im Auftrag von Lothar Kimmeringer <job at kimmeringer.de>
Gesendet: Wednesday, June 15, 2022 11:15:27 AM
An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Private Keys are cached "forever" leading to inop HTTP-TLS-servers

Hi,

I first thought this to be a bug in Jetty[1] but it seems to be within the JVM.

I have the situation that the Jetty HTTP server is configured to use a
cloud-based HSM as KeyStore for Private Keys. This works but if the
connector stays idle for some time, subsequent handshakes fail with
a ProviderException:

2022-06-10 20:18:29,595 DEBUG [qtp705913731-178] SslConnection: DecryptedEndPoint at 1b2a1192[{l=/127.0.0.1:4433,r=/127.0.0.1:3254,OPEN,fill=-,flush=-,to=24/180000}] stored flush exception
java.security.ProviderException: Initialization failed
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.initialize(P11PSSSignature.java:310)
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.ensureInitialized(P11PSSSignature.java:216)
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.engineUpdate(P11PSSSignature.java:507)
        at java.base/java.security.Signature$Delegate.engineUpdate(Signature.java:1394)
        at java.base/java.security.Signature.update(Signature.java:903)
        at java.base/java.security.Signature.update(Signature.java:872)
        at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.updateSignature(ECDHServerKeyExchange.java:462)
        at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.<init>(ECDHServerKeyExchange.java:173)
        at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeProducer.produce(ECDHServerKeyExchange.java:488)
        at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1091)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:843)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:802)
        at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
        at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:629)
[...]
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
        at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method)
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11PSSSignature.initialize(P11PSSSignature.java:303)
        ... 34 common frames omitted

Used Java: java -version
openjdk version "11.0.14" 2022-01-18 LTS
OpenJDK Runtime Environment Zulu11.54+23-CA (build 11.0.14+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.54+23-CA (build 11.0.14+9-LTS, mixed mode)

I assume that the driver or the HSM-server is running into a timeout invalidating
some session and thus make the key no longer usable. The KeyStore itself can
still be used. If the same key is retrieved by "getKey" somewhere else the
returned key doesn't get "invalidated", either. I've created a test class where
this can be seen:

------------------- snip
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.nio.charset.StandardCharsets;
import java.security.AuthProvider;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.Provider;
import java.security.Security;
import java.security.Signature;
import java.util.Arrays;
import java.util.Date;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
import javax.security.auth.login.LoginException;

import com.ebd.util.text.TextTools;

public class HSMAccessTest {

     public final static void main(String[] args) throws Exception {
         String config =
                 "name = TestUtimaco\r\n" +
                 "library = D:/Program Files/Utimaco/CryptoServer/Lib/cs_pkcs11_R2.dll\r\n" +
                 "";

         File tempConfig = File.createTempFile("hsmconfig_", ".properties");
         try {
             try (FileWriter fw = new FileWriter(tempConfig, StandardCharsets.ISO_8859_1)) {
                 fw.write(config);
                 fw.flush();
             }

             Provider p = Security.getProvider("SunPKCS11");
             AuthProvider prov = (AuthProvider) p.configure(tempConfig.getAbsolutePath());
             KeyStore ks = KeyStore.getInstance("PKCS11", prov);
             char[] pswd = "654321".toCharArray();
             ks.load(null, pswd);
             String certAlias = ks.aliases().nextElement();
             System.out.println(certAlias);

             PrivateKey key = (PrivateKey) ks.getKey(certAlias, null);
             for (long wait = 16 * 60000; wait < 3600000; ) {
//                performWorkaround(prov, pswd);
                 performSign(prov, key);
                 System.out.println("wait " + (wait / 60000) + " mins");
                 Thread.sleep(wait);
             }
         }
         finally {
             tempConfig.delete();
         }

     }

     static void performSign(AuthProvider prov, PrivateKey key) throws GeneralSecurityException, UnsupportedEncodingException {
         System.out.println(new Date() + ": Sign data. Key is destroyed: " + key.isDestroyed());
         Signature sig = Signature.getInstance("SHA1WithRSA", prov);
         sig.initSign(key);
         sig.update("signdata".getBytes("8859_1"));

         System.out.println(new Date() + ": " + TextTools.join(sig.sign(), ""));
     }

     static void performWorkaround(AuthProvider prov, char[] pswd) throws LoginException {
         prov.login(null, new CallbackHandler() {
             @Override
             public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
                 Arrays.stream(callbacks)
                     .filter(cb -> cb instanceof PasswordCallback)
                     .map(cb -> (PasswordCallback) cb)
                     .forEach(cb -> cb.setPassword(pswd));
             }
         });
     }
}
------------------- snip

The class in this version will run into an error after 16 minutes (32 minutes at the latest)

------------------- snip
testcert
Mon Jun 13 17:01:33 CEST 2022: Sign data. Key is destroyed: false
Mon Jun 13 17:01:33 CEST 2022: a8726a4ed3c3f77aced24b078931167214a7f64b1dac2e7774874aec7ec973d289bf72920b342b52c6b799ebee793332332f531994f1fd9ec77a986ac253e54771d410acc4c3dc71ca97b8c5ac445262b9da1177db0eaedb66b9a0af5dfc2f5c761ab514dde5ab90afc53aa7bcd54edfb93f247855794c127e6cff86562652ab5a3493c7e49756cc0d309495b5d365bbfc8eeeb30d46e4419727421c4eec5011560fe17fa6894ea967280470ec62366d56839ece086502471bb537a27a708a4654df2ba0a0234bd20f0d80519843e7ed4ca5beb76af5d66e886977a07092e20e73478c4bbdf1742475092b79b53c9a202d072a70ee112ef405138df7c1368b16
wait 16 mins
Mon Jun 13 17:17:33 CEST 2022: Sign data. Key is destroyed: false
Mon Jun 13 17:17:33 CEST 2022: a8726a4ed3c3f77aced24b078931167214a7f64b1dac2e7774874aec7ec973d289bf72920b342b52c6b799ebee793332332f531994f1fd9ec77a986ac253e54771d410acc4c3dc71ca97b8c5ac445262b9da1177db0eaedb66b9a0af5dfc2f5c761ab514dde5ab90afc53aa7bcd54edfb93f247855794c127e6cff86562652ab5a3493c7e49756cc0d309495b5d365bbfc8eeeb30d46e4419727421c4eec5011560fe17fa6894ea967280470ec62366d56839ece086502471bb537a27a708a4654df2ba0a0234bd20f0d80519843e7ed4ca5beb76af5d66e886977a07092e20e73478c4bbdf1742475092b79b53c9a202d072a70ee112ef405138df7c1368b16
wait 16 mins
Mon Jun 13 17:33:33 CEST 2022: Sign data. Key is destroyed: false
Exception in thread "main" java.security.ProviderException: Initialization failed
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.initialize(P11Signature.java:375)
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineInitSign(P11Signature.java:502)
        at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1351)
        at java.base/java.security.Signature.initSign(Signature.java:636)
        at HSMAccessTest.performSign(HSMAccessTest.java:76)
        at HSMAccessTest.main(HSMAccessTest.java:50)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
        at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method)
        at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.initialize(P11Signature.java:366)
        ... 5 more
------------------- snip

Putting the getKey-call inside the for-loop solves the problem. A workaround is
regularily calling authprovider.login. This can be seen if the commented-line
in the for-loop is activated.

Not sure if this should be considered a bug in the PKCS#11-DLL of the HSM-provider
but if a key-instance must be valid forever, shouldn't that be mentioned in the
interface's Javadoc?


Thanks and best regards,

Lothar Kimmeringer

[1] https://github.com/eclipse/jetty.project/issues/8157
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220615/de36075e/attachment-0001.htm>

From mullan at openjdk.java.net  Wed Jun 15 14:57:41 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 15 Jun 2022 14:57:41 GMT
Subject: RFR: 8288329: Avoid redundant TreeMap.containsKey call in
 PolicyParser.read
In-Reply-To: <h3SKsjC-DP9XLnFWj8P6Bs1mqoqtJGytmKSixodBLR4=.d65f9822-68d2-4d0c-ab59-742e67dfcb76@github.com>
References: <h3SKsjC-DP9XLnFWj8P6Bs1mqoqtJGytmKSixodBLR4=.d65f9822-68d2-4d0c-ab59-742e67dfcb76@github.com>
Message-ID: <W_aG6Eybt4iUXriqx_Z2xpXeCksncsY_6HDbNs_wFpw=.e6880812-5e7c-4f50-83ae-b71921751fbb@github.com>

On Sat, 30 Apr 2022 16:43:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair `TreeMap.containsKey`/`TreeMap.put` method calls, we can use single call `TreeMap.putIfAbsent` and check result for nullness.
> Only non-null values are put into `Map<String, DomainEntry> domainEntries`.
> https://github.com/openjdk/jdk/blob/53a0acee06eb32fba700967c9a34d37ea42f7a99/src/java.base/share/classes/sun/security/provider/PolicyParser.java#L205-L214

Looks good, but please add an appropriate `noreg` label to the bug.

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

Marked as reviewed by mullan (Reviewer).

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

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I think this looks good overall, but please try to limit the accessibility of  the methods in `State`.

src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:

> 38:  * operations triggered by threads other than the owner thread, which we support.
> 39:  */
> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {

Same here. I don't see why this is made public now.

src/java.base/share/classes/jdk/internal/foreign/SharedSessionState.java line 46:

> 44:  * checking the liveness bit upon access can be performed in plain mode, as in the confined case.
> 45:  */
> 46: public class SharedSessionState extends MemorySessionImpl.State {

Unclear to me why this is now public. It still seems to be only accessed from with the `jdk.internal.foreign` package?

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

Marked as reviewed by jvernee (Reviewer).

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

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <NNFbp2rnfsp4-twI5e8a6s9kxqklOnUaInu5fAEUr0o=.a87e3023-0dd0-4b29-86b0-38ed8efd4883@github.com>

On Wed, 15 Jun 2022 14:41:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into cleanup_memory_session_impl_state
>>  - Add null check on Buffer::checkState
>>  - Add docs
>>    Simplify liveness check in Buffer
>>    Drop redundant import in DirectBuffer
>>  - Simplify checkValidState
>>  - Add fastpath for implicit session state
>>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>>  - Fix asNonCloseable to return self
>>    Improve direct buffer code with isImplicit predicate
>>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>>  - Simplify readOnly check
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246
>
> src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:
> 
>> 38:  * operations triggered by threads other than the owner thread, which we support.
>> 39:  */
>> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {
> 
> Same here. I don't see why this is made public now.

Same for `justClose` and `ConfinedList::add` in this file. They still seem only accessed in the same package.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 16:55:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 16:55:06 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <lTNs91mKp3yK6ux1HoGYYanROrJMGgwBs_ykF-Us-8Q=.d7350e59-cfa0-4cbe-8d33-fd97e24a4a47@github.com>

On Wed, 15 Jun 2022 14:55:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think this looks good overall, but please try to limit the accessibility of the methods in `State`.

Thanks, I'll take another look

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

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

From xuelei at openjdk.java.net  Wed Jun 15 17:32:41 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 15 Jun 2022 17:32:41 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v8]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <vblABaYcTg_9gjMeJu6bDwj4ZM3V0McmUJfPSq-2o-c=.8ec3c751-d35f-4a9b-ad0c-cc7340f6c073@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  use timeout factor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8979/files
  - new: https://git.openjdk.org/jdk/pull/8979/files/2825686b..bc51397f

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

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

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

From xuelei at openjdk.java.net  Wed Jun 15 17:32:43 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 15 Jun 2022 17:32:43 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
In-Reply-To: <RT1U-Xkb2cCL-v_GKjEnGxcgfjUSlhmxDr5fnaf7hgQ=.3bf18491-09df-477c-b3e6-37762751b006@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <pqDIz146EyleM3TZeY8WcgjAG9ze7NhE7g7B0bt_K1M=.6fde489c-efb8-4726-861a-38ee6a75fc2d@github.com>
 <THmEMBXe44ieDrUdmDKx-yRYWgijFsdwXM-PLdHv3e8=.bd9bbc0b-de5b-41e0-86cc-c763d179f634@github.com>
 <RT1U-Xkb2cCL-v_GKjEnGxcgfjUSlhmxDr5fnaf7hgQ=.3bf18491-09df-477c-b3e6-37762751b006@github.com>
Message-ID: <IGEI6KTnheskcc8cqA0gVe5aHJWPZA3rNH5r54P9OTA=.7ead3b40-261c-48f6-ae0a-e00b1e79b04a@github.com>

On Mon, 13 Jun 2022 22:21:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 44:
>> 
>>> 42:      */
>>> 43:     public static boolean wait(BooleanSupplier booleanSupplier) {
>>> 44:         return wait(booleanSupplier, 10000L);
>> 
>> For the max waiting time, instead of a fixed value I strongly recommend choosing some base waiting time, say 1 second, and scaling it by the jtreg timeout factor.
>
> I also have similar feedback.  The timeout factor can be found in the `test.timeout.factor` system property, if present.    When running tests with -Xcomp in a fastdebug build, the timeout factor is currently configured to 10.   Setting the base waiting time to 1 second seems reasonable.

Good point!  I changed to use 1 second as the base waiting time.  I was not very sure if 1 second is big enough for the GC cleanup, but the testing result on my laptop and VMs, which are super faster, looks good to me.  Please help to check mach5 result.

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

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

From xuelei at openjdk.java.net  Wed Jun 15 17:39:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 15 Jun 2022 17:39:12 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
In-Reply-To: <qtt-SVbqqY8iB_klhuuj6QSjoNd07bxq87ETB6FIh_A=.8b120b05-236e-4db3-855d-bbc78763df2b@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <pqDIz146EyleM3TZeY8WcgjAG9ze7NhE7g7B0bt_K1M=.6fde489c-efb8-4726-861a-38ee6a75fc2d@github.com>
 <qtt-SVbqqY8iB_klhuuj6QSjoNd07bxq87ETB6FIh_A=.8b120b05-236e-4db3-855d-bbc78763df2b@github.com>
Message-ID: <kTcV6sJAXtuUcdBjWEwYFfHYgN5y_8fzH7pdBUkRfLg=.38dd3af7-038f-4a75-8cfd-62f84843c1f6@github.com>

On Mon, 13 Jun 2022 22:37:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge
>>  - Merge master
>>  - Merge
>>  - add timeout parameter
>>  - rollback is not in this branch
>>  - rollback JDK-8287384
>>  - back to wait 1 second
>>  - Remove trailing white space
>>  - 8287596: Reorg jdk.test.lib.util.ForceGC
>
> test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java line 224:
> 
>> 222: 
>> 223:         boolean tryUnload() {
>> 224:             return ForceGC.wait(() -> weakRef.get() == null, 1000L);
> 
> This verifies that the reference will never become weakly unreachable, i.e. it remains strongly reachable.
> 
> I suggest to add a method default to 200ms (?) timeout scaled with the timeout factor and expect the specified condition will never met.   Maybe call it `ForceGC.neverTrue(BooleanSupplier)`?   Need to tune the base waiting time; for example if timeout factor is 4, then total wait would be 800 ms.

I see your points.

When I changed the waiting time to 1 second scaled with timeout factor, it looks like safe to use the ForceGC.wait() method for either cleanup and non-cleanup checking.  The default JTREG timeout for a test case is 120 seconds. 1 seconds may be small enough so that we could use it for both cases.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:31 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <N43DTnhrT-MpOW5fxbWyn5r2x7Fbn0MEZGYREvuCKAQ=.67761ec2-83ef-46c9-a54e-d0487fc233c5@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9017/files
  - new: https://git.openjdk.org/jdk/pull/9017/files/5b8f7246..67710665

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

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:34 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <WOeSkpiMEWFdfq24NPuKr1MkRsC-2KyWl7-xBTVhinY=.cedef75d-3936-4ef1-ba65-a24f579ac63e@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I'm going to close this PR and re-open another against the 19 repo.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:54:39 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:54:39 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <45yAEXwPWvEqPT03oBHaJgH9HANer_iQ1uDSNGELoiA=.a1e6ee75-275e-407c-a8ce-355f54fab41f@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Address review comments
 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - ... and 6 more: https://git.openjdk.org/jdk/compare/13d4ddc3...b1a494e4

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

Changes: https://git.openjdk.org/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9017&range=03
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9017/head:pull/9017

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

From mcimadamore at openjdk.java.net  Wed Jun 15 18:01:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:01:08 GMT
Subject: Withdrawn: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <68QEAhgjPyyQCGZ7bKIm4b_sNlrxfpUWblsB5miSHy8=.22c49980-caba-4fd0-87a9-851ee63dadfd@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 18:16:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:16:21 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>

This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

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

Commit messages:
 - Add missing files
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287809
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From valeriep at openjdk.java.net  Wed Jun 15 19:41:03 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 15 Jun 2022 19:41:03 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
Message-ID: <uuFFoHmUXObQpSRG9KgJGyQ5SCjvbruUpPxwfQeoOwA=.a2565dbb-ce7e-4b09-a080-00088a021e8d@github.com>

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

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

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 242:

> 240:             dst.put(in, 0, processed);
> 241:         } finally {
> 242:             Arrays.fill(in, (byte)0);

The same handling should be applied to the 'out' buffer allocated on line 177 assuming the idea is to not leaving copies of user data lying around on the heap. Recovered text may contain the same bytes as plain text, so arguably the same handling should be applied to both input/output?

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

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

From weijun at openjdk.java.net  Wed Jun 15 20:02:13 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 15 Jun 2022 20:02:13 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <uuFFoHmUXObQpSRG9KgJGyQ5SCjvbruUpPxwfQeoOwA=.a2565dbb-ce7e-4b09-a080-00088a021e8d@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
 <uuFFoHmUXObQpSRG9KgJGyQ5SCjvbruUpPxwfQeoOwA=.a2565dbb-ce7e-4b09-a080-00088a021e8d@github.com>
Message-ID: <VoMLfDi7RSiEo_c_k097cVInxHhg4g5HtudEGUtvESw=.916e3cd5-37e8-4271-a091-0b17676749b0@github.com>

On Wed, 15 Jun 2022 19:37:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Clearing buffers and temporary arrays to avoid data leaks in cipher operations.
>
> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 242:
> 
>> 240:             dst.put(in, 0, processed);
>> 241:         } finally {
>> 242:             Arrays.fill(in, (byte)0);
> 
> The same handling should be applied to the 'out' buffer allocated on line 177 assuming the idea is to not leaving copies of user data lying around on the heap. Recovered text may contain the same bytes as plain text, so arguably the same handling should be applied to both input/output?

Seems so. BTW, I was using a test-driven programming model and have not observed a leak here. I'll see if I can trigger one.

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

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

From duke at openjdk.java.net  Wed Jun 15 20:21:03 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Wed, 15 Jun 2022 20:21:03 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
Message-ID: <mOB_6xLwBtlXpDoO_oN1HhT-Nc7VeJr9ceVyE8xpnpk=.fcbae310-dc5f-497a-9fcb-d865834eb863@github.com>

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

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

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

> 1012:             dst.flip();
> 1013:             originalDst.put(dst);
> 1014:             dst.clear().put(new byte[dst.capacity()]);

If `dst` is an array-backed ByteByffer, could you use `Array.fill` to avoid a memory allocation? It's surprising to me that ByteBuffer doesn't have a method to set all of the bytes in the ByteBuffer.

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

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

From duke at openjdk.java.net  Wed Jun 15 21:08:08 2022
From: duke at openjdk.java.net (Kevin Driver)
Date: Wed, 15 Jun 2022 21:08:08 GMT
Subject: Integrated: 8220732: setSeed(long) java api doc is missing warning
 about provided seed quality
In-Reply-To: <l5YYV1Rf1lQB4Vno4tCx_qfggfiCZKwg7jRPgWuVdDQ=.8d7bd369-031a-4c9c-8df9-a800f6a34292@github.com>
References: <l5YYV1Rf1lQB4Vno4tCx_qfggfiCZKwg7jRPgWuVdDQ=.8d7bd369-031a-4c9c-8df9-a800f6a34292@github.com>
Message-ID: <GsHL1hozSTl_ka6UVRI_SH6WuvMqDZV77h2Wd5_KXDg=.3683cb85-2539-403e-a5e1-aea2ed11a065@github.com>

On Tue, 14 Jun 2022 16:37:59 GMT, Kevin Driver <duke at openjdk.org> wrote:

> Resolves [JDK-8220732](https://bugs.openjdk.org/browse/JDK-8220732?filter=42718). The additional guidance as been added to the javadoc for `setSeed(long)`

This pull request has now been integrated.

Changeset: 1855e9d2
Author:    Kevin Driver <kevin.driver at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1855e9d2017f315b31f40329b41eb1cf13c59cfe
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8220732: setSeed(long) java api doc is missing warning about provided seed quality

Reviewed-by: wetmore

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

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

From jvernee at openjdk.java.net  Wed Jun 15 22:30:09 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 22:30:09 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <U4NNFOHiB-6BybfOYNa3eluBB_n05D2jZlLgjcx9G-4=.f929fc9d-2990-474d-81c4-ebdad836bb5a@github.com>

On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

Already reviewed in the mainline repo.

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/22

From valeriep at openjdk.java.net  Wed Jun 15 22:30:55 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 15 Jun 2022 22:30:55 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <VoMLfDi7RSiEo_c_k097cVInxHhg4g5HtudEGUtvESw=.916e3cd5-37e8-4271-a091-0b17676749b0@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
 <uuFFoHmUXObQpSRG9KgJGyQ5SCjvbruUpPxwfQeoOwA=.a2565dbb-ce7e-4b09-a080-00088a021e8d@github.com>
 <VoMLfDi7RSiEo_c_k097cVInxHhg4g5HtudEGUtvESw=.916e3cd5-37e8-4271-a091-0b17676749b0@github.com>
Message-ID: <zOrvDJF3XU4fzaWNzkS9TS5fgAxVS8c8dbgUrcRo2YI=.0bcb1d1b-253c-4342-8484-5c8e3ff78793@github.com>

On Wed, 15 Jun 2022 19:58:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 242:
>> 
>>> 240:             dst.put(in, 0, processed);
>>> 241:         } finally {
>>> 242:             Arrays.fill(in, (byte)0);
>> 
>> The same handling should be applied to the 'out' buffer allocated on line 177 assuming the idea is to not leaving copies of user data lying around on the heap. Recovered text may contain the same bytes as plain text, so arguably the same handling should be applied to both input/output?
>
> Seems so. BTW, I was using a test-driven programming model and have not observed a leak here. I'll see if I can trigger one.

Sounds good. Rest of changes look fine.

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

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

From weijun at openjdk.java.net  Wed Jun 15 22:30:56 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 15 Jun 2022 22:30:56 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <mOB_6xLwBtlXpDoO_oN1HhT-Nc7VeJr9ceVyE8xpnpk=.fcbae310-dc5f-497a-9fcb-d865834eb863@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
 <mOB_6xLwBtlXpDoO_oN1HhT-Nc7VeJr9ceVyE8xpnpk=.fcbae310-dc5f-497a-9fcb-d865834eb863@github.com>
Message-ID: <MwxHeYy1qWwK_Uv0U_5OXCZfedc2kD7-xCODqroPy5E=.3807f335-42e3-4183-8c20-7f5e65df62be@github.com>

On Wed, 15 Jun 2022 20:17:47 GMT, Mark Powers <duke at openjdk.org> wrote:

>> Clearing buffers and temporary arrays to avoid data leaks in cipher operations.
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1014:
> 
>> 1012:             dst.flip();
>> 1013:             originalDst.put(dst);
>> 1014:             dst.clear().put(new byte[dst.capacity()]);
> 
> If `dst` is an array-backed ByteByffer, could you use `Array.fill` to avoid a memory allocation? It's surprising to me that ByteBuffer doesn't have a method to set all of the bytes in the ByteBuffer.

Yes, we can.

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

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

From jkuhn at openjdk.java.net  Thu Jun 16 07:31:35 2022
From: jkuhn at openjdk.java.net (Johannes Kuhn)
Date: Thu, 16 Jun 2022 07:31:35 GMT
Subject: RFR: JDK-8288475: Initializing RandomGeneratorFactory.FactoryMapHolder
 fails if a SecurityManager is installed
Message-ID: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>

* This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
* The annotations of the provider classes are now parsed early.  
  This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
* If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
  This avoids parsing annotations of user classes from a privileged context.

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

Commit messages:
 - Fix line endings
 - Initial fix

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

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

From jnimeh at openjdk.org  Thu Jun 16 15:23:32 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 16 Jun 2022 15:23:32 GMT
Subject: RFR: 8288209: SSL debug message wrong about unsupported
 authentication scheme [v2]
In-Reply-To: <2hItx-6albkOAuyDUSW2AtkjSiWBZqjeC77aZzK5StM=.8a366382-ecf8-4cfa-b19c-8163ab8964c3@github.com>
References: <4pgkx8kgS4mJZJwbWS0ObyGGwXAK0SoDcWpuGSQnwtU=.e79b8336-d066-4da8-96b6-39458fc41be7@github.com>
 <2hItx-6albkOAuyDUSW2AtkjSiWBZqjeC77aZzK5StM=.8a366382-ecf8-4cfa-b19c-8163ab8964c3@github.com>
Message-ID: <2u9jc6k7Vvn-nryT5tJ6kZiufN_TT8ei1hjmpxC89rc=.b8e42008-2eb1-4e4c-aed8-fd183b2aca42@github.com>

On Mon, 13 Jun 2022 15:44:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> At the beginning, this bug was about the incorrect warning message "Unsupported authentication scheme" on line 1051 which should have been "This key algorithm has been checked, skip it".
>> 
>> Now, it's a code refactoring that emphasizes only the key algorithm inside a signature scheme is checked in these two methods, and therefore the ignore-if-checked logic in the old code is correct.
>> 
>> Note: `logWarning` is put inside `SSLLogger` so we can get the correct caller line number. Also, please advise if the `|| SSLLogger.logWarning` style looks weird and if there is a better way to filter and log at the same time.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

LGTM

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

Marked as reviewed by jnimeh (Reviewer).

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

From redestad at openjdk.org  Thu Jun 16 15:43:10 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 16 Jun 2022 15:43:10 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks
Message-ID: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>

- Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.

Reduces runtime from estimated 10+ hours to 54 minutes.

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

Commit messages:
 - Reduce runtime of java.security microbenchmarks

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

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

From xuelei at openjdk.org  Thu Jun 16 15:55:00 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 16 Jun 2022 15:55:00 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!P3mU7WBvQpF4QSHNkVOdEIIBqmwa2KSvo7-WmFeGD6B15q1wxtvwq2Au21hqz5cU-qZyGxPosHWAyXGM0Unj5Q$ ).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  remove trailing whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8979/files
  - new: https://git.openjdk.org/jdk/pull/8979/files/bc51397f..6073acb5

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

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

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

From rriggs at openjdk.org  Thu Jun 16 16:11:56 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Jun 2022 16:11:56 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]
In-Reply-To: <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>
Message-ID: <STM_EdzJAndHF8f7AXy1Kx3RMOT0IN4rvpjbsDqECb0=.e4a78277-d1ca-494e-855b-5c4b5541a76c@github.com>

On Thu, 16 Jun 2022 15:55:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!LTtncpyN_2kanJmZF3wz3O88hB5AwboRKEitwQ0UJpiaZQ7RhIZpzgU4kCL3gwrt_JRqji2j5Tb92sOTWGguKw$ ).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing whitespaces

test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 64:

> 62:         assertNotNull(myOwnClassLoaderWeakReference.get());
> 63: 
> 64:         assertTrue(ForceGC.wait(() -> myOwnClassLoaderWeakReference.get() == null));

The call to ref.get() can create a strong reference to the object; depending on the timing it might interfere with the GC in process.
`ref.refersTo(null)` is preferred over `ref.get() == null` 

Here and all subsequent changes.

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

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

From ecaspole at openjdk.org  Thu Jun 16 17:52:24 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 16 Jun 2022 17:52:24 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks
In-Reply-To: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
Message-ID: <Ezv_0Jbzl7vrDmg1x9sxC1CRdac0YlP0YZExgxYhGok=.3162c955-910a-48e9-bce0-646eedb65e89@github.com>

On Thu, 16 Jun 2022 15:35:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
> 
> Reduces runtime from estimated 10+ hours to 54 minutes.

Looks good, thanks!

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

Marked as reviewed by ecaspole (Committer).

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

From mullan at openjdk.org  Thu Jun 16 17:54:58 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Jun 2022 17:54:58 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <RO6qKMSxUOOkB6uLw61XkLIBuvfBjC1gagSCc5WSU-A=.10b2ed0b-ce90-4a4c-93fa-c658f935d827@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

test/jdk/java/util/Random/SecurityManagerFactory.java line 2:

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

Update year to 2022.

test/jdk/java/util/Random/SecurityManagerFactory.java line 29:

> 27:  * @summary Checks if the random factory providers can be loaded when a SecurityManager is active
> 28:  * @bug 8288475
> 29:  * @run main/othervm/policy=java.policy -Djava.security.manager SecurityManagerFactory

You should not need to specify the `java.security.manager` system property as the jtreg `policy` tag will automatically run it under a SecurityManager.

test/jdk/java/util/Random/SecurityManagerFactory.java line 34:

> 32: public class SecurityManagerFactory {
> 33:     public static void main(String[] args) {
> 34:         RandomGeneratorFactory.all().toList();

Should you also check what `RandomGenerator`s are returned when an SM is enabled to make sure it is ok?

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

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

From job at kimmeringer.de  Thu Jun 16 20:02:25 2022
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Thu, 16 Jun 2022 22:02:25 +0200
Subject: Private Keys are cached "forever" leading to inop HTTP-TLS-servers
In-Reply-To: <AM9P193MB1142F9975D6239B948707FA0FFAD9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <f0283220-38b0-6d9b-82f3-c5556c00e4c7@kimmeringer.de>
 <AM9P193MB1142F9975D6239B948707FA0FFAD9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <377bc386-ac52-7466-aa26-5bb94047d29a@kimmeringer.de>

[this is a resend, my last mail seem to have been lost]

Am 15.06.2022 um 13:32 schrieb Bernd Eckenfels:
> This look to me like a bug in the PKCS11 code or - if it is documented -
> in the application. Why do you think it is in JCE?

I'm not sure if there is a SPTB (single point to blame ;-).

  - As mentioned, the contract of java.security.Key doesn't mention any
    requirements if a key should be considered usable for the whole
    duration of the process. This is no wonder given the fact, that the
    Javadoc is from Java 1.1.
  - The PKCS#11-reference documentation doesn't mention anything about
    that, either and there is a part covering PKCS-keystores that
    become unavailable for some time (e.g. USB-based ones) where this
    might be a good place for something like this to be described.

So the inaccuracy in the contract's description can be seen as bug
at least. But the question remains: Has an instance of java.security.Key
to be usable all the time (with keys that rely on resources that can
"go away", I doubt that this is enforceable) and in case they aren't, are
they supposed to become useable again automatically if the resource is
back?

If they are allowed to become unuseable (as explained, I see that as
something that is to be expected IRL) and they don't need
to automatically "repair" themselves, it's a bug in the JVM's TLS
implementation to keep it using even after the first
ProviderException occurred.

If they have to "repair themselves", it's a bug in the HSM's
PKCS#11-library and I have to compose yet another bug-report ;-)
A change in the TLS-implementation might still be considered
(as a feature request that is) to discard the unuseable key
to keep an application using this buggy library running.


Thanks and best regards,

Lothar Kimmeringer

From job at kimmeringer.de  Thu Jun 16 20:09:18 2022
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Thu, 16 Jun 2022 22:09:18 +0200
Subject: Wrong mailadresses in List-mail-headers in mails from security-dev@
Message-ID: <90f3e8ae-3feb-56ac-c3d3-40a2857c2f87@kimmeringer.de>

Hi,

I've had the pronblem that mails, I've sent to the list, got lost in
transmission. The reason is that I've used Thunderbird's "Write to"
and "Respond to" List function that appears as a button if a mail
contains a List-Post-header.

The problem is that there are currently non-working addresses:

List-Archive: <https://mail.openjdk.org/pipermail/security-dev/>
List-Post: <mailto:security-dev at mail.openjdk.org>
List-Help: <mailto:security-dev-request at mail.openjdk.org?subject=help>
List-Subscribe: <https://mail.openjdk.org/mailman/listinfo/security-dev>,
  <mailto:security-dev-request at mail.openjdk.org?subject=subscribe>

mail.openjdk.org doesn't seem to be a valid endpoint and it should
be openjdk.org instead.

I've checked the mails of the clientlib-list and they seem to be
correct, so this might be a secdev-only problem, which is the reason
why I send it to the list (I don't have that many lists subscribed,
so my empirical data is limited ;-)


Thanks and cheers,

Lothar Kimmeringer

From sean.mullan at oracle.com  Thu Jun 16 21:22:22 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 16 Jun 2022 17:22:22 -0400
Subject: Wrong mailadresses in List-mail-headers in mails from
 security-dev@
In-Reply-To: <90f3e8ae-3feb-56ac-c3d3-40a2857c2f87@kimmeringer.de>
References: <90f3e8ae-3feb-56ac-c3d3-40a2857c2f87@kimmeringer.de>
Message-ID: <261d2d54-ca43-8c95-2102-8ba6d534ba0d@oracle.com>

Thanks, looking into the issue and will get back to you.

--Sean

On 6/16/22 4:09 PM, Lothar Kimmeringer wrote:
> Hi,
> 
> I've had the pronblem that mails, I've sent to the list, got lost in
> transmission. The reason is that I've used Thunderbird's "Write to"
> and "Respond to" List function that appears as a button if a mail
> contains a List-Post-header.
> 
> The problem is that there are currently non-working addresses:
> 
> List-Archive: <https://mail.openjdk.org/pipermail/security-dev/>
> List-Post: <mailto:security-dev at mail.openjdk.org>
> List-Help: <mailto:security-dev-request at mail.openjdk.org?subject=help>
> List-Subscribe: <https://mail.openjdk.org/mailman/listinfo/security-dev>,
>    <mailto:security-dev-request at mail.openjdk.org?subject=subscribe>
> 
> mail.openjdk.org doesn't seem to be a valid endpoint and it should
> be openjdk.org instead.
> 
> I've checked the mails of the clientlib-list and they seem to be
> correct, so this might be a secdev-only problem, which is the reason
> why I send it to the list (I don't have that many lists subscribed,
> so my empirical data is limited ;-)
> 
> 
> Thanks and cheers,
> 
> Lothar Kimmeringer

From hchao at openjdk.org  Thu Jun 16 21:58:47 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 16 Jun 2022 21:58:47 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks
In-Reply-To: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
Message-ID: <2eCDdCACImNzdr2OW0t2Ex2myMwI3PQJj01J0LyML5I=.995c4022-d4a8-4b9e-ab66-93fec911e5c0@github.com>

On Thu, 16 Jun 2022 15:35:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
> 
> Reduces runtime from estimated 10+ hours to 54 minutes.

Looks good. Would you also consider to apply the same value or iteration to PermissionsImplies.java and javax/crypto/Crypto.java? The copyright year for some of the Oracle files in this PR can be changed to 2022. Thanks!

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

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

From jkuhn at openjdk.org  Fri Jun 17 03:47:49 2022
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 17 Jun 2022 03:47:49 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <RO6qKMSxUOOkB6uLw61XkLIBuvfBjC1gagSCc5WSU-A=.10b2ed0b-ce90-4a4c-93fa-c658f935d827@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <RO6qKMSxUOOkB6uLw61XkLIBuvfBjC1gagSCc5WSU-A=.10b2ed0b-ce90-4a4c-93fa-c658f935d827@github.com>
Message-ID: <YFWAU6UC5b74XTFHzQPRmyNeOsweoXRyYTm13PGKRkY=.04c42afd-0b7d-4655-9083-c1944806780a@github.com>

On Thu, 16 Jun 2022 17:43:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
>> * The annotations of the provider classes are now parsed early.  
>>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
>> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>>   This avoids parsing annotations of user classes from a privileged context.
>
> test/jdk/java/util/Random/SecurityManagerFactory.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Update year to 2022.

Will fix.

> test/jdk/java/util/Random/SecurityManagerFactory.java line 29:
> 
>> 27:  * @summary Checks if the random factory providers can be loaded when a SecurityManager is active
>> 28:  * @bug 8288475
>> 29:  * @run main/othervm/policy=java.policy -Djava.security.manager SecurityManagerFactory
> 
> You should not need to specify the `java.security.manager` system property as the jtreg `policy` tag will automatically run it under a SecurityManager.

Thanks, was not aware of that

> test/jdk/java/util/Random/SecurityManagerFactory.java line 34:
> 
>> 32: public class SecurityManagerFactory {
>> 33:     public static void main(String[] args) {
>> 34:         RandomGeneratorFactory.all().toList();
> 
> Should you also check what `RandomGenerator`s are returned when an SM is enabled to make sure it is ok?

As long as it doesn't throw it's ok.

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

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

From jpai at openjdk.org  Fri Jun 17 06:47:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 06:47:51 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <xhjVkWfOEVfunuhQ2Rak9ovsjR_SYqfvic8Mq1GdW4A=.892fcb4d-443d-4401-830c-119f0bce2927@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 170:

> 168:                     .filter(p -> !p.type().isAnnotationPresent(Deprecated.class) &&
> 169:                             p.type().isAnnotationPresent(RandomGeneratorProperties.class))
> 170:                     .toList();

Hello Johannes, I haven't yet fully grasped this change, so a few questions:

1. Does this change now mean that in the presence of a SecurityManager, the `RandomGeneratorFactory.all()` method will no longer return instances of `RandomGeneratorFactory` which belong to the application's classloader (those added as Service provider implementations of that interface within the application's jar for example)? Would that then contradict the expectations of the `RandomGeneratorFactory.all()` API and is there any other way to obtain those application specific implementations?
2. I see that this patch now calls `VM.isSystemDomainLoader` in the presence of the SecurityManager. That method implementation internally calls `ClassLoader.getPlatformClassLoader()` which has SecurityManager checks for the `RuntimePermission` for `getClassLoader` permission. Does this call then have to be in a privileged block?
3. Is this entire issue specific only to the `RandomGeneratorFactory.all()` method? For example, I see that there are some other methods which also use the ServiceProvider API to find the relevant provider implementation and there's also an `isDeprecated` method which checks for the presence of an annotation on the provider's implementation. Are those methods affected too?
4.

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

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

From jpai at openjdk.org  Fri Jun 17 06:54:48 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 06:54:48 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 165:

> 163:                 onlyBuiltIn = p -> VM.isSystemDomainLoader(p.type().getClassLoader());
> 164:             } else {
> 165:                 onlyBuiltIn = p -> true;

Should this variable be renamed to something else? Because right now it does the opposite of it's name. i.e. When `onlyBuiltIn` is set to `true`, like here, the code a few lines below which filters the stream accepts all `RandomGeneratorFactory` implementations that have been found.

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

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

From jkuhn at openjdk.org  Fri Jun 17 06:54:49 2022
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 17 Jun 2022 06:54:49 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>
Message-ID: <JaomL_3JtoDSghEyk0HAEYPQBISLtGHEM8iIYlH90e0=.6a553cd3-e95b-44c6-808b-6e144e1af9e0@github.com>

On Fri, 17 Jun 2022 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
>> * The annotations of the provider classes are now parsed early.  
>>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
>> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>>   This avoids parsing annotations of user classes from a privileged context.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 165:
> 
>> 163:                 onlyBuiltIn = p -> VM.isSystemDomainLoader(p.type().getClassLoader());
>> 164:             } else {
>> 165:                 onlyBuiltIn = p -> true;
> 
> Should this variable be renamed to something else? Because right now it does the opposite of it's name. i.e. When `onlyBuiltIn` is set to `true`, like here, the code a few lines below which filters the stream accepts all `RandomGeneratorFactory` implementations that have been found.

Good idea. Naming is hard - and I don't have a good name. Maybe `allowType`?

On second thought, I could change it to `Stream<...> s = ...; if (...) {s = s.filter(...)}`.

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

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

From jpai at openjdk.org  Fri Jun 17 07:06:53 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 07:06:53 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 141:

> 139: 
> 140:     private static class FactoryMapHolder {
> 141:         static final Map<String, Provider<? extends RandomGenerator>> FACTORY_MAP = createFactoryMap();

Unrelated to this PR, but a more general question. It appears that this `FACTORY_MAP` gets cached on first use/call. A few questions about the `createFactoryMap` method:
1. The javadoc of that private method says:

/**
         * Returns the factory map, lazily constructing map on first use.
         *
         * @return Map of RandomGeneratorFactory classes.
         */

But the implementation and the signature of this method actually return a Map of `RandomGenerator` classes and not the `RandomGeneratorFactory` classes.
2. The implementation of this method internally uses the `ServiceLoader` to load the `RandomGenerator` service provider implementations. The internal implementation of the `ServiceLoader` will use a Thread context classloader that is set on the calling thread. The result of the call to this `createFactoryMap` is then cached once and for all in the `FACTORY_MAP`. Would this then lead to a non-deterministic behaviour where whoever ends up initializing this `FactoryMapHolder` first, will end up storing those RandomGenerators for every one else? Is this intentional? Do you think this caching should be reviewed?

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

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

From jkuhn at openjdk.org  Fri Jun 17 07:14:55 2022
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 17 Jun 2022 07:14:55 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>
Message-ID: <KD-Tcm4BGWQeERzwzdeAuhhUQrDEJKUQc2ynmBnVFfw=.782c8efc-e4cb-4cfa-a4e3-2fd41b25b358@github.com>

On Fri, 17 Jun 2022 07:04:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
>> * The annotations of the provider classes are now parsed early.  
>>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
>> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>>   This avoids parsing annotations of user classes from a privileged context.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 141:
> 
>> 139: 
>> 140:     private static class FactoryMapHolder {
>> 141:         static final Map<String, Provider<? extends RandomGenerator>> FACTORY_MAP = createFactoryMap();
> 
> Unrelated to this PR, but a more general question. It appears that this `FACTORY_MAP` gets cached on first use/call. A few questions about the `createFactoryMap` method:
> 1. The javadoc of that private method says:
> 
> /**
>          * Returns the factory map, lazily constructing map on first use.
>          *
>          * @return Map of RandomGeneratorFactory classes.
>          */
> 
> But the implementation and the signature of this method actually return a Map of `RandomGenerator` classes and not the `RandomGeneratorFactory` classes.
> 2. The implementation of this method internally uses the `ServiceLoader` to load the `RandomGenerator` service provider implementations. The internal implementation of the `ServiceLoader` will use a Thread context classloader that is set on the calling thread. The result of the call to this `createFactoryMap` is then cached once and for all in the `FACTORY_MAP`. Would this then lead to a non-deterministic behaviour where whoever ends up initializing this `FactoryMapHolder` first, will end up storing those RandomGenerators for every one else? Is this intentional? Do you think this caching should be reviewed?

Good point. It might be useful to explicitly pass the boot layer to the service loader.

But that is outside the scope of this bug - my goal here is just to make it not throw an exception when running with a SecurityManager while not introducing security vulnerabilities.

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

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

From jpai at openjdk.org  Fri Jun 17 07:14:57 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 07:14:57 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <KD-Tcm4BGWQeERzwzdeAuhhUQrDEJKUQc2ynmBnVFfw=.782c8efc-e4cb-4cfa-a4e3-2fd41b25b358@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>
 <KD-Tcm4BGWQeERzwzdeAuhhUQrDEJKUQc2ynmBnVFfw=.782c8efc-e4cb-4cfa-a4e3-2fd41b25b358@github.com>
Message-ID: <WfOVnFQTfIj0v07hjyH90JQm_aey0kPcugxRCp4S5dE=.0dbd2664-a516-459d-a3ae-a518e848bf44@github.com>

On Fri, 17 Jun 2022 07:10:02 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> But that is outside the scope of this bug

Agreed. I'm not expecting that to be changed in this PR :)  It was more a general question about the implementation.

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

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

From jpai at openjdk.org  Fri Jun 17 10:12:56 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 10:12:56 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <JaomL_3JtoDSghEyk0HAEYPQBISLtGHEM8iIYlH90e0=.6a553cd3-e95b-44c6-808b-6e144e1af9e0@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>
 <JaomL_3JtoDSghEyk0HAEYPQBISLtGHEM8iIYlH90e0=.6a553cd3-e95b-44c6-808b-6e144e1af9e0@github.com>
Message-ID: <xE7Km52cLgQ9brBM-e70h8F6EJ2wDh7Pc9APZpdxwNg=.9cdce373-f6cf-4d9a-9968-62739c9b4846@github.com>

On Fri, 17 Jun 2022 06:50:24 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 165:
>> 
>>> 163:                 onlyBuiltIn = p -> VM.isSystemDomainLoader(p.type().getClassLoader());
>>> 164:             } else {
>>> 165:                 onlyBuiltIn = p -> true;
>> 
>> Should this variable be renamed to something else? Because right now it does the opposite of it's name. i.e. When `onlyBuiltIn` is set to `true`, like here, the code a few lines below which filters the stream accepts all `RandomGeneratorFactory` implementations that have been found.
>
> Good idea. Naming is hard - and I don't have a good name. Maybe `allowType`?
> 
> On second thought, I could change it to `Stream<...> s = ...; if (...) {s = s.filter(...)}`.

I think what you have with the filter call is fine. I think just renaming the `onlyBuiltIn` variable should be enough. Perhaps rename it to `acceptedProviders`?

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

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

From rmartinc at redhat.com  Fri Jun 17 12:23:11 2022
From: rmartinc at redhat.com (Ricardo Martin Camarero)
Date: Fri, 17 Jun 2022 14:23:11 +0200
Subject: Bug JDK-8176553
Message-ID: <04eec9b7-4995-3f88-c2db-ec8ba628dffa@redhat.com>

Hi!

I decided to send an email to the security-dev email list as ldap is
involved. Please redirect me to other list if it is not the proper audience.

The last last days I have faced the same issue that is commented in
JDK-8176553 [1]. Although it is cataloged as fixed in 12, the issue is
not solved in the openjdk master branch yet. You can test with this
simple project [2]. The project is using apache-ds and creating 12
branches with redirects from one to the other. The search should be
limited to 5 hops but you will see that all of them are followed (12).
Therefore, If there are loops, the search hangs indefinitely. So
JDK-8176553 is not fixed completely. You just need `mvn clean test` to
reproduce the problem in that project.

I have investigated and I think the attached little patch fixes the
issue. Mainly the `LdapReferralException` is not stopping the referral
loop in some situations. I have added a test in the jndi jtreg
test-suite to check everything works OK; `make test
TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java`

WDYT? Is the PR worthy?

Thanks in advance!


[1] https://bugs.openjdk.org/browse/JDK-8176553
[2] https://urldefense.com/v3/__https://github.com/rmartinc/apache-ds-referrals__;!!ACWV5N9M2RV99hQ!IZkp5q_gOAeIP8Y9Gvr8aniLloG51lZJwlG1yN6BRDyHHLpyr0W64TDMUPAzoPu7dOBOyJrNcKYmwaOF9REM3oA$ 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8176553.patch
Type: text/x-patch
Size: 9531 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220617/605b3eec/8176553-0001.patch>

From redestad at openjdk.org  Fri Jun 17 12:24:50 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 Jun 2022 12:24:50 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v2]
In-Reply-To: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
Message-ID: <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>

> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
> 
> Reduces runtime from estimated 10+ hours to 54 minutes.

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

  Copyrights, apply consistent settings to PermissionsImplies

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9189/files
  - new: https://git.openjdk.org/jdk/pull/9189/files/263c0ae3..8330c018

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

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

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

From redestad at openjdk.org  Fri Jun 17 12:24:51 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 Jun 2022 12:24:51 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks
In-Reply-To: <2eCDdCACImNzdr2OW0t2Ex2myMwI3PQJj01J0LyML5I=.995c4022-d4a8-4b9e-ab66-93fec911e5c0@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
 <2eCDdCACImNzdr2OW0t2Ex2myMwI3PQJj01J0LyML5I=.995c4022-d4a8-4b9e-ab66-93fec911e5c0@github.com>
Message-ID: <TUHNdjvja50mnEm58172dYhhggbqVi8Ulf5WomKe4MA=.9b881fd0-4f7b-4cf1-933e-658475b131c0@github.com>

On Thu, 16 Jun 2022 21:56:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Looks good. Would you also consider to apply the same value or iteration to PermissionsImplies.java and javax/crypto/Crypto.java? The copyright year for some of the Oracle files in this PR can be changed to 2022. Thanks!

Fixed copyrights and made `PermissionImplies` consistent.

I'm going through micros package-by-package and will deal with javax/crypto microbenchmarks in a follow-up.

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

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

From duke at openjdk.org  Fri Jun 17 16:12:34 2022
From: duke at openjdk.org (Ryan Ernst)
Date: Fri, 17 Jun 2022 16:12:34 GMT
Subject: RFR: 8286389: Address possibly lossy conversions in jdk.crypto.ec
Message-ID: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>

Applied required casts in jdk.crypto.ec for the upcoming warning.
Verified by cherry-picking @asotona's patch.

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

Commit messages:
 - 8286389: Address possibly lossy conversions in jdk.crypto.ec

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

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

From duke at openjdk.org  Fri Jun 17 16:16:28 2022
From: duke at openjdk.org (Ryan Ernst)
Date: Fri, 17 Jun 2022 16:16:28 GMT
Subject: RFR: 8286395: Address possibly lossy conversions in java.security.jgss
Message-ID: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>

Applied required casts in java.security.jgss for the upcoming warning.
Verified by cherry-picking @asotona's patch.

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

Commit messages:
 - 8286395: Address possibly lossy conversions in java.security.jgss

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

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

From sean.mullan at oracle.com  Fri Jun 17 16:20:48 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 17 Jun 2022 12:20:48 -0400
Subject: Wrong mailadresses in List-mail-headers in mails from
 security-dev@
In-Reply-To: <261d2d54-ca43-8c95-2102-8ba6d534ba0d@oracle.com>
References: <90f3e8ae-3feb-56ac-c3d3-40a2857c2f87@kimmeringer.de>
 <261d2d54-ca43-8c95-2102-8ba6d534ba0d@oracle.com>
Message-ID: <032af134-4060-2dd5-7891-9a3764550347@oracle.com>

This should be fixed now. Let us know if you see any more problems.

--Sean

On 6/16/22 5:22 PM, Sean Mullan wrote:
> Thanks, looking into the issue and will get back to you.
> 
> --Sean
> 
> On 6/16/22 4:09 PM, Lothar Kimmeringer wrote:
>> Hi,
>>
>> I've had the pronblem that mails, I've sent to the list, got lost in
>> transmission. The reason is that I've used Thunderbird's "Write to"
>> and "Respond to" List function that appears as a button if a mail
>> contains a List-Post-header.
>>
>> The problem is that there are currently non-working addresses:
>>
>> List-Archive: <https://mail.openjdk.org/pipermail/security-dev/>
>> List-Post: <mailto:security-dev at mail.openjdk.org>
>> List-Help: <mailto:security-dev-request at mail.openjdk.org?subject=help>
>> List-Subscribe: <https://mail.openjdk.org/mailman/listinfo/security-dev>,
>>     <mailto:security-dev-request at mail.openjdk.org?subject=subscribe>
>>
>> mail.openjdk.org doesn't seem to be a valid endpoint and it should
>> be openjdk.org instead.
>>
>> I've checked the mails of the clientlib-list and they seem to be
>> correct, so this might be a secdev-only problem, which is the reason
>> why I send it to the list (I don't have that many lists subscribed,
>> so my empirical data is limited ;-)
>>
>>
>> Thanks and cheers,
>>
>> Lothar Kimmeringer

From chegar at openjdk.org  Fri Jun 17 16:26:55 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 17 Jun 2022 16:26:55 GMT
Subject: RFR: 8286395: Address possibly lossy conversions in
 java.security.jgss
In-Reply-To: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
References: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
Message-ID: <jZYzGEHOg-UZ9Q2aCIFrP0Mc090UQvVxwkaH7s2F00A=.556ba050-1393-478e-b47b-d8ff7895ac92@github.com>

On Fri, 17 Jun 2022 16:09:41 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in java.security.jgss for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Looks good to me. I'm happy to sponsor this change, once a reviewer from the security area has had a chance to take a look.

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

Marked as reviewed by chegar (Reviewer).

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

From chegar at openjdk.org  Fri Jun 17 16:26:57 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 17 Jun 2022 16:26:57 GMT
Subject: RFR: 8286389: Address possibly lossy conversions in jdk.crypto.ec
In-Reply-To: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
References: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
Message-ID: <TzZrjuAK2YR0OfjowlrlWXMAxjTRVBccE4UElHb7OTI=.35f92788-fe95-4012-bbf3-657eb71f2f6f@github.com>

On Fri, 17 Jun 2022 16:05:38 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in jdk.crypto.ec for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Looks good to me. I'm happy to sponsor this change, once a reviewer from the security area has had a chance to take a look.

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

Marked as reviewed by chegar (Reviewer).

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

From mcimadamore at openjdk.org  Fri Jun 17 18:19:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:19:22 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!LqHfEzMnB5I2tQcPYGNk5lbO6mqR2JyzHIqL69ssF926nQucUWim_jTb-W8SGJKAO5suXHZeN0knE-kE0kLuHY9chG57$ 

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into memory_session_cleanup
 - Fix issue in Direct-X-Buffer template
 - Simplify and drop the state class
 - Add missing files
 - Initial push

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

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=01
  Stats: 543 lines in 28 files changed: 48 ins; 110 del; 385 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:24 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:24 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <5qDmnUurtGSqPny2rf0qUp3wafWfpRRvpMJyI_r0VkM=.20cd2a71-bed0-4ef7-80ca-fd6e9efc2528@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!LasBnmlQqj3d1rqmNV1QR8r1A712unwkWeIA-hKEZUsYJKufBEFTSX-saLL9b-ktzJmys5eM5ztcf8vK9D7eX3399d8g$ 

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

  Unify heap vs. implicit scopes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/be81918f..b605aeab

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

  Stats: 12 lines in 3 files changed: 3 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:25 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
Message-ID: <cCTCVBbOOKw_cFTiqNt4rYCnWYWAGKo5S3kiapdTGxI=.663dbdb4-b47c-4b00-909d-156ea8b42ecf@github.com>

On Fri, 17 Jun 2022 18:19:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!MJBIdOCiCKapELuC4Frw5pEuyVqRHww-MJCCcp8fMDAaZcb6YI6rfye8wDUuXhq1hH1KW5uKFYelFb2-TUmhiC3KLuku$ 
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into memory_session_cleanup
>  - Fix issue in Direct-X-Buffer template
>  - Simplify and drop the state class
>  - Add missing files
>  - Initial push

I ended up simplifying this PR, by selecting some of the improvement from the previous patch:
* simplify handling of "readOnly" for memory segments
* Remove duplication between `sessionImpl` and `session` accessors, by making non-closeable views also be subclasses of `MemorySessionImpl`
* use better naming for the `checkValidState` methods - now the plain method is the method that should be used by all clients, while `checkValidStateRaw` is the method that should only be used in ScopedMemoryAccess
* unify exception handling, and fix issues around WrongThreadException not being handled correctly in ScopedMemoryAccess

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

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:39:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:39:03 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!PDiDD7tpqoYwjNISzsD57v-URWsuxLBHjmp7XC7fR0hzuYt2MRflM8_6NU2jfsXK3HxUNhXRZQtpOHvwmbzoJYtLC1v2$ 

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

  Revert implicit vs. heap session changes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/b605aeab..a6841b24

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

  Stats: 14 lines in 5 files changed: 4 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 20:42:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 20:42:59 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
Message-ID: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>

On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!Off-l8NwzAhR8cTQMgW01NR8g_uIjxXm-ftxHRQTWaGPkYDn4G75Nu_mGQ7UaX1HyCOQcQqZA0SL02LVyrHqkt4deq2b$ 
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert implicit vs. heap session changes

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:

> 528:             bufferSession = bufferSegment.session;
> 529:         } else {
> 530:             bufferSession = MemorySessionImpl.heapSession(bb);

I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

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

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 21:50:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 21:50:05 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
 <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
Message-ID: <cw0qgrS7-SFUAkNN-b0fUDZRZJaqTUO8YTAeqohDimk=.1e6ee1ad-4499-4578-b2c8-4087b68fdaae@github.com>

On Fri, 17 Jun 2022 20:39:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert implicit vs. heap session changes
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:
> 
>> 528:             bufferSession = bufferSegment.session;
>> 529:         } else {
>> 530:             bufferSession = MemorySessionImpl.heapSession(bb);
> 
> I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

I've filed a dependent PR for this: https://urldefense.com/v3/__https://github.com/openjdk/jdk19/pull/39__;!!ACWV5N9M2RV99hQ!LNsRgoqWnca5DjZEbihMqD3ymdjqIteLQUbxZka3ZxNFe_KWilsdy2oH81S_xl7V07y10vgZa8C8cHCJF8m0xmdEFD8C$ 

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

PR: https://git.openjdk.org/jdk19/pull/22

From hchao at openjdk.org  Fri Jun 17 22:12:03 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 17 Jun 2022 22:12:03 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v2]
In-Reply-To: <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
 <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
Message-ID: <m2Ujv8kbASZo7l6jmjdYzzdjRfEwS-KkW3jbq-HnilE=.41a7592c-070f-45e2-8f7f-003bbd5df8fe@github.com>

On Fri, 17 Jun 2022 12:24:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
>> 
>> Reduces runtime from estimated 10+ hours to 54 minutes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights, apply consistent settings to PermissionsImplies

Marked as reviewed by hchao (Committer).

Sounds like a good plan. Thanks for the update.

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

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

From duke at openjdk.org  Sat Jun 18 01:40:54 2022
From: duke at openjdk.org (kristylee88)
Date: Sat, 18 Jun 2022 01:40:54 GMT
Subject: RFR: 8286395: Address possibly lossy conversions in
 java.security.jgss
In-Reply-To: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
References: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
Message-ID: <3z4dOO_Seks1qK1L_GPuld5X1FktiprDMjE7oO1to0w=.4a87ac5e-dbff-43e8-b61c-ca13885e0ca4@github.com>

On Fri, 17 Jun 2022 16:09:41 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in java.security.jgss for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

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

From xuelei at openjdk.org  Sat Jun 18 05:55:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 18 Jun 2022 05:55:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!NNGX7uEj58t7UHOcS2PbUgT_R8PW8A2xNlmJ5N8WuCcgG8EPOLJBHAjRiwhXq_NhJ33K0VrDlHQxNLJpVy9XSw$ ).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Master
 - use Reference.refersTo
 - remove trailing whitespaces
 - use timeout factor
 - Merge
 - Merge master
 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282

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

Changes: https://git.openjdk.org/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=09
  Stats: 93 lines in 10 files changed: 14 ins; 38 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979

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

From xuelei at openjdk.org  Sat Jun 18 06:03:54 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 18 Jun 2022 06:03:54 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]
In-Reply-To: <STM_EdzJAndHF8f7AXy1Kx3RMOT0IN4rvpjbsDqECb0=.e4a78277-d1ca-494e-855b-5c4b5541a76c@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>
 <STM_EdzJAndHF8f7AXy1Kx3RMOT0IN4rvpjbsDqECb0=.e4a78277-d1ca-494e-855b-5c4b5541a76c@github.com>
Message-ID: <tHroVfSb3ZE1TjOAPHeaqPRSwjjEp-l6wH-enontRDY=.86887e2d-8aa7-4902-ab54-1520ca4239c6@github.com>

On Thu, 16 Jun 2022 16:08:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove trailing whitespaces
>
> test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 64:
> 
>> 62:         assertNotNull(myOwnClassLoaderWeakReference.get());
>> 63: 
>> 64:         assertTrue(ForceGC.wait(() -> myOwnClassLoaderWeakReference.get() == null));
> 
> The call to ref.get() can create a strong reference to the object; depending on the timing it might interfere with the GC in process.
> `ref.refersTo(null)` is preferred over `ref.get() == null` 
> 
> Here and all subsequent changes.

Good point.  I learned a lot these days from PRs comments!  Thank you!

The patch is changed to use refersTo().

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

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

From aturbanov at openjdk.org  Mon Jun 20 08:07:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Jun 2022 08:07:02 GMT
Subject: Integrated: 8288329: Avoid redundant TreeMap.containsKey call in
 PolicyParser.read
In-Reply-To: <h3SKsjC-DP9XLnFWj8P6Bs1mqoqtJGytmKSixodBLR4=.d65f9822-68d2-4d0c-ab59-742e67dfcb76@github.com>
References: <h3SKsjC-DP9XLnFWj8P6Bs1mqoqtJGytmKSixodBLR4=.d65f9822-68d2-4d0c-ab59-742e67dfcb76@github.com>
Message-ID: <kPnC1BOq0wuY1lXLxqzeMMirfy5_eX5dOsTJIckHNZM=.28d1821d-b07c-4af5-b6ff-a05cf83696d8@github.com>

On Sat, 30 Apr 2022 16:43:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair `TreeMap.containsKey`/`TreeMap.put` method calls, we can use single call `TreeMap.putIfAbsent` and check result for nullness.
> Only non-null values are put into `Map<String, DomainEntry> domainEntries`.
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/53a0acee06eb32fba700967c9a34d37ea42f7a99/src/java.base/share/classes/sun/security/provider/PolicyParser.java*L205-L214__;Iw!!ACWV5N9M2RV99hQ!MYjrZeeC3SvB-PXMjtJ1MKbKVlyU-a4FU-6T-YpF2xuNMD8V4t-D72Yerko2VutSI2IROskm_vBLAiURjVc02YrJaw$ 

This pull request has now been integrated.

Changeset: 7acdcc10
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7acdcc1034fb9529ee7b617889d38b0e557a20ec
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8288329: Avoid redundant TreeMap.containsKey call in PolicyParser.read

Reviewed-by: mullan

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

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

From redestad at openjdk.org  Mon Jun 20 10:27:55 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 10:27:55 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v2]
In-Reply-To: <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
 <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
Message-ID: <3uTN76Vg0t98OCZFAtO_r08BCJNAf1KEH6lpkjmSYVQ=.de768d54-7d61-4a00-944c-d381b6175af4@github.com>

On Fri, 17 Jun 2022 12:24:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
>> 
>> Reduces runtime from estimated 10+ hours to 54 minutes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights, apply consistent settings to PermissionsImplies

Thanks for reviewing!

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

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

From subscriptions at bensmyth.com  Mon Jun 20 12:48:11 2022
From: subscriptions at bensmyth.com (Ben Smyth)
Date: Mon, 20 Jun 2022 14:48:11 +0200
Subject: SSLExtension: Bug/typo in unsupported extension
Message-ID: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>

We have

    // extensions defined in RFC 7250
    CLIENT_CERT_TYPE        (0x0013, "padding"),
    SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),

    // extensions defined in RFC 7685
    PADDING                 (0x0015, "client_certificate_type"),

We should have

    // extensions defined in RFC 7250
    CLIENT_CERT_TYPE        (0x0013, "client_certificate_type"),
    SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),

    // extensions defined in RFC 7685
    PADDING                 (0x0015, "padding"),
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220620/2e63addc/attachment-0001.htm>

From xueleifan at tencent.com  Mon Jun 20 14:09:52 2022
From: xueleifan at tencent.com (xueleifan(XueleiFan))
Date: Mon, 20 Jun 2022 14:09:52 +0000
Subject: [Internet]SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
Message-ID: <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>

Would you mind post the source code or the repository link?  It looks like the code<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLExtension.java__;!!ACWV5N9M2RV99hQ!PwHKnqRDgM-ytcCTUrslz1xQKkQ2DN83ExZf4kyHIV0yzWOQtQ4hWWvLLLfyj2MGc5tK-otM-0tixBFuCA2fsjtn$ > is good in OpenJDK/jdk GitHub.

Regards,
Xuelei

On Jun 20, 2022, at 5:48 AM, Ben Smyth <subscriptions at bensmyth.com<mailto:subscriptions at bensmyth.com>> wrote:

We have

    // extensions defined in RFC 7250
    CLIENT_CERT_TYPE        (0x0013, "padding"),
    SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),

    // extensions defined in RFC 7685
    PADDING                 (0x0015, "client_certificate_type"),

We should have

    // extensions defined in RFC 7250
    CLIENT_CERT_TYPE        (0x0013, "client_certificate_type"),
    SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),

    // extensions defined in RFC 7685
    PADDING                 (0x0015, "padding"),

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

From subscriptions at bensmyth.com  Mon Jun 20 14:38:13 2022
From: subscriptions at bensmyth.com (Ben Smyth)
Date: Mon, 20 Jun 2022 16:38:13 +0200
Subject: [Internet]SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
 <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
Message-ID: <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>

Xuelei,

You're right, OpenJDK/jdk GitHub is correct. I was looking at
hg.openjdk.java.net/jdk/jdk, specifically


https://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/ssl/SSLExtension.java


Ben

On Mon, 20 Jun 2022 at 16:19, xueleifan(XueleiFan) <xueleifan at tencent.com>
wrote:

> Would you mind post the source code or the repository link?  It looks like the
> code
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLExtension.java__;!!ACWV5N9M2RV99hQ!NKebj9uKrLF6gb-37saVUyukQr-EnHuECUvPsDhJS_U2FQ__HEdRupoxA-eK7zAJ1ueKd3-K-vp2clOGvK0QlWU2uHdasaI$ > is
> good in OpenJDK/jdk GitHub.
>
> Regards,
> Xuelei
>
> On Jun 20, 2022, at 5:48 AM, Ben Smyth <subscriptions at bensmyth.com> wrote:
>
> We have
>
>     // extensions defined in RFC 7250
>     CLIENT_CERT_TYPE        (0x0013, "padding"),
>     SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),
>
>     // extensions defined in RFC 7685
>     PADDING                 (0x0015, "client_certificate_type"),
>
> We should have
>
>     // extensions defined in RFC 7250
>     CLIENT_CERT_TYPE        (0x0013, "client_certificate_type"),
>     SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),
>
>     // extensions defined in RFC 7685
>     PADDING                 (0x0015, "padding"),
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220620/095c5960/attachment.htm>

From xueleifan at tencent.com  Mon Jun 20 14:54:43 2022
From: xueleifan at tencent.com (xueleifan(XueleiFan))
Date: Mon, 20 Jun 2022 14:54:43 +0000
Subject: [Internet]Re: SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
 <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
 <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
Message-ID: <6E011060-E969-4214-AE05-1592B4B33C06@Tencent.Com>


On Jun 20, 2022, at 7:38 AM, Ben Smyth <subscriptions at bensmyth.com<mailto:subscriptions at bensmyth.com>> wrote:

Xuelei,

You're right, OpenJDK/jdk GitHub is correct. I was looking at hg.openjdk.java.net/jdk/jdk<http://hg.openjdk.java.net/jdk/jdk>, specifically

    https://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/ssl/SSLExtension.java


I see.  The Github repository is used now, and the hg repository above may be discontinued.

Xuelei



Ben

On Mon, 20 Jun 2022 at 16:19, xueleifan(XueleiFan) <xueleifan at tencent.com<mailto:xueleifan at tencent.com>> wrote:
Would you mind post the source code or the repository link?  It looks like the code<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLExtension.java__;!!ACWV5N9M2RV99hQ!JN_NGx0FSR1eqgQsiUqxhPXr6Oh4N-ukcgtoAJTN2M-6ingXT29z2bVeRcYyGuVSt9WVaJBcTfpIHPz1muEo582J$ > is good in OpenJDK/jdk GitHub.

Regards,
Xuelei

On Jun 20, 2022, at 5:48 AM, Ben Smyth <subscriptions at bensmyth.com<mailto:subscriptions at bensmyth.com>> wrote:

We have

    // extensions defined in RFC 7250
    CLIENT_CERT_TYPE        (0x0013, "padding"),
    SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),

    // extensions defined in RFC 7685
    PADDING                 (0x0015, "client_certificate_type"),

We should have

    // extensions defined in RFC 7250
    CLIENT_CERT_TYPE        (0x0013, "client_certificate_type"),
    SERVER_CERT_TYPE        (0x0014, "server_certificate_type"),

    // extensions defined in RFC 7685
    PADDING                 (0x0015, "padding"),


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

From jai.forums2013 at gmail.com  Mon Jun 20 15:23:15 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 20 Jun 2022 20:53:15 +0530
Subject: [Internet]SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
 <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
 <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
Message-ID: <7802fd29-d3c0-5f7f-02ed-2f6ee85a5962@gmail.com>

Hello Ben,

Like Xuelei noted in his reply, the latest upstream JDK mainline code 
has the necessary fix for this issue. The fix seems to have been done as 
part of some other bigger changes (in Java 16). What you discovered is 
still an issue in versions previous to that (specifically Java 8 and 
Java 11). Do you have a JBS account so that you can create an issue here 
https://bugs.openjdk.org/browse/JDK to track and have this fixed in 
those Java versions? If not, let me know and I'll go ahead create them 
on your behalf.

-Jaikiran

On 20/06/22 8:08 pm, Ben Smyth wrote:
> Xuelei,
>
> You're right, OpenJDK/jdk GitHub is correct. I was looking at 
> hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk>, 
> specifically
>
> https://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/ssl/SSLExtension.java
>
>
> Ben
>
> On Mon, 20 Jun 2022 at 16:19, xueleifan(XueleiFan) 
> <xueleifan at tencent.com> wrote:
>
>     Would you mind post the source code or the repository link?? It
>     looks like the code
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLExtension.java__;!!ACWV5N9M2RV99hQ!NKebj9uKrLF6gb-37saVUyukQr-EnHuECUvPsDhJS_U2FQ__HEdRupoxA-eK7zAJ1ueKd3-K-vp2clOGvK0QlWU2uHdasaI$>?is
>     good in OpenJDK/jdk GitHub.
>
>     Regards,
>     Xuelei
>
>>     On Jun 20, 2022, at 5:48 AM, Ben Smyth
>>     <subscriptions at bensmyth.com> wrote:
>>
>>     We have
>>
>>     ? ? // extensions defined in RFC 7250
>>     ? ? CLIENT_CERT_TYPE ? ? ? ?(0x0013, "padding"),
>>     ? ? SERVER_CERT_TYPE ? ? ? ?(0x0014, "server_certificate_type"),
>>
>>     ? ? // extensions defined in RFC 7685
>>     ? ? PADDING ? ? ? ? ? ? ? ? (0x0015, "client_certificate_type"),
>>
>>     We should have
>>
>>     ? ? // extensions defined in RFC 7250
>>     ? ? CLIENT_CERT_TYPE ? ? ? ?(0x0013, "client_certificate_type"),
>>     ? ? SERVER_CERT_TYPE ? ? ? ?(0x0014, "server_certificate_type"),
>>
>>     ? ? // extensions defined in RFC 7685
>>     ? ? PADDING ? ? ? ? ? ? ? ? (0x0015, "padding"),
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220620/b1759ce2/attachment.htm>

From subscriptions at bensmyth.com  Mon Jun 20 15:35:07 2022
From: subscriptions at bensmyth.com (Ben Smyth)
Date: Mon, 20 Jun 2022 17:35:07 +0200
Subject: [Internet]Re: SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <6E011060-E969-4214-AE05-1592B4B33C06@Tencent.Com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
 <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
 <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
 <6E011060-E969-4214-AE05-1592B4B33C06@Tencent.Com>
Message-ID: <CA+_8xu0a5hH-qTQE3N3v2t-Y4gbUmRq73DXSKB=m3dTcJBM6jA@mail.gmail.com>

On Mon, 20 Jun 2022 at 17:00, xueleifan(XueleiFan)

> I see.  The Github repository is used now, and the hg repository above may
> be discontinued.
>

Thanks for the clarification Xuelei, I'll be sure to use Github.

On Mon, 20 Jun 2022 at 17:23, Jaikiran Pai

> Do you have a JBS account so that you can create an issue here
> https://bugs.openjdk.org/browse/JDK to track and have this fixed in those
> Java versions? If not, let me know and I'll go ahead create them on your
> behalf.
>

Jaikiran, I don't have a JBS account, you can report on my behalf, thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220620/d7a08eca/attachment.htm>

From jai.forums2013 at gmail.com  Tue Jun 21 05:50:55 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 21 Jun 2022 11:20:55 +0530
Subject: [Internet]Re: SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <CA+_8xu0a5hH-qTQE3N3v2t-Y4gbUmRq73DXSKB=m3dTcJBM6jA@mail.gmail.com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
 <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
 <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
 <6E011060-E969-4214-AE05-1592B4B33C06@Tencent.Com>
 <CA+_8xu0a5hH-qTQE3N3v2t-Y4gbUmRq73DXSKB=m3dTcJBM6jA@mail.gmail.com>
Message-ID: <cd4d829c-4468-8a8d-a078-ffae5c7cedca@gmail.com>


On 20/06/22 9:05 pm, Ben Smyth wrote:
> On Mon, 20 Jun 2022 at 17:00, xueleifan(XueleiFan)
>
>     I see.? The Github repository is used now, and the hg repository
>     above may be?discontinued.
>
>
> Thanks for the clarification Xuelei, I'll be sure to use Github.
> On Mon, 20 Jun 2022 at 17:23, Jaikiran Pai
>
>     Do you have a JBS account so that you can create an issue here
>     https://bugs.openjdk.org/browse/JDK to track and have this fixed
>     in those Java versions? If not, let me know and I'll go ahead
>     create them on your behalf.
>
>
> Jaikiran, I don't have a JBS account, you can report on my behalf, thanks.
>
I've created https://bugs.openjdk.org/browse/JDK-8288794


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

From subscriptions at bensmyth.com  Tue Jun 21 07:12:49 2022
From: subscriptions at bensmyth.com (Ben Smyth)
Date: Tue, 21 Jun 2022 09:12:49 +0200
Subject: [Internet]Re: SSLExtension: Bug/typo in unsupported extension
In-Reply-To: <cd4d829c-4468-8a8d-a078-ffae5c7cedca@gmail.com>
References: <CA+_8xu1+_A1L_RXDTrfd_X_xPDTM6o4Tq9PiTv4Ym9KJkNy2dA@mail.gmail.com>
 <43E5D88A-485F-4372-A741-D2FD85237E6A@Tencent.Com>
 <CA+_8xu0TEB4qS-fw4YA_ZsJSwYkW9dPJKOqDKGftDQP=hbP42Q@mail.gmail.com>
 <6E011060-E969-4214-AE05-1592B4B33C06@Tencent.Com>
 <CA+_8xu0a5hH-qTQE3N3v2t-Y4gbUmRq73DXSKB=m3dTcJBM6jA@mail.gmail.com>
 <cd4d829c-4468-8a8d-a078-ffae5c7cedca@gmail.com>
Message-ID: <CA+_8xu3GpHEDYpxzDhjoadQ2nD8hvz50Vvwnuk1kL1poPezQeg@mail.gmail.com>

Thanks Jaikiran. Since RFC 7250 &7685 are unsupported, this isn't
particularly significant. (I discovered whilst looking for raw public key
support.)

On Tue, 21 Jun 2022 at 07:51, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

>
> On 20/06/22 9:05 pm, Ben Smyth wrote:
>
> On Mon, 20 Jun 2022 at 17:00, xueleifan(XueleiFan)
>
>> I see.  The Github repository is used now, and the hg repository above
>> may be discontinued.
>>
>
> Thanks for the clarification Xuelei, I'll be sure to use Github.
>
> On Mon, 20 Jun 2022 at 17:23, Jaikiran Pai
>
>> Do you have a JBS account so that you can create an issue here
>> https://bugs.openjdk.org/browse/JDK to track and have this fixed in
>> those Java versions? If not, let me know and I'll go ahead create them on
>> your behalf.
>>
>
> Jaikiran, I don't have a JBS account, you can report on my behalf, thanks.
>
> I've created https://bugs.openjdk.org/browse/JDK-8288794
>
>
> -Jaikiran
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220621/e7b5d42d/attachment.htm>

From aph-open at littlepinkcloud.com  Tue Jun 21 07:32:03 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 21 Jun 2022 08:32:03 +0100
Subject: Private Keys are cached "forever" leading to inop HTTP-TLS-servers
In-Reply-To: <377bc386-ac52-7466-aa26-5bb94047d29a@kimmeringer.de>
References: <f0283220-38b0-6d9b-82f3-c5556c00e4c7@kimmeringer.de>
 <AM9P193MB1142F9975D6239B948707FA0FFAD9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <377bc386-ac52-7466-aa26-5bb94047d29a@kimmeringer.de>
Message-ID: <7beb1942-8d55-19a0-1dea-892d4ce11c10@littlepinkcloud.com>

On 6/16/22 21:02, Lothar Kimmeringer wrote:
> If they are allowed to become unuseable (as explained, I see that as
> something that is to be expected IRL)

I don't think they are. There is nothing in PKCS#11 that gives an implementation
any permission to time out.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!JWFTUuaaENCVogZet_voTXNz393V2ewVZcuErhjsKanMTJhbCm39xc98M_xGyuW5SH7L5iTmP3ipmB76_VGGmD3jxTqjiw$ >
https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!JWFTUuaaENCVogZet_voTXNz393V2ewVZcuErhjsKanMTJhbCm39xc98M_xGyuW5SH7L5iTmP3ipmB76_VGGmD0v5MXQog$ 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From dfuchs at openjdk.org  Tue Jun 21 11:20:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Jun 2022 11:20:40 GMT
Subject: RFR: 8286389: Address possibly lossy conversions in jdk.crypto.ec
In-Reply-To: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
References: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
Message-ID: <ImXP30Vze9l5ztVU1KyB_pAgzZvmBKsAvh_R_uCo_3o=.6d5b1cd6-ab0a-48de-8eb0-218ff29a7558@github.com>

On Fri, 17 Jun 2022 16:05:38 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in jdk.crypto.ec for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Looks reasonable to me  - but it would be good to have someone from security-dev take a look.

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

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

From dfuchs at openjdk.org  Tue Jun 21 11:23:41 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Jun 2022 11:23:41 GMT
Subject: RFR: 8286395: Address possibly lossy conversions in
 java.security.jgss
In-Reply-To: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
References: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
Message-ID: <yvS_RlFpxRPWUbjNDdARxeDsYjn6yO2xobyy5ayQH5Q=.8f7a1ed2-0d86-4532-87cf-d0a728c14f8a@github.com>

On Fri, 17 Jun 2022 16:09:41 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in java.security.jgss for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Looks reasonable to me - but it we be good to have someone from security-dev take a look.

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

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

From job at kimmeringer.de  Tue Jun 21 12:28:17 2022
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Tue, 21 Jun 2022 14:28:17 +0200
Subject: Private Keys are cached "forever" leading to inop HTTP-TLS-servers
In-Reply-To: <7beb1942-8d55-19a0-1dea-892d4ce11c10@littlepinkcloud.com>
References: <f0283220-38b0-6d9b-82f3-c5556c00e4c7@kimmeringer.de>
 <AM9P193MB1142F9975D6239B948707FA0FFAD9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <377bc386-ac52-7466-aa26-5bb94047d29a@kimmeringer.de>
 <7beb1942-8d55-19a0-1dea-892d4ce11c10@littlepinkcloud.com>
Message-ID: <9c473f06-c134-5885-c0a4-38309c0222bd@kimmeringer.de>



Am 21.06.2022 um 09:32 schrieb Andrew Haley:
> On 6/16/22 21:02, Lothar Kimmeringer wrote:
>> If they are allowed to become unuseable (as explained, I see that as
>> something that is to be expected IRL)
> 
> I don't think they are. There is nothing in PKCS#11 that gives an implementation
> any permission to time out.

It's not only session timeouts that can make a Key unusable. An HSM
might become unavailable during runtime, e.g. if it is a USB-stick
that has been temporarily removed. So any operation that requires
this key will fail.


Thanks and best regards,

Lothar Kimmeringer

From weijun at openjdk.org  Tue Jun 21 14:36:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Jun 2022 14:36:53 GMT
Subject: Integrated: 8288209: SSL debug message wrong about unsupported
 authentication scheme
In-Reply-To: <4pgkx8kgS4mJZJwbWS0ObyGGwXAK0SoDcWpuGSQnwtU=.e79b8336-d066-4da8-96b6-39458fc41be7@github.com>
References: <4pgkx8kgS4mJZJwbWS0ObyGGwXAK0SoDcWpuGSQnwtU=.e79b8336-d066-4da8-96b6-39458fc41be7@github.com>
Message-ID: <QZpw1PwR5YMvWozWFmqwXE9O5z4gVQu-Y2t3vzlJCJk=.1ddf0a97-68ed-4198-922e-4e014521db62@github.com>

On Mon, 13 Jun 2022 14:53:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> At the beginning, this bug was about the incorrect warning message "Unsupported authentication scheme" on line 1051 which should have been "This key algorithm has been checked, skip it".
> 
> Now, it's a code refactoring that emphasizes only the key algorithm inside a signature scheme is checked in these two methods, and therefore the ignore-if-checked logic in the old code is correct.
> 
> Note: `logWarning` is put inside `SSLLogger` so we can get the correct caller line number. Also, please advise if the `|| SSLLogger.logWarning` style looks weird and if there is a better way to filter and log at the same time.

This pull request has now been integrated.

Changeset: 19017358
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19017358b1b3c63fdddc1eecb2fe52f7b7d4b6e3
Stats:     106 lines in 5 files changed: 9 ins; 57 del; 40 mod

8288209: SSL debug message wrong about unsupported authentication scheme

Reviewed-by: djelinski, jnimeh

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

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

From xuelei at openjdk.org  Tue Jun 21 16:51:34 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 21 Jun 2022 16:51:34 GMT
Subject: RFR: 8286389: Address possibly lossy conversions in jdk.crypto.ec
In-Reply-To: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
References: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
Message-ID: <16Gy1vM87LSDeG2Sp6vs0tW2w7gSl8ds-aujUAMnaA0=.e08112fe-709d-4502-8842-a9f3c27cfe82@github.com>

On Fri, 17 Jun 2022 16:05:38 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in jdk.crypto.ec for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Marked as reviewed by xuelei (Reviewer).

src/jdk.crypto.ec/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 79:

> 77:         int bitsMod8 = params.getBits() % 8;
> 78:         if (bitsMod8 != 0) {
> 79:             byte mask = (byte) ((1 << bitsMod8) - 1);

I may not insert a whitespace after the "(byte)" conversion.  Similar to following update.  Otherwise, looks good to me.

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

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

From duke at openjdk.org  Tue Jun 21 21:59:20 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Tue, 21 Jun 2022 21:59:20 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is
 not logged
Message-ID: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>

Could you please review the changes?
This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

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

Commit messages:
 - 8215916: Print out more information as a part of failure reason of an optional JAAS LoginModule

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

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

From weijun at openjdk.org  Tue Jun 21 22:10:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Jun 2022 22:10:02 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <zOrvDJF3XU4fzaWNzkS9TS5fgAxVS8c8dbgUrcRo2YI=.0bcb1d1b-253c-4342-8484-5c8e3ff78793@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
 <uuFFoHmUXObQpSRG9KgJGyQ5SCjvbruUpPxwfQeoOwA=.a2565dbb-ce7e-4b09-a080-00088a021e8d@github.com>
 <VoMLfDi7RSiEo_c_k097cVInxHhg4g5HtudEGUtvESw=.916e3cd5-37e8-4271-a091-0b17676749b0@github.com>
 <zOrvDJF3XU4fzaWNzkS9TS5fgAxVS8c8dbgUrcRo2YI=.0bcb1d1b-253c-4342-8484-5c8e3ff78793@github.com>
Message-ID: <O5UWVsxkZjOxn00cp6ctISCpdHH8_oFGR2u2yJQIKCc=.8f1e61c2-1001-412a-a8f8-dbab165029e8@github.com>

On Wed, 15 Jun 2022 22:27:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Seems so. BTW, I was using a test-driven programming model and have not observed a leak here. I'll see if I can trigger one.
>
> Sounds good. Rest of changes look fine.

I cannot reproduce this leak, but I found more by mixing the calls on byte array and `ByteBuffer`, and data length of whole block and half block. I'll study more and maybe some sort of fuzzy testing is needed.

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

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

From subscriptions at bensmyth.com  Wed Jun 22 10:22:01 2022
From: subscriptions at bensmyth.com (Ben Smyth)
Date: Wed, 22 Jun 2022 12:22:01 +0200
Subject: JSSE: SSLEngine reporting HandshakeStatus.FINISHED,
 disabling NewSessionTicket
In-Reply-To: <CA+_8xu37yJM2Yz2agq33toQLMvs5qYZz=xidaGMygdJ-O1SyEg@mail.gmail.com>
References: <CA+_8xu37yJM2Yz2agq33toQLMvs5qYZz=xidaGMygdJ-O1SyEg@mail.gmail.com>
Message-ID: <CA+_8xu02PMMgKJKFKti98VK+-HxFifEwLcfFqhbTf4TVVnKDhg@mail.gmail.com>

On Tue, 24 May 2022 at 17:20, Ben Smyth wrote:

> Javadoc advises HandshakeStatus.FINISHED is reported when "a call to
> SSLEngine.wrap() / unwrap() ... finishes a handshake." As expected,
>
> * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping a
> client's (TLS) FINISHED message.
>
> By comparison, rather than report (server) handshake completion upon
> unwrapping a client's (TLS) FINISHED message,
>

Actually, (server) handshake completion *is* reported upon unwrapping a
client's FINISHED message, *but* only when the client's ClientHello message
omits extension psk_key_exchange_modes.


> Can production of NewSessionTicket be disabled?
>

Omitting extension psk_key_exchange_modes suppresses NewSessionTicket
production, but it doesn't seem possible to disable extension
psk_key_exchange_modes for OpenJDK ClientHello messages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220622/1e5b21d0/attachment-0001.htm>

From mullan at openjdk.org  Wed Jun 22 13:13:55 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 22 Jun 2022 13:13:55 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 887:

> 885:                             (new java.io.PrintWriter(sw));
> 886:                     sw.flush();
> 887:                     le = new LoginException(sw.toString());

@wangweij might have more to say, but I think you just want to dump this information using `debug.println` if debug is enabled.

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

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

From weijun at openjdk.org  Wed Jun 22 13:55:54 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Jun 2022 13:55:54 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>
Message-ID: <d04cQLBFo8iHXOfMfywQKUnTzOGC_BzkcjwHEjP4haY=.139c361e-5ca8-4b57-a0ee-405927b88d8c@github.com>

On Wed, 22 Jun 2022 13:10:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Could you please review the changes?
>> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug
>
> src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 887:
> 
>> 885:                             (new java.io.PrintWriter(sw));
>> 886:                     sw.flush();
>> 887:                     le = new LoginException(sw.toString());
> 
> @wangweij might have more to say, but I think you just want to dump this information using `debug.println` if debug is enabled.

I have the same suggestion as Sean. In JAAS, login could succeed even if one optional LoginModule failed, and in this case the reason for that failure is lost (even with your current fix). Logging it somewhere might help developer understand why it happened.

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

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

From duke at openjdk.org  Wed Jun 22 14:15:40 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 22 Jun 2022 14:15:40 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <d04cQLBFo8iHXOfMfywQKUnTzOGC_BzkcjwHEjP4haY=.139c361e-5ca8-4b57-a0ee-405927b88d8c@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>
 <d04cQLBFo8iHXOfMfywQKUnTzOGC_BzkcjwHEjP4haY=.139c361e-5ca8-4b57-a0ee-405927b88d8c@github.com>
Message-ID: <uqfn0eQ2NIs9IE2NBihg2jv8i7e5mtKJzngkuy5jcNE=.a32addb4-e9b7-4d59-a5aa-4f3676b4d2f1@github.com>

On Wed, 22 Jun 2022 13:52:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 887:
>> 
>>> 885:                             (new java.io.PrintWriter(sw));
>>> 886:                     sw.flush();
>>> 887:                     le = new LoginException(sw.toString());
>> 
>> @wangweij might have more to say, but I think you just want to dump this information using `debug.println` if debug is enabled.
>
> I have the same suggestion as Sean. In JAAS, login could succeed even if one optional LoginModule failed, and in this case the reason for that failure is lost (even with your current fix). Logging it somewhere might help developer understand why it happened.

Thanks you both for taking a look at this PR.
I will investigate further for suitable suggested changes.
Could you please suggest me how I can quickly check whether the changes I made are reflecting properly as expected ?

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

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

From weijun at openjdk.org  Wed Jun 22 15:12:56 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Jun 2022 15:12:56 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <uqfn0eQ2NIs9IE2NBihg2jv8i7e5mtKJzngkuy5jcNE=.a32addb4-e9b7-4d59-a5aa-4f3676b4d2f1@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>
 <d04cQLBFo8iHXOfMfywQKUnTzOGC_BzkcjwHEjP4haY=.139c361e-5ca8-4b57-a0ee-405927b88d8c@github.com>
 <uqfn0eQ2NIs9IE2NBihg2jv8i7e5mtKJzngkuy5jcNE=.a32addb4-e9b7-4d59-a5aa-4f3676b4d2f1@github.com>
Message-ID: <tDPOPDcPugibHu-CLA4hHsPp4nWQaVW9tLbhVl-MhHI=.fed264bf-0835-49a7-972c-19b5be1be540@github.com>

On Wed, 22 Jun 2022 14:12:34 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> I have the same suggestion as Sean. In JAAS, login could succeed even if one optional LoginModule failed, and in this case the reason for that failure is lost (even with your current fix). Logging it somewhere might help developer understand why it happened.
>
> Thanks you both for taking a look at this PR.
> I will investigate further for suitable suggested changes.
> Could you please suggest me how I can quickly check whether the changes I made are reflecting properly as expected ?

There are several builtin `LoginModule` implementations inside OpenJDK. For example, you can configure both `NTLoginModule` and `UnixLoginModule` as OPTIONAL in your JAAS login configuration file. No matter if you run on Windows or Linux, one will succeed and one will fail but overall the login will succeed. You can set `-Djava.security.debug=logincontext` to see if there is information on the failed one.

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

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

From weijun at openjdk.org  Wed Jun 22 15:22:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Jun 2022 15:22:44 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <tDPOPDcPugibHu-CLA4hHsPp4nWQaVW9tLbhVl-MhHI=.fed264bf-0835-49a7-972c-19b5be1be540@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>
 <d04cQLBFo8iHXOfMfywQKUnTzOGC_BzkcjwHEjP4haY=.139c361e-5ca8-4b57-a0ee-405927b88d8c@github.com>
 <uqfn0eQ2NIs9IE2NBihg2jv8i7e5mtKJzngkuy5jcNE=.a32addb4-e9b7-4d59-a5aa-4f3676b4d2f1@github.com>
 <tDPOPDcPugibHu-CLA4hHsPp4nWQaVW9tLbhVl-MhHI=.fed264bf-0835-49a7-972c-19b5be1be540@github.com>
Message-ID: <67V29u7Ly5U0wWajhos0Sqs38YIZFVMHrWfnQVm6010=.1f793672-42cd-4f1e-ab46-b3bf9b577333@github.com>

On Wed, 22 Jun 2022 15:10:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thanks you both for taking a look at this PR.
>> I will investigate further for suitable suggested changes.
>> Could you please suggest me how I can quickly check whether the changes I made are reflecting properly as expected ?
>
> There are several builtin `LoginModule` implementations inside OpenJDK. For example, you can configure both `NTLoginModule` and `UnixLoginModule` as OPTIONAL in your JAAS login configuration file. No matter if you run on Windows or Linux, one will succeed and one will fail but overall the login will succeed. You can set `-Djava.security.debug=logincontext` to see if there is information on the failed one.

Also, if you like, try writing this as a regression test. You can call `System.setErr` at the beginning to redirect the log messages to your own `ByteArrayOutputStream`, and then after restoring the original `System.err`, you can inspect the output to see if the expected log message is there. This is not necessary since the code change is not significant.

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

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

From duke at openjdk.org  Wed Jun 22 15:50:16 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 22 Jun 2022 15:50:16 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator works with ChaCha20-Poly1305
Message-ID: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>

TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].


make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
...
javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
	at SSLSocketClient.test(SSLSocketClient.java:72)
	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
	at Main.main(Main.java:30)
Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
	... 7 more

FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256


Problem:
Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).

Fix:
This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 

Testing:
I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.

[1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!Ihr0-QNcHHQghvFIHn5mTJbrqQfZkUgTNfcVcmxcKSmszIs-Ay8aQCf8QK0PQehO3gGnwLmsflHhm3-fz88$ 
[2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!Ihr0-QNcHHQghvFIHn5mTJbrqQfZkUgTNfcVcmxcKSmszIs-Ay8aQCf8QK0PQehO3gGnwLmsflHhA4rf0DE$ 
[3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!Ihr0-QNcHHQghvFIHn5mTJbrqQfZkUgTNfcVcmxcKSmszIs-Ay8aQCf8QK0PQehO3gGnwLmsflHh5rBEGEw$ 
[4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!Ihr0-QNcHHQghvFIHn5mTJbrqQfZkUgTNfcVcmxcKSmszIs-Ay8aQCf8QK0PQehO3gGnwLmsflHhaPGjS2w$ 
[5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!Ihr0-QNcHHQghvFIHn5mTJbrqQfZkUgTNfcVcmxcKSmszIs-Ay8aQCf8QK0PQehO3gGnwLmsflHhfBU8aN4$ 
[6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!Ihr0-QNcHHQghvFIHn5mTJbrqQfZkUgTNfcVcmxcKSmszIs-Ay8aQCf8QK0PQehO3gGnwLmsflHh3avgySo$ 

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

Commit messages:
 - Key material generator works with ChaCha20-Poly1305

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

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

From duke at openjdk.org  Wed Jun 22 15:59:44 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 22 Jun 2022 15:59:44 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator works with
 ChaCha20-Poly1305 [v2]
In-Reply-To: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
Message-ID: <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>

> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
> 
> 
> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
> ...
> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> 	at SSLSocketClient.test(SSLSocketClient.java:72)
> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
> 	at Main.main(Main.java:30)
> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> 	... 7 more
> 
> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> 
> 
> Problem:
> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
> 
> Fix:
> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
> 
> Testing:
> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
> 
> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!OQl-COyTBJFcnEQ2FnUPM9RYvMtwDbSpcLbGXdw-xBCSFbGvLSIU2TA345qNdUAkuQiFVRCTpAOhWnlIghM$ 
> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!OQl-COyTBJFcnEQ2FnUPM9RYvMtwDbSpcLbGXdw-xBCSFbGvLSIU2TA345qNdUAkuQiFVRCTpAOh9m17XQY$ 
> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!OQl-COyTBJFcnEQ2FnUPM9RYvMtwDbSpcLbGXdw-xBCSFbGvLSIU2TA345qNdUAkuQiFVRCTpAOhmnxgjfs$ 
> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!OQl-COyTBJFcnEQ2FnUPM9RYvMtwDbSpcLbGXdw-xBCSFbGvLSIU2TA345qNdUAkuQiFVRCTpAOhlNK3BJw$ 
> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!OQl-COyTBJFcnEQ2FnUPM9RYvMtwDbSpcLbGXdw-xBCSFbGvLSIU2TA345qNdUAkuQiFVRCTpAOh1UCVhr4$ 
> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!OQl-COyTBJFcnEQ2FnUPM9RYvMtwDbSpcLbGXdw-xBCSFbGvLSIU2TA345qNdUAkuQiFVRCTpAOhcZ21CGY$ 

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

  TestKeyMaterialChaCha20.java: Added bug number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9072/files
  - new: https://git.openjdk.org/jdk/pull/9072/files/8fdd7b9f..514da32e

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

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

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

From hchao at openjdk.org  Thu Jun 23 00:48:01 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 23 Jun 2022 00:48:01 GMT
Subject: RFR: 8286259: Password cleanup after KeyStore.PasswordProtection in
 P11KeyStore
Message-ID: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>

Please review the small update for JDK-8286259.

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

Commit messages:
 - 8286259: Password cleanup after KeyStore.PasswordProtection in P11KeyStore

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

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

From valeriep at openjdk.org  Thu Jun 23 16:41:55 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 16:41:55 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator works with
 ChaCha20-Poly1305 [v2]
In-Reply-To: <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>
Message-ID: <LBqHliHMjnnqZbyrsKfTejT-M831HBfcNTshMMJH-Ys=.e173f781-520a-4022-b439-61ab3b2afdfa@github.com>

On Wed, 22 Jun 2022 15:59:44 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!OWeUzDfyrNVflo7dTHlv4daZhaEdepfQLaHLQWMVx2Cdlq74hmuBMs8kYw9zUxy4h44mfiZW4E_dPG3WeajzDYyu$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!OWeUzDfyrNVflo7dTHlv4daZhaEdepfQLaHLQWMVx2Cdlq74hmuBMs8kYw9zUxy4h44mfiZW4E_dPG3WeYLyw-OJ$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!OWeUzDfyrNVflo7dTHlv4daZhaEdepfQLaHLQWMVx2Cdlq74hmuBMs8kYw9zUxy4h44mfiZW4E_dPG3WebnXB3tq$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!OWeUzDfyrNVflo7dTHlv4daZhaEdepfQLaHLQWMVx2Cdlq74hmuBMs8kYw9zUxy4h44mfiZW4E_dPG3WeS3Lz4_h$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!OWeUzDfyrNVflo7dTHlv4daZhaEdepfQLaHLQWMVx2Cdlq74hmuBMs8kYw9zUxy4h44mfiZW4E_dPG3WefY9v6H4$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!OWeUzDfyrNVflo7dTHlv4daZhaEdepfQLaHLQWMVx2Cdlq74hmuBMs8kYw9zUxy4h44mfiZW4E_dPG3WeUAnTQ-p$ 
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestKeyMaterialChaCha20.java: Added bug number

The title generally state the problem, or action/expectation. How about either "P11TlsKeyMaterialGenerator does not work with ChaCha20-Poly1305" or "P11TlsKeyMaterialGenerator should work with ChaCha20-Poly1305"?

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

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

From duke at openjdk.org  Thu Jun 23 16:50:54 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Thu, 23 Jun 2022 16:50:54 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <67V29u7Ly5U0wWajhos0Sqs38YIZFVMHrWfnQVm6010=.1f793672-42cd-4f1e-ab46-b3bf9b577333@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <sAkggWbnogVXCK6glRjUS7wc5tV7031zuG4t0A8sdt8=.02685b60-bad2-4476-9902-be1867e44bd4@github.com>
 <d04cQLBFo8iHXOfMfywQKUnTzOGC_BzkcjwHEjP4haY=.139c361e-5ca8-4b57-a0ee-405927b88d8c@github.com>
 <uqfn0eQ2NIs9IE2NBihg2jv8i7e5mtKJzngkuy5jcNE=.a32addb4-e9b7-4d59-a5aa-4f3676b4d2f1@github.com>
 <tDPOPDcPugibHu-CLA4hHsPp4nWQaVW9tLbhVl-MhHI=.fed264bf-0835-49a7-972c-19b5be1be540@github.com>
 <67V29u7Ly5U0wWajhos0Sqs38YIZFVMHrWfnQVm6010=.1f793672-42cd-4f1e-ab46-b3bf9b577333@github.com>
Message-ID: <tCYVpfUqqkI1rxW_jORPWXQqKRYCEwagSyeUjMJ4lXU=.9a881b3d-8edb-43af-854f-2090a9fbec11@github.com>

On Wed, 22 Jun 2022 15:18:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There are several builtin `LoginModule` implementations inside OpenJDK. For example, you can configure both `NTLoginModule` and `UnixLoginModule` as OPTIONAL in your JAAS login configuration file. No matter if you run on Windows or Linux, one will succeed and one will fail but overall the login will succeed. You can set `-Djava.security.debug=logincontext` to see if there is information on the failed one.
>
> Also, if you like, try writing this as a regression test. You can call `System.setErr` at the beginning to redirect the log messages to your own `ByteArrayOutputStream`, and then after restoring the original `System.err`, you can inspect the output to see if the expected log message is there. This is not necessary since the code change is not significant.

@wangweij Thank you I will try these.

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

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

From valeriep at openjdk.org  Thu Jun 23 16:50:58 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 16:50:58 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator works with
 ChaCha20-Poly1305 [v2]
In-Reply-To: <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>
Message-ID: <vy9DPrnka2SA_8UmHDZA0K8jidwQorcBbse-NLCLXSM=.1d57fd5d-9193-4944-9674-a678342dde20@github.com>

On Wed, 22 Jun 2022 15:59:44 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!NSwMcP_0Y78eDFk_Xa-lsC66x3js2YTsd1Hkj-6KYtWDvCabtchg5qmAdioH7DHKsNNKmqvJwkK3HJ7uM2OJfHyZ$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!NSwMcP_0Y78eDFk_Xa-lsC66x3js2YTsd1Hkj-6KYtWDvCabtchg5qmAdioH7DHKsNNKmqvJwkK3HJ7uM-KQolxR$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!NSwMcP_0Y78eDFk_Xa-lsC66x3js2YTsd1Hkj-6KYtWDvCabtchg5qmAdioH7DHKsNNKmqvJwkK3HJ7uMyDvdnGM$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!NSwMcP_0Y78eDFk_Xa-lsC66x3js2YTsd1Hkj-6KYtWDvCabtchg5qmAdioH7DHKsNNKmqvJwkK3HJ7uM6azgxGn$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!NSwMcP_0Y78eDFk_Xa-lsC66x3js2YTsd1Hkj-6KYtWDvCabtchg5qmAdioH7DHKsNNKmqvJwkK3HJ7uMxncGE48$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!NSwMcP_0Y78eDFk_Xa-lsC66x3js2YTsd1Hkj-6KYtWDvCabtchg5qmAdioH7DHKsNNKmqvJwkK3HJ7uM37U6uEn$ 
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestKeyMaterialChaCha20.java: Added bug number

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 104:

> 102:         if ("ChaCha20-Poly1305".equals(algorithm)) {
> 103:             algorithm = "ChaCha20";
> 104:         }

Have you considered adding "ChaCha20-Poly1305" into the "keyTypes" instead? Then you don't need to add the if-block here.

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

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

From valeriep at openjdk.org  Thu Jun 23 19:13:53 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 19:13:53 GMT
Subject: RFR: 8286259: Password cleanup after KeyStore.PasswordProtection
 in P11KeyStore
In-Reply-To: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>
References: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>
Message-ID: <g0RSt8CGLMS1xZUNsnbGe0gr7U-Q3kXa4uUBwcogXlk=.3c276273-4518-4c4e-b9ec-32eb17a96310@github.com>

On Thu, 23 Jun 2022 00:41:07 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the small update for JDK-8286259.

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

> 467:                 // ignore
> 468:             }
> 469:         }

This particular change looks fine. 
However, I noticed that there is another local PasswordProtection object inside the KeyStoreLoadParameter class in Secmod.java. Is that also subject to the same issue?

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

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

From duke at openjdk.org  Thu Jun 23 21:38:52 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 23 Jun 2022 21:38:52 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator works with
 ChaCha20-Poly1305 [v2]
In-Reply-To: <vy9DPrnka2SA_8UmHDZA0K8jidwQorcBbse-NLCLXSM=.1d57fd5d-9193-4944-9674-a678342dde20@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>
 <vy9DPrnka2SA_8UmHDZA0K8jidwQorcBbse-NLCLXSM=.1d57fd5d-9193-4944-9674-a678342dde20@github.com>
Message-ID: <_Z4Rft06ww4LQu2JS_A1hFV5ndxTkuufOH1QiVd4NcM=.c3895e59-734f-48a7-9fcb-ec4e3c68d8f9@github.com>

On Thu, 23 Jun 2022 16:47:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> zzambers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestKeyMaterialChaCha20.java: Added bug number
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 104:
> 
>> 102:         if ("ChaCha20-Poly1305".equals(algorithm)) {
>> 103:             algorithm = "ChaCha20";
>> 104:         }
> 
> Have you considered adding "ChaCha20-Poly1305" into the "keyTypes" instead? Then you don't need to add the if-block here.

That would indeed be cleaner solution. I'll make this change. Thank you.

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

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

From duke at openjdk.org  Thu Jun 23 22:07:42 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 23 Jun 2022 22:07:42 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator works with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
Message-ID: <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>

> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
> 
> 
> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
> ...
> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> 	at SSLSocketClient.test(SSLSocketClient.java:72)
> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
> 	at Main.main(Main.java:30)
> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> 	... 7 more
> 
> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> 
> 
> Problem:
> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
> 
> Fix:
> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
> 
> Testing:
> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
> 
> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!LkNIaJd2wGtgKipDkYK_Onk7xAvvBwG6QHrn6cCcDIjbsFz9K0qNyPnT9xS1eQGvkfIyVC9pyWqscLDoslQ$ 
> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!LkNIaJd2wGtgKipDkYK_Onk7xAvvBwG6QHrn6cCcDIjbsFz9K0qNyPnT9xS1eQGvkfIyVC9pyWqsHhPLrX4$ 
> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!LkNIaJd2wGtgKipDkYK_Onk7xAvvBwG6QHrn6cCcDIjbsFz9K0qNyPnT9xS1eQGvkfIyVC9pyWqsAA4LPzY$ 
> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!LkNIaJd2wGtgKipDkYK_Onk7xAvvBwG6QHrn6cCcDIjbsFz9K0qNyPnT9xS1eQGvkfIyVC9pyWqsJyjRirM$ 
> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!LkNIaJd2wGtgKipDkYK_Onk7xAvvBwG6QHrn6cCcDIjbsFz9K0qNyPnT9xS1eQGvkfIyVC9pyWqsVmVScb4$ 
> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!LkNIaJd2wGtgKipDkYK_Onk7xAvvBwG6QHrn6cCcDIjbsFz9K0qNyPnT9xS1eQGvkfIyVC9pyWqsm35XYHQ$ 

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

 - Link in comment made pernament
 - ChaCha20-Poly1305 added as key type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9072/files
  - new: https://git.openjdk.org/jdk/pull/9072/files/514da32e..7277ebe0

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

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

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

From duke at openjdk.org  Thu Jun 23 22:18:55 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 23 Jun 2022 22:18:55 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
Message-ID: <Gz8DX-DCGMjA32DU3uEylaIVg3Ed6Ez7rjB9G8Pd2WY=.a46a525a-c9e1-4b7b-9737-c7babae63621@github.com>

On Thu, 23 Jun 2022 22:07:42 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!JCEzppYX1gbhqMSRxkN8MymqTLfDjQ25nfh7dHSRO0rpwB1_2SHHp-5po2cYvloPONU3iJdDfkvc0GPuzUc$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!JCEzppYX1gbhqMSRxkN8MymqTLfDjQ25nfh7dHSRO0rpwB1_2SHHp-5po2cYvloPONU3iJdDfkvc7wj77AI$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!JCEzppYX1gbhqMSRxkN8MymqTLfDjQ25nfh7dHSRO0rpwB1_2SHHp-5po2cYvloPONU3iJdDfkvcqLy2KtA$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!JCEzppYX1gbhqMSRxkN8MymqTLfDjQ25nfh7dHSRO0rpwB1_2SHHp-5po2cYvloPONU3iJdDfkvcpoOGPkg$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!JCEzppYX1gbhqMSRxkN8MymqTLfDjQ25nfh7dHSRO0rpwB1_2SHHp-5po2cYvloPONU3iJdDfkvcl9-er4U$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!JCEzppYX1gbhqMSRxkN8MymqTLfDjQ25nfh7dHSRO0rpwB1_2SHHp-5po2cYvloPONU3iJdDfkvcBv0lQIY$ 
>
> zzambers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Link in comment made pernament
>  - ChaCha20-Poly1305 added as key type

I have addressed both remarks.
jdk_security tests passed for me locally with this change.
Thanks

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

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

From valeriep at openjdk.org  Thu Jun 23 22:52:45 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 22:52:45 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
Message-ID: <v6x9NIrZO90VxpwSRHzp3f-R0_ce94tCWdeYcFH8pkg=.7e5e2af1-dafa-4f42-ab3e-c9a5a1423e1f@github.com>

On Thu, 23 Jun 2022 22:07:42 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!KoEkrASINT9fJTWjXfBfgLgysh4gh3Q-Dj0zznn5mfhmpk5gavRKcTwoTq3Vd9kNH5tg3HSsvBFkdQGub2E81C7O$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!KoEkrASINT9fJTWjXfBfgLgysh4gh3Q-Dj0zznn5mfhmpk5gavRKcTwoTq3Vd9kNH5tg3HSsvBFkdQGubxqN9_Sb$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!KoEkrASINT9fJTWjXfBfgLgysh4gh3Q-Dj0zznn5mfhmpk5gavRKcTwoTq3Vd9kNH5tg3HSsvBFkdQGubzvZOlhN$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!KoEkrASINT9fJTWjXfBfgLgysh4gh3Q-Dj0zznn5mfhmpk5gavRKcTwoTq3Vd9kNH5tg3HSsvBFkdQGubxIU19U8$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!KoEkrASINT9fJTWjXfBfgLgysh4gh3Q-Dj0zznn5mfhmpk5gavRKcTwoTq3Vd9kNH5tg3HSsvBFkdQGub8CLRByq$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!KoEkrASINT9fJTWjXfBfgLgysh4gh3Q-Dj0zznn5mfhmpk5gavRKcTwoTq3Vd9kNH5tg3HSsvBFkdQGub7ZtSJq8$ 
>
> zzambers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Link in comment made pernament
>  - ChaCha20-Poly1305 added as key type

test/jdk/sun/security/pkcs11/tls/TestKeyMaterialChaCha20.java line 27:

> 25:  * @test
> 26:  * @bug 8288985
> 27:  * @summary Test that KeyMaterial generator works with ChaCha20-Poly1305

nit: add "TLS"

test/jdk/sun/security/pkcs11/tls/TestKeyMaterialChaCha20.java line 28:

> 26:  * @bug 8288985
> 27:  * @summary Test that KeyMaterial generator works with ChaCha20-Poly1305
> 28:  * @author Zdenek Zambersky

nit: IIRC we no longer add @author tag.

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

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

From valeriep at openjdk.org  Thu Jun 23 23:03:56 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 23:03:56 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <Gz8DX-DCGMjA32DU3uEylaIVg3Ed6Ez7rjB9G8Pd2WY=.a46a525a-c9e1-4b7b-9737-c7babae63621@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
 <Gz8DX-DCGMjA32DU3uEylaIVg3Ed6Ez7rjB9G8Pd2WY=.a46a525a-c9e1-4b7b-9737-c7babae63621@github.com>
Message-ID: <_bfAtO56Z39Ihb790DlB3Yinl6dTe9WPYETA_aZ-FMQ=.b2b4cdd0-99ab-435e-a445-340a5772a809@github.com>

On Thu, 23 Jun 2022 22:14:55 GMT, zzambers <duke at openjdk.org> wrote:

> I have addressed both remarks. jdk_security tests passed for me locally with this change. Thanks

I will submit a test job on my end also, just to be safe.

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

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

From valeriep at openjdk.org  Thu Jun 23 23:03:58 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 23:03:58 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v2]
In-Reply-To: <_Z4Rft06ww4LQu2JS_A1hFV5ndxTkuufOH1QiVd4NcM=.c3895e59-734f-48a7-9fcb-ec4e3c68d8f9@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <X3hD6fRSFMWTSjAt3caPj0lkZab4fLMSP_bsx_0OdOk=.7e87861e-190d-4df7-8e03-54ec7a346f09@github.com>
 <vy9DPrnka2SA_8UmHDZA0K8jidwQorcBbse-NLCLXSM=.1d57fd5d-9193-4944-9674-a678342dde20@github.com>
 <_Z4Rft06ww4LQu2JS_A1hFV5ndxTkuufOH1QiVd4NcM=.c3895e59-734f-48a7-9fcb-ec4e3c68d8f9@github.com>
Message-ID: <4UndgNXIIDleNWa6ABMiobMbje2Cz8UO8zjIGMv9YGw=.ae481ffd-00e5-485c-a72c-d0df1475be0c@github.com>

On Thu, 23 Jun 2022 21:35:46 GMT, zzambers <duke at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 104:
>> 
>>> 102:         if ("ChaCha20-Poly1305".equals(algorithm)) {
>>> 103:             algorithm = "ChaCha20";
>>> 104:         }
>> 
>> Have you considered adding "ChaCha20-Poly1305" into the "keyTypes" instead? Then you don't need to add the if-block here.
>
> That would indeed be cleaner solution. I'll make this change. Thank you.

Please update the 2nd copyright year to 2022 also.

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

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

From valeriep at openjdk.org  Thu Jun 23 23:04:02 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 23 Jun 2022 23:04:02 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
Message-ID: <vd295M0d2z5NRiXYqVcfLGIMWjEZkN9cNdXP4enoxgc=.3f38aa74-c688-4570-bad5-96548e3d5b59@github.com>

On Thu, 23 Jun 2022 22:07:42 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXhcORrrb$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXroZ9zf5$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXr9N27hf$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXt6Noj0J$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXlpeoiLU$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXvb4GCuu$ 
>
> zzambers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Link in comment made pernament
>  - ChaCha20-Poly1305 added as key type

test/jdk/sun/security/pkcs11/tls/TestKeyMaterialChaCha20.java line 57:

> 55:             System.out.println("Skipping, ChaCha20 not supported");
> 56:             return;
> 57:         }

This test does not use CKM_CHACHA20_KEY_GEN, and the test passes when I run it against the version of NSS which does not support CKM_CHACHA20_KEY_GEN. Since the test requires the provider to support  "SunTlsRsaPremasterSecret", "SunTls12MasterSecret", and "SunTls12KeyMaterial" key generators, probably should base the check on them instead?

test/jdk/sun/security/pkcs11/tls/TestKeyMaterialChaCha20.java line 74:

> 72: 
> 73:         // https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/ccec5d1e8529c8211cc678d8acc8d37fe461cb51/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXqs5Fs1V$ 
> 74:         // https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/ccec5d1e8529c8211cc678d8acc8d37fe461cb51/src/java.base/share/classes/sun/security/ssl/CipherSuite.java*L93__;Iw!!ACWV5N9M2RV99hQ!NkKDKTC1HJP1zRwYPBG_S8tcH8-fjaZQqUESU0pGPJNMl-_nUg9yiQiJ7eZm35pRa22MQKfBPiChpF2RXuIwam32$ 

nit: do these two links really needed? If yes, add some more text for their purpose?

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

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

From duke at openjdk.org  Fri Jun 24 14:38:49 2022
From: duke at openjdk.org (Ryan Ernst)
Date: Fri, 24 Jun 2022 14:38:49 GMT
Subject: RFR: 8286389: Address possibly lossy conversions in jdk.crypto.ec
In-Reply-To: <16Gy1vM87LSDeG2Sp6vs0tW2w7gSl8ds-aujUAMnaA0=.e08112fe-709d-4502-8842-a9f3c27cfe82@github.com>
References: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
 <16Gy1vM87LSDeG2Sp6vs0tW2w7gSl8ds-aujUAMnaA0=.e08112fe-709d-4502-8842-a9f3c27cfe82@github.com>
Message-ID: <3-ulgYk4J3mOmcyaQu5s8Otxr87qFlfl2g6WG758vG8=.735a15ea-6a24-4ffa-8f6e-61375462542c@github.com>

On Tue, 21 Jun 2022 16:48:23 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Applied required casts in jdk.crypto.ec for the upcoming warning.
>> Verified by cherry-picking @asotona's patch.
>
> src/jdk.crypto.ec/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 79:
> 
>> 77:         int bitsMod8 = params.getBits() % 8;
>> 78:         if (bitsMod8 != 0) {
>> 79:             byte mask = (byte) ((1 << bitsMod8) - 1);
> 
> I may not insert a whitespace after the "(byte)" conversion.  Similar to following update.  Otherwise, looks good to me.

I followed the cast style in `EdDSAOperations.java`. Should I change this one and leave the other, change both, or leave these as is to be consistent? I don't particularly mind which way it is, I'll do whatever you suggest.

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

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

From duke at openjdk.org  Sat Jun 25 07:59:41 2022
From: duke at openjdk.org (Ryan Ernst)
Date: Sat, 25 Jun 2022 07:59:41 GMT
Subject: Integrated: 8286389: Address possibly lossy conversions in
 jdk.crypto.ec
In-Reply-To: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
References: <NzNUsoSjm4KE78Md8FvBgAWLgm520wGlC9j6DWoool8=.8a7970cf-eb7a-44ac-92d2-2c99deccc103@github.com>
Message-ID: <CMGYeTeWnGZSjhSwN41Rn-WefnbPhSe9urWK8Oiv6Ds=.aa1409e2-05c9-46cd-b864-c2ffa9c04a24@github.com>

On Fri, 17 Jun 2022 16:05:38 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in jdk.crypto.ec for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

This pull request has now been integrated.

Changeset: e93be3ac
Author:    Ryan Ernst <ryan at iernst.net>
Committer: Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e93be3acdf75814674a365a87603f3f1d28b9262
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8286389: Address possibly lossy conversions in jdk.crypto.ec

Reviewed-by: chegar, xuelei

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

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

From duke at openjdk.org  Sat Jun 25 08:03:32 2022
From: duke at openjdk.org (Ryan Ernst)
Date: Sat, 25 Jun 2022 08:03:32 GMT
Subject: Integrated: 8286395: Address possibly lossy conversions in
 java.security.jgss
In-Reply-To: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
References: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
Message-ID: <hgk36Xjqldy-OthTI2XiUNubDTP8FOsf16ZWR3I0TMs=.4b4f47c6-0d13-4cb0-87da-0f7bf79dad8e@github.com>

On Fri, 17 Jun 2022 16:09:41 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in java.security.jgss for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

This pull request has now been integrated.

Changeset: a5c25d88
Author:    Ryan Ernst <ryan at iernst.net>
Committer: Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5c25d8837664f9a7302cdb84afd3916da533144
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8286395: Address possibly lossy conversions in java.security.jgss

Reviewed-by: chegar

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

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

From duke at openjdk.org  Mon Jun 27 13:18:44 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 27 Jun 2022 13:18:44 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v4]
In-Reply-To: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
Message-ID: <1BZn5xy3xh1H21cQItf8gPfjy9fMHcA542JHSvXBYP0=.9ffbb619-6097-49ae-a486-122367d0f8cc@github.com>

> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
> 
> 
> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
> ...
> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> 	at SSLSocketClient.test(SSLSocketClient.java:72)
> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
> 	at Main.main(Main.java:30)
> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> 	... 7 more
> 
> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> 
> 
> Problem:
> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
> 
> Fix:
> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
> 
> Testing:
> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
> 
> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!P17HC9X54R-gxB2y7Z5y7BzL_KNo5enGtpmzsTWjOUqiy3uw8kXM35S59daPN_cjaCxT7b1Bioz8D3KPLVQ$ 
> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!P17HC9X54R-gxB2y7Z5y7BzL_KNo5enGtpmzsTWjOUqiy3uw8kXM35S59daPN_cjaCxT7b1Bioz8CQ6KSAY$ 
> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!P17HC9X54R-gxB2y7Z5y7BzL_KNo5enGtpmzsTWjOUqiy3uw8kXM35S59daPN_cjaCxT7b1Bioz8O9PzZhs$ 
> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!P17HC9X54R-gxB2y7Z5y7BzL_KNo5enGtpmzsTWjOUqiy3uw8kXM35S59daPN_cjaCxT7b1Bioz8bk0BNXw$ 
> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!P17HC9X54R-gxB2y7Z5y7BzL_KNo5enGtpmzsTWjOUqiy3uw8kXM35S59daPN_cjaCxT7b1Bioz8Q5DqdJ4$ 
> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!P17HC9X54R-gxB2y7Z5y7BzL_KNo5enGtpmzsTWjOUqiy3uw8kXM35S59daPN_cjaCxT7b1Bioz8i27b3JY$ 

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

  TestKeyMaterialChaCha20.java: fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9072/files
  - new: https://git.openjdk.org/jdk/pull/9072/files/7277ebe0..b9c070c3

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

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

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

From duke at openjdk.org  Mon Jun 27 13:21:09 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 27 Jun 2022 13:21:09 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
Message-ID: <y3X4YkJENkll15nhKPB-5n4GimjbdDPAG3YjHFQdXFk=.e1e700f1-5de8-496d-9ce8-41f76e1e6571@github.com>

On Thu, 23 Jun 2022 22:07:42 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!NZF4uV7_c21y5QCbgTMiAeKlB7ZvAVHAqQXYN8FnRjIVUJoeHNG_B3i6fquCB45bA7fuHhq9kQV3D_bq8_U$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!NZF4uV7_c21y5QCbgTMiAeKlB7ZvAVHAqQXYN8FnRjIVUJoeHNG_B3i6fquCB45bA7fuHhq9kQV32LmyfOw$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!NZF4uV7_c21y5QCbgTMiAeKlB7ZvAVHAqQXYN8FnRjIVUJoeHNG_B3i6fquCB45bA7fuHhq9kQV36KjftMc$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!NZF4uV7_c21y5QCbgTMiAeKlB7ZvAVHAqQXYN8FnRjIVUJoeHNG_B3i6fquCB45bA7fuHhq9kQV3LsIeRO0$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!NZF4uV7_c21y5QCbgTMiAeKlB7ZvAVHAqQXYN8FnRjIVUJoeHNG_B3i6fquCB45bA7fuHhq9kQV3N1Ze8RU$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!NZF4uV7_c21y5QCbgTMiAeKlB7ZvAVHAqQXYN8FnRjIVUJoeHNG_B3i6fquCB45bA7fuHhq9kQV3Qq_ONJA$ 
>
> zzambers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Link in comment made pernament
>  - ChaCha20-Poly1305 added as key type

I have made fixes to the test based on your comments. I retested test :) and works ( fails without fix in P11SecretKeyFactory.java passes with ).
Thanks

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

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

From anthony.scarpino at oracle.com  Mon Jun 27 18:51:57 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 27 Jun 2022 11:51:57 -0700
Subject: JSSE: SSLEngine reporting HandshakeStatus.FINISHED, disabling
 NewSessionTicket
In-Reply-To: <CA+_8xu37yJM2Yz2agq33toQLMvs5qYZz=xidaGMygdJ-O1SyEg@mail.gmail.com>
References: <CA+_8xu37yJM2Yz2agq33toQLMvs5qYZz=xidaGMygdJ-O1SyEg@mail.gmail.com>
Message-ID: <7855fd47-9eb4-4ea0-b5eb-33115e68374b@oracle.com>



On 5/24/22 8:20 AM, Ben Smyth wrote:
> TL;DR: Why does a client report HandshakeStatus.FINISHED twice? Can 
> production of NewSessionTicket be disabled?
> 
> 

SSLEngine with post handshake messages returns HandshakeStatus.FINISHED. 
  I believe because the FINISHED definition is "The SSLEngine has just 
finished handshaking."

> A client (respectively server) becomes ready to encrypt application data 
> upon completing their side of handshaking: "Once a side has sent its 
> Finished message and has received and validated the Finished message 
> from its peer, it may begin to send and receive Application Data over 
> the connection" (RFC8446); a client completes handshaking upon wrapping 
> a FINISHED message and a server completes upon unwrapping such a 
> message. (There's an exception for 0-RTT data, and another for a server 
> operating with reduced security.)

Before TLS 1.3 and PostHandshake messages, the usage for FINISHED was 
clearly only during the handshake process and more tied to the Finished 
message. This decision was made back when TLS 1.3 was first put into the 
codebase, so I don't remember discussions that occurred about this.  But 
I'm not aware of a rule that that HandshakeStatus.FINISHED was directly 
linked to the finished message.

KeyUpdate and NewSessionTicket call finishPostHandshake() which sets the 
handshake status.

Personally, I don't have a strong feeling which is the better status to 
pass, and since TLS 1.3 was integrated, I haven't heard of issues with it.

> 
> Javadoc advises HandshakeStatus.FINISHED is reported when "a call to 
> SSLEngine.wrap() / unwrap() ... finishes a handshake." As expected,
> 
> * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping 
> a client's (TLS) FINISHED message.
> 
> By comparison, rather than report (server) handshake completion upon 
> unwrapping a client's (TLS) FINISHED message, HandshakeStatus.NEED_WRAP 
> is reported, a NewSessionTicket is produced on wrapping and
> 
> * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping 
> a server's (TLS) NewSessionTicket message.
> 
> Upon receipt of which,
> 
> * OpenJDK SSLEngine.unwrap() reports HandshakeStatus.FINISHED on 
> unwrapping a server's (TLS) NewSessionTicket message.
> 
> What does finishing a handshake mean in SSLEngine parlance? (I don't 
> understand why a client should report finishing twice.) Can production 
> of NewSessionTicket be disabled?

I don't think there is a way to prevent the jsse client from sending a 
PSK extension that triggers the NewSessionTicket.

Tony

From valeriep at openjdk.org  Mon Jun 27 21:50:46 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 27 Jun 2022 21:50:46 GMT
Subject: RFR: 8286259: Password cleanup after KeyStore.PasswordProtection
 in P11KeyStore
In-Reply-To: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>
References: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>
Message-ID: <a9eExYhVMQPFuzXbBi1mAZORXDEUUffDqY83B20HxKA=.dd496cb9-f08c-4d76-be90-e30fab315b70@github.com>

On Thu, 23 Jun 2022 00:41:07 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the small update for JDK-8286259.

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.org  Mon Jun 27 21:56:41 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 27 Jun 2022 21:56:41 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v4]
In-Reply-To: <1BZn5xy3xh1H21cQItf8gPfjy9fMHcA542JHSvXBYP0=.9ffbb619-6097-49ae-a486-122367d0f8cc@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <1BZn5xy3xh1H21cQItf8gPfjy9fMHcA542JHSvXBYP0=.9ffbb619-6097-49ae-a486-122367d0f8cc@github.com>
Message-ID: <n_GwiOD_RkEpHTZpUODGTM_lZ8J7xjJQ6teAej3g3Jw=.ebdd6cdf-e0c4-43b1-ad9b-b5c93f2a59b4@github.com>

On Mon, 27 Jun 2022 13:18:44 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://urldefense.com/v3/__https://github.com/zzambers/ssl-tests__;!!ACWV5N9M2RV99hQ!PcjETNYa6hx2teaCvrj-NrI_hyvuoLeFnH5gJSlXreue549Phly3gBbIqaZLYH-QpR5mHyyGZnCX-DfOhaH0qno2$ 
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java*L168__;Iw!!ACWV5N9M2RV99hQ!PcjETNYa6hx2teaCvrj-NrI_hyvuoLeFnH5gJSlXreue549Phly3gBbIqaZLYH-QpR5mHyyGZnCX-DfOhRz5uK33$ 
>> [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java*L101__;Iw!!ACWV5N9M2RV99hQ!PcjETNYa6hx2teaCvrj-NrI_hyvuoLeFnH5gJSlXreue549Phly3gBbIqaZLYH-QpR5mHyyGZnCX-DfOhfo-2Kfw$ 
>> [4] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java*L270__;Iw!!ACWV5N9M2RV99hQ!PcjETNYa6hx2teaCvrj-NrI_hyvuoLeFnH5gJSlXreue549Phly3gBbIqaZLYH-QpR5mHyyGZnCX-DfOhVBK_xLX$ 
>> [5] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java*L496__;Iw!!ACWV5N9M2RV99hQ!PcjETNYa6hx2teaCvrj-NrI_hyvuoLeFnH5gJSlXreue549Phly3gBbIqaZLYH-QpR5mHyyGZnCX-DfOhVpvySTB$ 
>> [6] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java*L81__;Iw!!ACWV5N9M2RV99hQ!PcjETNYa6hx2teaCvrj-NrI_hyvuoLeFnH5gJSlXreue549Phly3gBbIqaZLYH-QpR5mHyyGZnCX-DfOhYbcvvXD$ 
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestKeyMaterialChaCha20.java: fixes

Looks good. Thanks!

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

Marked as reviewed by valeriep (Reviewer).

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

From hchao at openjdk.org  Mon Jun 27 23:18:40 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 27 Jun 2022 23:18:40 GMT
Subject: Integrated: 8286259: Password cleanup after
 KeyStore.PasswordProtection in P11KeyStore
In-Reply-To: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>
References: <fzU0c3xlBiPP53sF0UVAUX5QCrKO87XN0dyIUcGEsI4=.d56b851c-c3f4-4859-9398-8b1b9a2e4dc9@github.com>
Message-ID: <xC198v2ZEqbk5DoWnQ-LcxMp9vsk7FF36l5-RPNfFeM=.ccc0499f-b070-4754-95d1-4224d206277a@github.com>

On Thu, 23 Jun 2022 00:41:07 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the small update for JDK-8286259.

This pull request has now been integrated.

Changeset: ca78f7bd
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca78f7bd762e1d5cd843d1ff36fafb8c943aba97
Stats:     13 lines in 1 file changed: 12 ins; 0 del; 1 mod

8286259: Password cleanup after KeyStore.PasswordProtection in P11KeyStore

Reviewed-by: valeriep

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

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

From wetmore at openjdk.org  Tue Jun 28 01:16:43 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 28 Jun 2022 01:16:43 GMT
Subject: RFR: 8286395: Address possibly lossy conversions in
 java.security.jgss
In-Reply-To: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
References: <ITKnO32HhRvZKoJnX35dfG7hfgA2blfMk-oldvesOjw=.731f16f7-719c-46df-85b8-26ccfaa2d3f5@github.com>
Message-ID: <VAwdehOq3AY_QwB73m3WB0blVUO3mOj7TrmDsvlpDg4=.c0e265c6-ea42-4df2-a72e-8a456db1dbc2@github.com>

On Fri, 17 Jun 2022 16:09:41 GMT, Ryan Ernst <duke at openjdk.org> wrote:

> Applied required casts in java.security.jgss for the upcoming warning.
> Verified by cherry-picking @asotona's patch.

Security didn't get a chance to review (was out last week), but looks ok to me.

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

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

From aturbanov at openjdk.org  Tue Jun 28 07:05:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Jun 2022 07:05:02 GMT
Subject: RFR: 8289274: Cleanup unnecessary null comparison before instanceof
 check in security modules
Message-ID: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>

Update code checks both non-null and instance of a class in security classes.
The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.

See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)

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

Commit messages:
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in security modules

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

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

From jwaters at openjdk.org  Tue Jun 28 07:23:05 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Jun 2022 07:23:05 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes from
 pointers in jdk.crypto.cryptoki
Message-ID: <x3k19aEcTApm1U-SKpcROrzW0qN0xTLIlY-r31jrV8c=.875dc878-323f-433b-ba91-7bbcd83f317b@github.com>

Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) and assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

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

Commit messages:
 - Remove __declspec(dllimport) from pointers

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

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

From duke at openjdk.org  Tue Jun 28 08:44:04 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Tue, 28 Jun 2022 08:44:04 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field
Message-ID: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>

Could you please review the changes?
This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

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

Commit messages:
 - 8283082: sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info field

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

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

From duke at openjdk.org  Tue Jun 28 13:06:34 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 28 Jun 2022 13:06:34 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding
Message-ID: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>

SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.

Exception:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
	at java.base/java.util.Arrays.fill(Arrays.java:3308)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
...


Details:
This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.

Solution:
Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.

[1] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622

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

Commit messages:
 - Fixed out of bounds exception in P11Cipher class

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

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

From duke at openjdk.org  Tue Jun 28 13:20:53 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 28 Jun 2022 13:20:53 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
Message-ID: <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>

> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
> 
> Exception:
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
> ...
> 
> 
> Details:
> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
> 
> Solution:
> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
> 
> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622

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

  Bug number and copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9310/files
  - new: https://git.openjdk.org/jdk/pull/9310/files/93c6b925..a2ecbb1d

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

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

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

From duke at openjdk.org  Tue Jun 28 13:20:55 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 28 Jun 2022 13:20:55 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding
In-Reply-To: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
Message-ID: <oPTb_JToIBJdnnnTv5_UreQPwN9wnkK_GFJBj0LZTdY=.babad67c-4a7f-4acb-b562-eb53724aa60b@github.com>

On Tue, 28 Jun 2022 12:57:21 GMT, zzambers <duke at openjdk.org> wrote:

> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
> 
> Exception:
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
> ...
> 
> 
> Details:
> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
> 
> Solution:
> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
> 
> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622

jdk_security tests passed for me locally

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

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

From weijun at openjdk.org  Tue Jun 28 13:21:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Jun 2022 13:21:41 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field
In-Reply-To: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
Message-ID: <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>

On Tue, 28 Jun 2022 08:33:58 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

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

> 740: 
> 741:         if (id.equalsIgnoreCase(INFO)) {
> 742:             if (!(attr.getSuffix() != null)) {

You can simply update the `!=` to `==`.

Also, please add a regression test. Since this is about testing an internal method, you are free to add `@modules java.base/sun.security.x509` to access it.

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

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

From weijun at openjdk.org  Tue Jun 28 13:30:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Jun 2022 13:30:41 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field
In-Reply-To: <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>
Message-ID: <zJQdpQIQhIa8kFMAL8t47B2sy56go4kmoV4wTlWevtA=.10e1a5f5-1a3e-434b-9281-53e51f14aee5@github.com>

On Tue, 28 Jun 2022 13:17:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Could you please review the changes?
>> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 742:
> 
>> 740: 
>> 741:         if (id.equalsIgnoreCase(INFO)) {
>> 742:             if (!(attr.getSuffix() != null)) {
> 
> You can simply update the `!=` to `==`.
> 
> Also, please add a regression test. Since this is about testing an internal method, you are free to add `@modules java.base/sun.security.x509` to access it.

The test can be much simpler than the program included in the bug report. Something like this:

1. Create an empty `X509CertImpl`
2. Add "x509.info"
3. Add "x509.info.issuer"
4. Remove "x509.info.issuer"
5. Add "x509.info.issuer" again

Without the fix, step 4 removes the whole info and step 5 would fail.

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

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

From duke at openjdk.org  Tue Jun 28 14:28:09 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 14:28:09 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc for
 mentioned classes
Message-ID: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>

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

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

Commit messages:
 - mo polish
 - polish
 - Merge
 - second round
 - Merge
 - first round

Changes: https://git.openjdk.org/jdk/pull/9282/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284851
  Stats: 1366 lines in 81 files changed: 85 ins; 4 del; 1277 mod
  Patch: https://git.openjdk.org/jdk/pull/9282.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9282/head:pull/9282

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

From jwaters at openjdk.org  Tue Jun 28 14:28:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Jun 2022 14:28:10 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <MwvQPeJx8YPkL94qrFlphSykW8cPZju2nqC_hrG1iI4=.c6ef2ff4-403f-498e-898f-8ff1fe19c28c@github.com>

On Fri, 24 Jun 2022 16:48:46 GMT, Mark Powers <duke at openjdk.org> wrote:

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

@mcpowers Seems like Skara didn't correctly detect and link the JBS entry. Try renaming your title to just "8284851" and see if that works (It may take a while)

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

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

From duke at openjdk.org  Tue Jun 28 14:33:30 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 14:33:30 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <4nLHifUgTVdBVw19epU5b899dYjJZEatf6pTuxj0q68=.2ac1ec27-8829-4b9d-a42a-deb78b1beb0e@github.com>

On Fri, 24 Jun 2022 16:48:46 GMT, Mark Powers <duke at openjdk.org> wrote:

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

Missing '-': changed "JDK 8284851" to JDK-8284851.
________________________________
From: TheShermanTanker ***@***.***>
Sent: Tuesday, June 28, 2022 4:12 AM
To: openjdk/jdk ***@***.***>
Cc: Mark Powers ***@***.***>; Mention ***@***.***>
Subject: [External] : Re: [openjdk/jdk] JDK 8284851 Update javax.crypto files to use proper javadoc for mentioned classes (PR #9282)


@mcpowers<https://urldefense.com/v3/__https://github.com/mcpowers__;!!ACWV5N9M2RV99hQ!J4f6TfiCEgjKE5PychE69_uOAeR5Jj8_vsJ3yevJkPu-KnxHbEH6OXpgeQwmZeqhuLvlb_QC9jcFOHE7QQiI9W3dwg$> Seems like Skara didn't correctly detect and link the JBS entry. Try renaming your title to just "8284851" and see if that works (It may take a while)

?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9282*issuecomment-1168584208__;Iw!!ACWV5N9M2RV99hQ!J4f6TfiCEgjKE5PychE69_uOAeR5Jj8_vsJ3yevJkPu-KnxHbEH6OXpgeQwmZeqhuLvlb_QC9jcFOHE7QQiKpQMjYw$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AXVTFJQVNTVQ36CCP32XCS3VRLM2TANCNFSM5ZYM4SZA__;!!ACWV5N9M2RV99hQ!J4f6TfiCEgjKE5PychE69_uOAeR5Jj8_vsJ3yevJkPu-KnxHbEH6OXpgeQwmZeqhuLvlb_QC9jcFOHE7QQiutUTZgQ$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>

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

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

From duke at openjdk.org  Tue Jun 28 14:53:41 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Tue, 28 Jun 2022 14:53:41 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field
In-Reply-To: <zJQdpQIQhIa8kFMAL8t47B2sy56go4kmoV4wTlWevtA=.10e1a5f5-1a3e-434b-9281-53e51f14aee5@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>
 <zJQdpQIQhIa8kFMAL8t47B2sy56go4kmoV4wTlWevtA=.10e1a5f5-1a3e-434b-9281-53e51f14aee5@github.com>
Message-ID: <Fattdqa4dbczjn6liEQSOXC43PvJvj8eLjwUEr04pZI=.96aff513-ae9a-4d1b-94db-e8f70a24d9bf@github.com>

On Tue, 28 Jun 2022 13:26:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 742:
>> 
>>> 740: 
>>> 741:         if (id.equalsIgnoreCase(INFO)) {
>>> 742:             if (!(attr.getSuffix() != null)) {
>> 
>> You can simply update the `!=` to `==`.
>> 
>> Also, please add a regression test. Since this is about testing an internal method, you are free to add `@modules java.base/sun.security.x509` to access it.
>
> The test can be much simpler than the program included in the bug report. Something like this:
> 
> 1. Create an empty `X509CertImpl`
> 2. Add "x509.info"
> 3. Add "x509.info.issuer"
> 4. Remove "x509.info.issuer"
> 5. Add "x509.info.issuer" again
> 
> Without the fix, step 4 removes the whole info and step 5 would fail.

Thank you for taking a look at the PR.
Sure I will address these comments.

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

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

From duke at openjdk.org  Tue Jun 28 15:39:27 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 28 Jun 2022 15:39:27 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v5]
In-Reply-To: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
Message-ID: <OaVpY4KsqVHQdx3IrcavD5XVcOegpraVinLOy_Q9Fhw=.9fc0c703-d162-4323-bf69-05610726390b@github.com>

> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
> 
> 
> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
> ...
> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> 	at SSLSocketClient.test(SSLSocketClient.java:72)
> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
> 	at Main.main(Main.java:30)
> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> 	... 7 more
> 
> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> 
> 
> Problem:
> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
> 
> Fix:
> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
> 
> Testing:
> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
> 
> [1] https://github.com/zzambers/ssl-tests
> [2] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java#L168
> [3] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L101
> [4] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java#L270
> [5] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java#L496
> [6] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java#L81

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

  Updated copyright date in P11SecretKeyFactory.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9072/files
  - new: https://git.openjdk.org/jdk/pull/9072/files/b9c070c3..804b2f0f

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

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

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

From duke at openjdk.org  Tue Jun 28 15:39:28 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 28 Jun 2022 15:39:28 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v4]
In-Reply-To: <1BZn5xy3xh1H21cQItf8gPfjy9fMHcA542JHSvXBYP0=.9ffbb619-6097-49ae-a486-122367d0f8cc@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <1BZn5xy3xh1H21cQItf8gPfjy9fMHcA542JHSvXBYP0=.9ffbb619-6097-49ae-a486-122367d0f8cc@github.com>
Message-ID: <GbpYBCHI6tuOqJzg1PQfl8piuh_v6XbjkVs25Z6nbgg=.35ae33cb-3870-4a49-b58f-3a5f5a1f43ae@github.com>

On Mon, 27 Jun 2022 13:18:44 GMT, zzambers <duke at openjdk.org> wrote:

>> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
>> 
>> 
>> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
>> ...
>> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
>> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
>> 	at SSLSocketClient.test(SSLSocketClient.java:72)
>> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
>> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
>> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
>> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
>> 	at Main.main(Main.java:30)
>> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
>> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
>> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
>> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
>> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
>> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
>> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
>> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
>> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
>> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
>> 	... 7 more
>> 
>> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>> 
>> 
>> Problem:
>> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
>> 
>> Fix:
>> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
>> 
>> Testing:
>> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
>> 
>> [1] https://github.com/zzambers/ssl-tests
>> [2] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java#L168
>> [3] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L101
>> [4] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java#L270
>> [5] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java#L496
>> [6] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java#L81
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestKeyMaterialChaCha20.java: fixes

I have realized, I forgot to fix copyright date in P11SecretKeyFactory.java, so fixed that.

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

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

From duke at openjdk.org  Tue Jun 28 15:39:28 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 28 Jun 2022 15:39:28 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <_bfAtO56Z39Ihb790DlB3Yinl6dTe9WPYETA_aZ-FMQ=.b2b4cdd0-99ab-435e-a445-340a5772a809@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
 <Gz8DX-DCGMjA32DU3uEylaIVg3Ed6Ez7rjB9G8Pd2WY=.a46a525a-c9e1-4b7b-9737-c7babae63621@github.com>
 <_bfAtO56Z39Ihb790DlB3Yinl6dTe9WPYETA_aZ-FMQ=.b2b4cdd0-99ab-435e-a445-340a5772a809@github.com>
Message-ID: <BNvAV8iy_wj4fEvB0hQFxl5hwIUkGfX6juQKLcmXSJ0=.120f7821-4e88-4fbd-98f7-9c45d8b50b09@github.com>

On Thu, 23 Jun 2022 23:01:36 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I have addressed both remarks.
>> jdk_security tests passed for me locally with this change.
>> Thanks
>
>> I have addressed both remarks. jdk_security tests passed for me locally with this change. Thanks
> 
> I will submit a test job on my end also, just to be safe.

@valeriepeng Thank you for the review

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

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

From duke at openjdk.org  Tue Jun 28 19:32:07 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 19:32:07 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>

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

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

  Valerie fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/77384537..eadba29f

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

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

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

From valeriep at openjdk.org  Tue Jun 28 19:35:31 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 19:35:31 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <ORGva7LjOJ-VUYZh3UdxO5HauxAbT9Q9F5xnRxsrwUQ=.45e78672-0fb7-4589-9e74-0d43fd0838cf@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/java/security/AccessControlContext.java line 58:

> 56:  * of the current calling context, and places
> 57:  * it in an {@code AccessControlContext} object, which it returns.
> 58:  A sample call is the following:

Missing "*"?

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

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

From duke at openjdk.org  Tue Jun 28 19:57:28 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 19:57:28 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <ORGva7LjOJ-VUYZh3UdxO5HauxAbT9Q9F5xnRxsrwUQ=.45e78672-0fb7-4589-9e74-0d43fd0838cf@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <ORGva7LjOJ-VUYZh3UdxO5HauxAbT9Q9F5xnRxsrwUQ=.45e78672-0fb7-4589-9e74-0d43fd0838cf@github.com>
Message-ID: <ZbiVGBuQK_LSJjbZvJgtnExD2ri_j4CJWMZnBXfQPN8=.2231ba9a-08f8-4069-8707-4e6fb485e3a0@github.com>

On Tue, 28 Jun 2022 19:31:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/java/security/AccessControlContext.java line 58:
> 
>> 56:  * of the current calling context, and places
>> 57:  * it in an {@code AccessControlContext} object, which it returns.
>> 58:  A sample call is the following:
> 
> Missing "*"?

Yes. Good catch.

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

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

From valeriep at openjdk.org  Tue Jun 28 20:24:44 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 20:24:44 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/AEADBadTagException.java line 41:

> 39: 
> 40:     /**
> 41:      * Constructs an <code>AEADBadTagException</code> with no detail message.

Why not using the {@code } as in other files?

src/java.base/share/classes/javax/crypto/AEADBadTagException.java line 48:

> 46: 
> 47:     /**
> 48:      * Constructs an <code>AEADBadTagException</code> with the specified

Same as above, use {@code }?

src/java.base/share/classes/javax/crypto/BadPaddingException.java line 44:

> 42: 
> 43:     /**
> 44:      * Constructs a <code>BadPaddingException</code> with no detail

Use `{@code }`?

src/java.base/share/classes/javax/crypto/BadPaddingException.java line 53:

> 51: 
> 52:     /**
> 53:      * Constructs a <code>BadPaddingException</code> with the specified

Use `{@code }`?

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

> 182: 
> 183:     /**
> 184:      * Constant used to initialize {@code Cipher} to encryption mode.

If it's lower case, we normally just leave it? Not sure what is the criteria for changing this.

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

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

From valeriep at openjdk.org  Tue Jun 28 20:37:39 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 20:37:39 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
Message-ID: <gil9_lprQ4gywyPw494PDGscxhs2XBgHGVDh2aBfaec=.9938d4e3-fd7b-4aa1-b827-de6b5368c1e5@github.com>

On Tue, 28 Jun 2022 20:21:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 184:
> 
>> 182: 
>> 183:     /**
>> 184:      * Constant used to initialize {@code Cipher} to encryption mode.
> 
> If it's lower case, we normally just leave it? Not sure what is the criteria for changing this. Is it because these are public static constants, so you prefer more formatting? But then, some have "object" following the `{@code Cipher}`, and some aren't which looks a bit inconsistent.

Personally, I'd against making this change, i.e. changing all "cipher" occurrences to "{@code Cipher}". Can we just stick to fixing what's broken?

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

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

From valeriep at openjdk.org  Tue Jun 28 20:37:40 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 20:37:40 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <X4N0NG5kI2tfQyAHQdbwrf5mpX8J_SODVvLHU12UFGE=.d9fdd58f-559c-41ec-b6e9-1e9b67e276d6@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/CipherInputStream.java line 33:

> 31: 
> 32: /**
> 33:  * A <code>CipherInputStream</code> is composed of an <code>InputStream</code>

Use `{@code }`? Applies to the rest of changes of this file.

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

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

From duke at openjdk.org  Tue Jun 28 20:52:52 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 20:52:52 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
Message-ID: <7oP-3JHvH-GTFJOOO4q7KbmO_5uVyDKskXMjSH9fL4k=.25f41397-1f56-48bc-ba57-11bf5dea571f@github.com>

On Tue, 28 Jun 2022 20:16:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/javax/crypto/AEADBadTagException.java line 41:
> 
>> 39: 
>> 40:     /**
>> 41:      * Constructs an <code>AEADBadTagException</code> with no detail message.
> 
> Why not using the {@code } as in other files?

I started with java.crypto first, and the first few files I looked at had  `<code>` so I used `<code>`. I later realized there was a mix of styles. I tried to continue with whatever style a file was using.

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

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

From valeriep at openjdk.org  Tue Jun 28 20:52:55 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 20:52:55 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <5a1atTVCX8MFRp3WUuYSaOPW_o1GDFBCiYrk5g8Q3DY=.b57e2303-f338-4a0f-b6aa-1727e5214182@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 31:

> 29: 
> 30: /**
> 31:  * A <code>CipherOutputStream</code> is composed of an <code>OutputStream</code>

Use `{@code }` for all of the javadoc in this class?

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

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

From valeriep at openjdk.org  Tue Jun 28 21:01:31 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:01:31 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <bZyukCUcPswF0ne67z7smAxdV3_mUPTPbNy38txZ1Jo=.54542849-a37e-4293-99c1-5f2e5b42bda1@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 108:

> 106:      * <code>OutputStream</code> and a <code>Cipher</code>.
> 107:      * <br>Note: if the specified output stream or cipher is
> 108:      * <code>null</code>, a NullPointerException may be thrown later when

Add {@code } to NullPointerException also

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

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

From duke at openjdk.org  Tue Jun 28 21:15:01 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 21:15:01 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <gil9_lprQ4gywyPw494PDGscxhs2XBgHGVDh2aBfaec=.9938d4e3-fd7b-4aa1-b827-de6b5368c1e5@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
 <gil9_lprQ4gywyPw494PDGscxhs2XBgHGVDh2aBfaec=.9938d4e3-fd7b-4aa1-b827-de6b5368c1e5@github.com>
Message-ID: <fMPnztkyULIHXNYN7rHtcDjRZPPbnIs-8eTxYtEqfhI=.6f062442-b33b-49e7-b3f4-52326a61b52e@github.com>

On Tue, 28 Jun 2022 20:33:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/Cipher.java line 184:
>> 
>>> 182: 
>>> 183:     /**
>>> 184:      * Constant used to initialize {@code Cipher} to encryption mode.
>> 
>> If it's lower case, we normally just leave it? Not sure what is the criteria for changing this. Is it because these are public static constants, so you prefer more formatting? But then, some have "object" following the `{@code Cipher}`, and some aren't which looks a bit inconsistent.
>
> Personally, I'd against making this change, i.e. changing all "cipher" occurrences to "{@code Cipher}". Can we just stick to fixing what's broken?

In this case the sentence was about initializing a cipher object, so I changed it to `{@code Cipher}`. If a sentence says "cipher block size" then I tried to leave it alone because it's referring to an algorithm rather than a class or object. I could add "object" after `{@code Cipher} `if it's not present. That would make it more consistent.

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

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

From weijun at openjdk.org  Tue Jun 28 21:14:59 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Jun 2022 21:14:59 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

This is the `java.security` part.

src/java.base/share/classes/java/security/AccessController.java line 983:

> 981: 
> 982:     /**
> 983:      * Returns the "inherited" AccessControl context. This is the context

Not sure what "AccessControl context" is. Either "access control context" or "{@code AccessControlContext}".

src/java.base/share/classes/java/security/AccessController.java line 993:

> 991:     /**
> 992:      * This method takes a "snapshot" of the current calling context, which
> 993:      * includes the current Thread's inherited {@code AccessControlContext}

"Thread" to "thread".

src/java.base/share/classes/java/security/AccessController.java line 1021:

> 1019:      * the current {@code AccessControlContext} and security policy.
> 1020:      * This method quietly returns if the access request
> 1021:      * is permitted, or throws an AccessControlException otherwise. The

Want to code-if "AccessControlException" as well?

src/java.base/share/classes/java/security/AccessController.java line 1023:

> 1021:      * is permitted, or throws an AccessControlException otherwise. The
> 1022:      * {@code getPermission} method of the AccessControlException returns the
> 1023:      * {@code perm} {@code Permission} object instance.

Two "{@code" together. Maybe move "{@code perm}" to the end?

src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java line 144:

> 142:      * A new {@code AlgorithmParameterGenerator} object encapsulating the
> 143:      * {@code AlgorithmParameterGeneratorSpi} implementation from the first
> 144:      * Provider that supports the specified algorithm is returned.

"Provider" -> "provider".

src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java line 249:

> 247:      * <p> A new {@code AlgorithmParameterGenerator} object encapsulating the
> 248:      * {@code AlgorithmParameterGeneratorSpi} implementation from the Provider
> 249:      * object is returned.  Note that the specified Provider object

Code-ify two "Provider" here.

src/java.base/share/classes/java/security/AlgorithmParameters.java line 225:

> 223:      * <p> A new {@code AlgorithmParameters} object encapsulating the
> 224:      * {@code AlgorithmParametersSpi} implementation from the specified
> 225:      * Provider object is returned.  Note that the specified Provider object

`{@code Provider}`.

src/java.base/share/classes/java/security/AllPermission.java line 73:

> 71:      * Creates a new {@code AllPermission} object. This
> 72:      * constructor exists for use by the {@code Policy} object
> 73:      * to instantiate new Permission objects.

`{@code Permission}`.

src/java.base/share/classes/java/security/AllPermission.java line 139:

> 137: /**
> 138:  * An {@code AllPermissionCollection} stores a collection
> 139:  * of AllPermission permissions. {@code AllPermission} objects

`{@code AllPermission}`.

src/java.base/share/classes/java/security/AllPermission.java line 177:

> 175: 
> 176:     /**
> 177:      * Adds a permission to the {@code AllPermissions} object.

There is no such a thing named "AllPermissions". Update it into "AllPermissionCollection". There are several such names in this file.

src/java.base/share/classes/java/security/AllPermission.java line 178:

> 176:     /**
> 177:      * Adds a permission to the {@code AllPermissions} object.
> 178:      * The key for the hash is {@code permission.path}.

No idea what key means? Could possibly be describing an old implementation. File a separate bug please.

src/java.base/share/classes/java/security/AllPermission.java line 201:

> 199:     /**
> 200:      * Check and see if this set of permissions implies the permissions
> 201:      * expressed in "permission".

"this set of permissions" is not used anywhere. You can copy from the same method from the parent class.

src/java.base/share/classes/java/security/BasicPermission.java line 246:

> 244:     /**
> 245:      * Returns a new {@code PermissionCollection} object for storing
> 246:      * BasicPermissions.

Maybe the original wording is better. I found it strange to write `{@code BasicPermission}s`. There are several other occurrences in this file.

src/java.base/share/classes/java/security/BasicPermission.java line 250:

> 248:      * <p>{@code BasicPermission} objects must be stored in a manner
> 249:      * that allows them to be inserted in any order, but that also enables the
> 250:      * {@code PermissionCollection} {@code implies} method

Two code in a row. Maybe make it a link?

src/java.base/share/classes/java/security/BasicPermission.java line 360:

> 358:      *                                       {@code BasicPermission}, or if
> 359:      *                                       the permission is not of the
> 360:      *                                       same Class as the other

"Class" to "class" or "type".

src/java.base/share/classes/java/security/GeneralSecurityException.java line 52:

> 50:      * Constructs a {@code GeneralSecurityException} with the specified detail
> 51:      * message.
> 52:      * A detail message is a String that describes this particular

"String" to "string".

src/java.base/share/classes/java/security/IdentityScope.java line 38:

> 36:  *
> 37:  * <p>An {@code IdentityScope} can contain {@code Identity} objects of all
> 38:  * kinds, including Signers. All types of {@code Identity} objects can be

"Signers" -> "signers".

src/java.base/share/classes/java/security/IdentityScope.java line 190:

> 188:     /**
> 189:      * Retrieves the {@code Identity} whose name is the same as that of the
> 190:      * specified principal. (Note: Identity implements Principal.)

Code-ify both Identity and Principal.

src/java.base/share/classes/java/security/KeyStore.java line 1728:

> 1726:      * A new {@code KeyStore} object is returned that encapsulates the
> 1727:      * {@code KeyStoreSpi}
> 1728:      * implementation from the first Provider that supports the specified file.

"Provider" -> "provider".

src/java.base/share/classes/java/security/KeyStore.java line 1889:

> 1887:          * @throws KeyStoreException if an error occurred during the
> 1888:          *   operation
> 1889:          * @throws IllegalStateException if the getKeyStore method has

Code-ify getKeyStore.

src/java.base/share/classes/java/security/KeyStore.java line 1903:

> 1901:          *
> 1902:          * <p> This is useful if an existing {@code KeyStore} object needs to be
> 1903:          * used with Builder-based APIs.

"Builder" -> "builder".

src/java.base/share/classes/java/security/KeyStore.java line 1913:

> 1911:          * @throws IllegalArgumentException if the keyStore has not been
> 1912:          *   initialized
> 1913:          */

A bunch of names need to be in code above: Builder, KeyStore, ProtectionParameter, keyStore, protectionParameters. Same for the methods below.

src/java.base/share/classes/java/security/KeyStoreException.java line 44:

> 42:     /**
> 43:      * Constructs a {@code KeyStoreException} with no detail message.  (A
> 44:      * detail message is a String that describes this particular

"String" -> "string". Same below.

src/java.base/share/classes/java/security/MessageDigest.java line 266:

> 264:      * <p> A new {@code MessageDigest} object encapsulating the
> 265:      * {@code MessageDigestSpi} implementation from the specified Provider
> 266:      * object is returned.  Note that the specified Provider object

"Provider" -> "provider".

src/java.base/share/classes/java/security/MessageDigest.java line 562:

> 560:      * The following class allows providers to extend from
> 561:      * {@code MessageDigestSpi} rather than from {@code MessageDigest}.
> 562:      * It represents a MessageDigest with an

Maybe "message digest"?

src/java.base/share/classes/java/security/MessageDigest.java line 565:

> 563:      * encapsulated, provider-supplied SPI object (of type MessageDigestSpi).
> 564:      * If the provider implementation is an instance of
> 565:      * {@code MessageDigestSpi}, the getInstance() methods above return an

Wrap getInstance in code.

src/java.base/share/classes/java/security/MessageDigest.java line 569:

> 567:      *
> 568:      * Note: All SPI methods from the original MessageDigest class have been
> 569:      * moved up the hierarchy into a new class (MessageDigestSpi), which has

Both MessageDigest and MessageDigestSpi here.

src/java.base/share/classes/java/security/NoSuchProviderException.java line 43:

> 41:     /**
> 42:      * Constructs a {@code NoSuchProviderException} with no detail message. A
> 43:      * detail message is a String that describes this particular

"String" to "string".

src/java.base/share/classes/java/security/Permission.java line 52:

> 50:  * subset test.
> 51:  *
> 52:  * <P> {@code Permission} objects are similar to String objects in that they

`{@code String}`.

src/java.base/share/classes/java/security/PermissionCollection.java line 80:

> 78:  * it desires (one using a Hashtable, one using a Vector, etc.). For example,
> 79:  * the Permissions object uses a default {@code PermissionCollection}
> 80:  * implementation that stores the permission objects in a Hashtable.

Several names need to be wrapped in code in the two paragraphs above.

src/java.base/share/classes/java/security/PermissionCollection.java line 130:

> 128:     /**
> 129:      * Checks to see if the specified permission is implied by
> 130:      * the collection of Permission objects held in this

Permission.

src/java.base/share/classes/java/security/PermissionCollection.java line 175:

> 173:      * Marks this {@code PermissionCollection} object as "readonly". After
> 174:      * a {@code PermissionCollection} object
> 175:      * is marked as readonly, no new Permission objects can be added to it

Permission.

src/java.base/share/classes/java/security/PermissionCollection.java line 184:

> 182:     /**
> 183:      * Returns true if this {@code PermissionCollection} object is marked
> 184:      * as readonly. If it is readonly, no new Permission objects can be added

Permission.

src/java.base/share/classes/java/security/PermissionCollection.java line 211:

> 209:      * method of this
> 210:      * object's superclass, which is Object. The result is
> 211:      * this PermissionCollection's type name followed by this object's

Object, PermissionCollection.

src/java.base/share/classes/java/security/Permissions.java line 64:

> 62:  * PermissionCollection that uses a hashtable will be created and used. Each
> 63:  * hashtable entry stores a Permission object as both the key and the value.
> 64:  *

Multiple Permission and PermissionCollection.

src/java.base/share/classes/java/security/Permissions.java line 100:

> 98:     /**
> 99:      * Creates a new {@code Permissions} object containing no
> 100:      * PermissionCollections.

PermissionCollections.

src/java.base/share/classes/java/security/Permissions.java line 117:

> 115:      * if an appropriate collection does not yet exist.
> 116:      *
> 117:      * @param permission the Permission object to add.

Permission on L117, PermissionCollection on L108 and L114. FilePermission and FilePermissionCollection on Line 110.

src/java.base/share/classes/java/security/Permissions.java line 154:

> 152:      * specifies "read" access for  all files in all subdirectories of the
> 153:      * "/tmp" directory, and another FilePermission that specifies "write"
> 154:      * access for all files in the "/tmp/scratch/foo" directory.

FilePermissionCollection and FIlePermission (twice) above.

src/java.base/share/classes/java/security/Permissions.java line 188:

> 186:     /**
> 187:      * Returns an enumeration of all the Permission objects in all the
> 188:      * PermissionCollections in this {@code Permissions} object.

Permission and PermissionCollection.

src/java.base/share/classes/java/security/Permissions.java line 190:

> 188:      * PermissionCollections in this {@code Permissions} object.
> 189:      *
> 190:      * @return an enumeration of all the Permissions.

Permissions. This one need to be taken care of because it's about permission objects inside, not Permissions as in this class name.

src/java.base/share/classes/java/security/Permissions.java line 205:

> 203:      * For example, if <i>p</i> is a FilePermission,
> 204:      * the FilePermissionCollection
> 205:      * stored in this {@code Permissions} object will be returned.

PermissionCollection, FilePermission, FilePermissionCollection.

src/java.base/share/classes/java/security/Permissions.java line 208:

> 206:      *
> 207:      * If createEmpty is true,
> 208:      * this method creates a new PermissionCollection object for the specified

createEmpty and PermissionCollection.

src/java.base/share/classes/java/security/Permissions.java line 220:

> 218:      * createEmpty is true, then
> 219:      * this method instantiates and stores a default PermissionCollection
> 220:      * that uses a hashtable to store its permission objects.

PermissionCollection on L216 and 219.

src/java.base/share/classes/java/security/Policy.java line 50:

> 48:  * {@code getPolicy} installs an instance of the default Policy
> 49:  * implementation (a default subclass implementation of this abstract class).
> 50:  * The default Policy implementation can be changed by setting the value

Policy.

src/java.base/share/classes/java/security/Policy.java line 371:

> 369:      * A new {@code Policy} object encapsulating the
> 370:      * {@code PolicySpi} implementation from the first
> 371:      * Provider that supports the specified type is returned.

"Provider" to "provider", L368 and L371.

src/java.base/share/classes/java/security/Policy.java line 505:

> 503:      * <p> A new {@code Policy} object encapsulating the
> 504:      * {@code PolicySpi} implementation from the specified Provider
> 505:      * object is returned.  Note that the specified Provider object

Provider, twice.

src/java.base/share/classes/java/security/Policy.java line 517:

> 515:      * {@code null}.
> 516:      *
> 517:      * @param provider the Provider.

Provider.

src/java.base/share/classes/java/security/Policy.java line 581:

> 579:      * Otherwise this method returns {@code null}.
> 580:      *
> 581:      * @return the Provider of this Policy, or {@code null}.

Provider, L575/577/581. Maybe "provider". Or wrap in code.

src/java.base/share/classes/java/security/Policy.java line 596:

> 594:      * Otherwise this method returns {@code null}.
> 595:      *
> 596:      * @return the type of this Policy, or {@code null}.

Policy, L590/596.

src/java.base/share/classes/java/security/Policy.java line 611:

> 609:      * Otherwise this method returns {@code null}.
> 610:      *
> 611:      * @return Policy parameters, or {@code null}.

Policy, L605/611.

src/java.base/share/classes/java/security/ProtectionDomain.java line 53:

> 51:  * policies, a {@code ProtectionDomain} can also be constructed such that it
> 52:  * is dynamically mapped to a set of permissions by the current Policy whenever
> 53:  * a permission is checked.

Policy, L50/52.

src/java.base/share/classes/java/security/ProtectionDomain.java line 166:

> 164:      * Permissions object.
> 165:      * <p>
> 166:      * The permissions granted to this domain are static, i.e.

CodeSource, Permissions. Note it's PermissionCollection here. So maybe use "permissions".

src/java.base/share/classes/java/security/ProtectionDomain.java line 192:

> 190:     /**
> 191:      * Creates a new {@code ProtectionDomain} qualified by the given CodeSource,
> 192:      * Permissions, ClassLoader and array of Principals. If the

Same as above, plus ClassLoader and Principal.

src/java.base/share/classes/java/security/ProtectionDomain.java line 241:

> 239:     /**
> 240:      * Returns the CodeSource of this domain.
> 241:      * @return the CodeSource of this domain which may be {@code null}.

CodeSource.

src/java.base/share/classes/java/security/ProtectionDomain.java line 251:

> 249:     /**
> 250:      * Returns the ClassLoader of this domain.
> 251:      * @return the ClassLoader of this domain which may be {@code null}.

ClassLoader.

src/java.base/share/classes/java/security/ProtectionDomain.java line 298:

> 296:     /**
> 297:      * Check and see if this {@code ProtectionDomain} implies the permissions
> 298:      * expressed in the Permission object.

Permission.

src/java.base/share/classes/java/security/ProtectionDomain.java line 458:

> 456:      *          debug is {@code null},
> 457:      *          caller has Policy.getPolicy permission
> 458:      */

Maybe it's not necessary to fix these non-public API cases.

src/java.base/share/classes/java/security/ProviderException.java line 52:

> 50: 
> 51:     /**
> 52:      * Constructs a {@code ProviderException} with the specified detail

String, L43/53. I'm now wondering if we need to describe what detail message means at all.

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

> 1030:      * Returns a Set of Strings containing the names of all available
> 1031:      * algorithms or types for the specified Java cryptographic service
> 1032:      * (e.g., Signature, MessageDigest, Cipher, Mac, KeyStore). Returns

All these Java cryptographic service type names.

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

> 1031:      * algorithms or types for the specified Java cryptographic service
> 1032:      * (e.g., Signature, MessageDigest, Cipher, Mac, KeyStore). Returns
> 1033:      * an empty Set if there is no provider that supports the

"set" is OK.

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

> 1032:      * (e.g., Signature, MessageDigest, Cipher, Mac, KeyStore). Returns
> 1033:      * an empty Set if there is no provider that supports the
> 1034:      * specified service or if serviceName is {@code null}. For a complete list

`{@code serviceName}`.

src/java.base/share/classes/java/security/UnresolvedPermission.java line 67:

> 65:  * containing information about the permission.
> 66:  *
> 67:  * <p>Later, when code calls AccessController.checkPermission

AccessController.checkPermission. Maybe make it a link.

src/java.base/share/classes/java/security/UnresolvedPermission.java line 329:

> 327:      * @param obj the object we are testing for equality with this object.
> 328:      *
> 329:      * @return true if obj is an {@code UnresolvedPermission}, and has the same

`{@code obj}`.

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

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

From valeriep at openjdk.org  Tue Jun 28 21:15:05 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:15:05 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <_ReEdn8yJGFxU9HHacILa9kz1LVEtk9gPP9b5yDvZEI=.7cda05e0-bd2f-4d23-a402-0b309f5a7c2d@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 126:

> 124:      * using a <code>NullCipher</code>.
> 125:      * <br>Note: if the specified output stream is <code>null</code>, a
> 126:      * NullPointerException may be thrown later when it is used.

Add {@code } to NullPointerException also.

src/java.base/share/classes/javax/crypto/CipherSpi.java line 227:

> 225: 
> 226:     /**
> 227:      * Sets the mode of this {@code Cipher}.

Same comment as in the one in Cipher.java, prefer to leave cipher alone.

src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 64:

> 62:      *
> 63:      * @return true if the specified permission is an
> 64:      * instance of <code>CryptoPermission</code>.

Use {@code } for all of the javadoc in this class?

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 40:

> 38:  * The <code>CryptoPermission</code> class extends the
> 39:  * <code>java.security.Permission</code> class. A
> 40:  * <code>CryptoPermission</code> object is used to represent

Use {@code } for all of the javadoc in this class?

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

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

From valeriep at openjdk.org  Tue Jun 28 21:23:45 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:23:45 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <ZAoBUmDbPU_Hi0ZVNTJO-4uvzjvYv-t3rl8yNajjEz8=.ea35fc00-865d-4ae0-a673-de123b8086cf@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 481:

> 479:      * @param permission the <code>Permission</code> object to add.
> 480:      *
> 481:      * @exception SecurityException - if this

Should be ok to remove "-"?

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 46:

> 44: 
> 45: /**
> 46:  * This class contains <code>CryptoPermission</code> objects, organized into

Use {@code } for all of the javadoc in this class?

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

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

From valeriep at openjdk.org  Tue Jun 28 21:36:24 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:36:24 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <DmSgNp1f6G_TqpA7zgl8J5NYGMb-FKvQpIf7QzExy5k=.85a9f7e9-ec06-4208-b374-ff64f5ac84b7@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 47:

> 45:  * that JCE has new permission classes called
> 46:  * <code>javax.crypto.CryptoPermission</code> and
> 47:  * <code>javax.crypto.CryptoAllPermission</code>.

Use` {@code }` instead of `<code></code>` for all of the javadoc?

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

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

From valeriep at openjdk.org  Tue Jun 28 21:42:39 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:42:39 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
Message-ID: <OMjOrd7AqohQB7dlP9j-ED6dWdEW94p-rRhKrRJ_2R0=.d9949cb8-d71f-4967-a165-ba23c9416a41@github.com>

On Tue, 28 Jun 2022 13:20:53 GMT, zzambers <duke at openjdk.org> wrote:

>> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
>> 
>> Exception:
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
>> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
>> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
>> ...
>> 
>> 
>> Details:
>> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
>> 
>> Solution:
>> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
>> 
>> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug number and copyright date

I am still reviewing some other PR, will take a look of this tomorrow. Thanks~

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

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

From duke at openjdk.org  Tue Jun 28 21:52:40 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 28 Jun 2022 21:52:40 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <DmSgNp1f6G_TqpA7zgl8J5NYGMb-FKvQpIf7QzExy5k=.85a9f7e9-ec06-4208-b374-ff64f5ac84b7@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <DmSgNp1f6G_TqpA7zgl8J5NYGMb-FKvQpIf7QzExy5k=.85a9f7e9-ec06-4208-b374-ff64f5ac84b7@github.com>
Message-ID: <5n7tn0qeUdhBs_UyTHO0GNiXy6aalc7TCrXLjiGmR1o=.8c06360e-3726-4b1f-bec8-19750337e9e9@github.com>

On Tue, 28 Jun 2022 21:32:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 47:
> 
>> 45:  * that JCE has new permission classes called
>> 46:  * <code>javax.crypto.CryptoPermission</code> and
>> 47:  * <code>javax.crypto.CryptoAllPermission</code>.
> 
> Use` {@code }` instead of `<code></code>` for all of the javadoc?

Are you suggesting that whenever file is modified, **all** occurrences of `<code></code>` should be changed to `{@code }`?

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

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

From valeriep at openjdk.org  Tue Jun 28 21:52:42 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:52:42 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <tqtLHWFdLIFBXy8yh6jhXshrWolL5NTbzGwXoykzv8Q=.b5d9b36e-9864-4476-a790-fbd86239629d@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 78:

> 76:      * the array are copied to protect against subsequent modification.
> 77:      * @exception NullPointerException if the <code>encoded</code> is
> 78:      * <code>null</code>.

Use `{@code }` instead of `<code></code>` for all of the javadoc?

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

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

From valeriep at openjdk.org  Tue Jun 28 21:58:29 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 21:58:29 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <jw11lS4kQTovptHw6vuT2QVByihO_Dj0R-gxjRN3uqc=.d6357fb1-f875-43ec-9632-23043508646e@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/ExemptionMechanism.java line 74:

> 72: 
> 73:     /**
> 74:      * Creates an <code>ExemptionMechanism</code> object.

Use `{@code }` instead of `<code></code>` for all of the javadoc?

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

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

From valeriep at openjdk.org  Tue Jun 28 22:04:41 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Jun 2022 22:04:41 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <neCCi24HLdCfCGO9mPz69f0CrIBwZ2EEtj_8oLqK5yU=.c28e581f-dcd4-4ae3-9cde-f58276d7d1c9@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/KeyGenerator.java line 60:

> 58:  * method in this {@code KeyGenerator} class that takes these two universally
> 59:  * shared types of arguments. There is also one that takes just a
> 60:  * {@code keysize} argument, and uses the SecureRandom implementation

Add `{@code }` to the SecureRandom?

src/java.base/share/classes/javax/crypto/KeyGenerator.java line 207:

> 205:      * for the specified algorithm.
> 206:      *
> 207:      * <p> This method traverses the list of registered security Providers,

Providers -> providers

src/java.base/share/classes/javax/crypto/KeyGenerator.java line 208:

> 206:      *
> 207:      * <p> This method traverses the list of registered security Providers,
> 208:      * starting with the most preferred Provider.

Provider -> provider

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

> 209:      * A new {@code KeyGenerator} object encapsulating the
> 210:      * {@code KeyGeneratorSpi} implementation from the first
> 211:      * Provider that supports the specified algorithm is returned.

Provider -> provider

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

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

From hchao at openjdk.org  Tue Jun 28 23:02:11 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 28 Jun 2022 23:02:11 GMT
Subject: RFR: 8289401: Add dump output to TestRawRSACipher.java
Message-ID: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>

Test TestRawRSACipher.java may fail intermittently. Please review changes to dump out the input and output when it fails.

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

Commit messages:
 - 8289401: Add dump output to TestRawRSACipher.java

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

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

From hchao at openjdk.org  Tue Jun 28 23:26:15 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 28 Jun 2022 23:26:15 GMT
Subject: RFR: 8289401: Add dump output to TestRawRSACipher.java [v2]
In-Reply-To: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>
References: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>
Message-ID: <-P8u8BtrWGK4DSBmJEUcyz-6FotfA0vHBkk0yQTZNZQ=.67ffc918-a5b4-4bd1-be85-485f92e7458c@github.com>

> Test TestRawRSACipher.java may fail intermittently. Please review changes to dump out the input and output when it fails.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update to use HexFormat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9316/files
  - new: https://git.openjdk.org/jdk/pull/9316/files/a8bb807b..ca09f31a

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

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

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

From weijun at openjdk.org  Tue Jun 28 23:26:16 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Jun 2022 23:26:16 GMT
Subject: RFR: 8289401: Add dump output to TestRawRSACipher.java [v2]
In-Reply-To: <-P8u8BtrWGK4DSBmJEUcyz-6FotfA0vHBkk0yQTZNZQ=.67ffc918-a5b4-4bd1-be85-485f92e7458c@github.com>
References: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>
 <-P8u8BtrWGK4DSBmJEUcyz-6FotfA0vHBkk0yQTZNZQ=.67ffc918-a5b4-4bd1-be85-485f92e7458c@github.com>
Message-ID: <fQyHIgxS4pj2vuwjqEi3dWedkex6P5FDOckMppapoD8=.c503fddb-4b7a-496a-adae-1a6b5f69971d@github.com>

On Tue, 28 Jun 2022 23:22:20 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Test TestRawRSACipher.java may fail intermittently. Please review changes to dump out the input and output when it fails.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use HexFormat

Looks fine.

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

Marked as reviewed by weijun (Reviewer).

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

From hchao at openjdk.org  Tue Jun 28 23:33:33 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 28 Jun 2022 23:33:33 GMT
Subject: RFR: 8289401: Add dump output to TestRawRSACipher.java [v2]
In-Reply-To: <fQyHIgxS4pj2vuwjqEi3dWedkex6P5FDOckMppapoD8=.c503fddb-4b7a-496a-adae-1a6b5f69971d@github.com>
References: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>
 <-P8u8BtrWGK4DSBmJEUcyz-6FotfA0vHBkk0yQTZNZQ=.67ffc918-a5b4-4bd1-be85-485f92e7458c@github.com>
 <fQyHIgxS4pj2vuwjqEi3dWedkex6P5FDOckMppapoD8=.c503fddb-4b7a-496a-adae-1a6b5f69971d@github.com>
Message-ID: <XU1Ace8SsJLlACgCrqTvcVRE_eepdPUI_YMCRugEbLo=.65c51559-5851-4f87-a1a4-75475f047edf@github.com>

On Tue, 28 Jun 2022 23:18:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to use HexFormat
>
> Looks fine.

@wangweij Thanks for the review.

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

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

From hchao at openjdk.org  Tue Jun 28 23:33:33 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 28 Jun 2022 23:33:33 GMT
Subject: Integrated: 8289401: Add dump output to TestRawRSACipher.java
In-Reply-To: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>
References: <D9dtLhVZwFectcibYOC6hRXFgrxl8vIQv9FA9Jtlr7g=.117be8b9-3e3d-460d-be0a-24aff0053702@github.com>
Message-ID: <lmWCsA1x0csontrxmQ4UmlFhPGqZ_ARM3TrFK8mCarw=.5f1d8615-126f-4609-bf94-2551ba698d6f@github.com>

On Tue, 28 Jun 2022 22:55:26 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Test TestRawRSACipher.java may fail intermittently. Please review changes to dump out the input and output when it fails.

This pull request has now been integrated.

Changeset: 7b3bf977
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b3bf97760c8daf6c03aaa069660f5a3a3873f8c
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8289401: Add dump output to TestRawRSACipher.java

Reviewed-by: weijun

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

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

From valeriep at openjdk.org  Wed Jun 29 00:11:43 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 29 Jun 2022 00:11:43 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/KeyGenerator.java line 297:

> 295:      *
> 296:      * <p> A new {@code KeyGenerator} object encapsulating the
> 297:      * {@code KeyGeneratorSpi} implementation from the specified Provider

Change "Provider" to start with lowercase or add `{@code }`

src/java.base/share/classes/javax/crypto/KeyGenerator.java line 298:

> 296:      * <p> A new {@code KeyGenerator} object encapsulating the
> 297:      * {@code KeyGeneratorSpi} implementation from the specified Provider
> 298:      * object is returned.  Note that the specified Provider object

Same for this one as well.

src/java.base/share/classes/javax/crypto/Mac.java line 146:

> 144:      *
> 145:      * <p> This method traverses the list of registered security Providers,
> 146:      * starting with the most preferred Provider.

Change "Providers"/"Provider" to start with lowercase.

src/java.base/share/classes/javax/crypto/Mac.java line 149:

> 147:      * A new {@code Mac} object encapsulating the
> 148:      * {@code MacSpi} implementation from the first
> 149:      * Provider that supports the specified algorithm is returned.

Provider -> provider

src/java.base/share/classes/javax/crypto/Mac.java line 243:

> 241:      *
> 242:      * <p> A new {@code Mac} object encapsulating the
> 243:      * {@code MacSpi} implementation from the specified Provider

Provider -> provider

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

> 43: 
> 44:     /**
> 45:      * Constructs a <code>NoSuchPaddingException</code> with no detail

Use `{@code }` for all of the javadoc in this class?

src/java.base/share/classes/javax/crypto/NoSuchPaddingException.java line 46:

> 44:     /**
> 45:      * Constructs a <code>NoSuchPaddingException</code> with no detail
> 46:      * message. A detail message is a String that describes this

Add `{@code }` to String

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

> 27: 
> 28: /**
> 29:  * The <code>NullCipher</code> class is a class that provides an

Use `{@code }` for all of the javadoc in this class?

src/java.base/share/classes/javax/crypto/ProviderVerifier.java line 54:

> 52: 
> 53:     /**
> 54:      * Creates a <code>ProviderVerifier</code> object to verify the given URL.

Use `{@code }` for all of the javadoc in this class?

src/java.base/share/classes/javax/crypto/ProviderVerifier.java line 170:

> 168:      * NOTE: if this <code>ProviderVerifier</code> instance is constructed
> 169:      * with "savePerms" equal to false, then this method would always
> 170:      * return null.

Add `{@code }` to "false" and "null"

src/java.base/share/classes/javax/crypto/SealedObject.java line 43:

> 41:  * confidentiality with a cryptographic algorithm.
> 42:  *
> 43:  * <p> Given any Serializable object, one can create a <code>SealedObject</code>

Use `{@code }` for all of the javadoc in this class?

src/java.base/share/classes/javax/crypto/SealedObject.java line 195:

> 193:     /**
> 194:      * Constructs a <code>SealedObject</code> object from the passed-in
> 195:      * SealedObject.

Add `{@code }` to SealedObject?

src/java.base/share/classes/javax/crypto/SealedObject.java line 198:

> 196:      *
> 197:      * @param so a <code>SealedObject</code> object
> 198:      * @exception NullPointerException if the given sealed object is null.

Add `{@code }` to null?

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

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

From valeriep at openjdk.org  Wed Jun 29 00:11:44 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 29 Jun 2022 00:11:44 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>
Message-ID: <ZSBDKDc_SaxCioxNANj6lg03oNjShC51reb2ri0lEoA=.5a570e3f-ef97-4649-9ff8-514d830e9541@github.com>

On Tue, 28 Jun 2022 22:02:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 297:
> 
>> 295:      *
>> 296:      * <p> A new {@code KeyGenerator} object encapsulating the
>> 297:      * {@code KeyGeneratorSpi} implementation from the specified Provider
> 
> Change "Provider" to start with lowercase or add `{@code }`

Other methods seem to use "provider".

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

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

From valeriep at openjdk.org  Wed Jun 29 00:16:48 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 29 Jun 2022 00:16:48 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
Message-ID: <NbNLi7KOTL7ZHS5l2sd-5EaDdcLXNKNh6DCcHPXVkjo=.a757f447-342c-41cc-9e5e-5a2f4950e7fc@github.com>

On Tue, 28 Jun 2022 19:32:07 GMT, Mark Powers <duke at openjdk.org> wrote:

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

src/java.base/share/classes/javax/crypto/SecretKeyFactory.java line 131:

> 129:      * A new {@code SecretKeyFactory} object encapsulating the
> 130:      * {@code SecretKeyFactorySpi} implementation from the first
> 131:      * Provider that supports the specified algorithm is returned.

Provider -> provider

src/java.base/share/classes/javax/crypto/SecretKeyFactory.java line 219:

> 217:      *
> 218:      * <p> A new {@code SecretKeyFactory} object encapsulating the
> 219:      * {@code SecretKeyFactorySpi} implementation from the specified Provider

Provider->provider

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

> 43: 
> 44:     /**
> 45:      * Constructs a <code>ShortBufferException</code> with no detail

Use `{@code }` for all of the javadoc in this class?

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

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

From valeriep at openjdk.org  Wed Jun 29 00:38:37 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 29 Jun 2022 00:38:37 GMT
Subject: RFR: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305 [v3]
In-Reply-To: <_bfAtO56Z39Ihb790DlB3Yinl6dTe9WPYETA_aZ-FMQ=.b2b4cdd0-99ab-435e-a445-340a5772a809@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
 <Ffho_T2uLnrE0UbhP9_9cYmfFhenT7_YFpJ_-zAKmkE=.2f06a743-d903-4484-9594-1ad2568a98ef@github.com>
 <Gz8DX-DCGMjA32DU3uEylaIVg3Ed6Ez7rjB9G8Pd2WY=.a46a525a-c9e1-4b7b-9737-c7babae63621@github.com>
 <_bfAtO56Z39Ihb790DlB3Yinl6dTe9WPYETA_aZ-FMQ=.b2b4cdd0-99ab-435e-a445-340a5772a809@github.com>
Message-ID: <ZWfc-cBmLlHy_w-iTPIVs2g2Y7lGa61PmR1nHbBKrEQ=.9ea8d2a8-c410-4b89-9fe4-1cb2d4421503@github.com>

On Thu, 23 Jun 2022 23:01:36 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I have addressed both remarks.
>> jdk_security tests passed for me locally with this change.
>> Thanks
>
>> I have addressed both remarks. jdk_security tests passed for me locally with this change. Thanks
> 
> I will submit a test job on my end also, just to be safe.

> @valeriepeng Thank you for the review

Once you did the "/integrate" command, I can then sponsor this change.

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

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

From wetmore at openjdk.org  Wed Jun 29 01:03:48 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 29 Jun 2022 01:03:48 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>
Message-ID: <AtPtV5FZSK_poM_d4EQ2yodFjjTUfVwQ0ROWzHNSsvE=.c6be8ccf-6f52-4497-b936-c898eda4c7cf@github.com>

On Tue, 28 Jun 2022 22:13:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/javax/crypto/ProviderVerifier.java line 170:
> 
>> 168:      * NOTE: if this <code>ProviderVerifier</code> instance is constructed
>> 169:      * with "savePerms" equal to false, then this method would always
>> 170:      * return null.
> 
> Add `{@code }` to "false" and "null"

I had wasn't aware that this was as common as it is.

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

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

From duke at openjdk.org  Wed Jun 29 02:39:26 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 29 Jun 2022 02:39:26 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
Message-ID: <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>

> Could you please review the changes?
> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9306/files
  - new: https://git.openjdk.org/jdk/pull/9306/files/39c33a71..e93be28f

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

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

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

From duke at openjdk.org  Wed Jun 29 02:50:38 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 29 Jun 2022 02:50:38 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <Fattdqa4dbczjn6liEQSOXC43PvJvj8eLjwUEr04pZI=.96aff513-ae9a-4d1b-94db-e8f70a24d9bf@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>
 <zJQdpQIQhIa8kFMAL8t47B2sy56go4kmoV4wTlWevtA=.10e1a5f5-1a3e-434b-9281-53e51f14aee5@github.com>
 <Fattdqa4dbczjn6liEQSOXC43PvJvj8eLjwUEr04pZI=.96aff513-ae9a-4d1b-94db-e8f70a24d9bf@github.com>
Message-ID: <sXaK76co35_hIDAPXtViFtv0SQUTA6lw5ndiwJIiIfA=.3f7fb3d6-45e6-4982-bc9e-8da993d8b6f9@github.com>

On Tue, 28 Jun 2022 14:49:52 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> The test can be much simpler than the program included in the bug report. Something like this:
>> 
>> 1. Create an empty `X509CertImpl`
>> 2. Add "x509.info"
>> 3. Add "x509.info.issuer"
>> 4. Remove "x509.info.issuer"
>> 5. Add "x509.info.issuer" again
>> 
>> Without the fix, step 4 removes the whole info and step 5 would fail.
>
> Thank you for taking a look at the PR.
> Sure I will address these comments.

> The test can be much simpler than the program included in the bug report. Something like this:
> 
>     1. Create an empty `X509CertImpl`
> 
>     2. Add "x509.info"
> 
>     3. Add "x509.info.issuer"
> 
>     4. Remove "x509.info.issuer"
> 
>     5. Add "x509.info.issuer" again
> 
> 
> Without the fix, step 4 removes the whole info and step 5 would fail.
I am not a getting a clear idea about how to add issuer and delete etc. 
Could you please point me to some example?

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

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

From weijun at openjdk.org  Wed Jun 29 13:47:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 29 Jun 2022 13:47:41 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>
Message-ID: <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>

On Wed, 29 Jun 2022 02:39:26 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

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

> 740: 
> 741:         if (id.equalsIgnoreCase(INFO)) {
> 742:             if ((attr.getSuffix() == null)) {

You can remove the parentheses that were added last time.

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

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

From weijun at openjdk.org  Wed Jun 29 13:47:38 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 29 Jun 2022 13:47:38 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <sXaK76co35_hIDAPXtViFtv0SQUTA6lw5ndiwJIiIfA=.3f7fb3d6-45e6-4982-bc9e-8da993d8b6f9@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>
 <zJQdpQIQhIa8kFMAL8t47B2sy56go4kmoV4wTlWevtA=.10e1a5f5-1a3e-434b-9281-53e51f14aee5@github.com>
 <Fattdqa4dbczjn6liEQSOXC43PvJvj8eLjwUEr04pZI=.96aff513-ae9a-4d1b-94db-e8f70a24d9bf@github.com>
 <sXaK76co35_hIDAPXtViFtv0SQUTA6lw5ndiwJIiIfA=.3f7fb3d6-45e6-4982-bc9e-8da993d8b6f9@github.com>
Message-ID: <9LT0SGub6teI-ivZ42BL-0E8pCc2qPtyexKiVvDNZAg=.ab65a26d-1c08-4c0e-8a46-f03cb5f87347@github.com>

On Wed, 29 Jun 2022 02:46:48 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Thank you for taking a look at the PR.
>> Sure I will address these comments.
>
>> The test can be much simpler than the program included in the bug report. Something like this:
>> 
>>     1. Create an empty `X509CertImpl`
>> 
>>     2. Add "x509.info"
>> 
>>     3. Add "x509.info.issuer"
>> 
>>     4. Remove "x509.info.issuer"
>> 
>>     5. Add "x509.info.issuer" again
>> 
>> 
>> Without the fix, step 4 removes the whole info and step 5 would fail.
> I am not a getting a clear idea about how to add issuer and delete etc. 
> Could you please point me to some example?

import sun.security.x509.X500Name;
import sun.security.x509.X509CertImpl;
import sun.security.x509.X509CertInfo;

public class A {
    public static void main(String[] args) throws Exception {
        var c = new X509CertImpl();
        c.set("x509.info", new X509CertInfo());
        c.set("x509.info.issuer", new X500Name("CN=one"));
        c.delete("x509.info.issuer");
        c.set("x509.info.issuer", new X500Name("CN=two"));
    }
}

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

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

From duke at openjdk.org  Wed Jun 29 14:15:51 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 29 Jun 2022 14:15:51 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <9LT0SGub6teI-ivZ42BL-0E8pCc2qPtyexKiVvDNZAg=.ab65a26d-1c08-4c0e-8a46-f03cb5f87347@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <9tZ3sSpe7kni58GNpUW8EcjIH17L4aPrg-MzEfJKqsY=.5bce9923-ac1d-4932-badb-befe11facc7e@github.com>
 <zJQdpQIQhIa8kFMAL8t47B2sy56go4kmoV4wTlWevtA=.10e1a5f5-1a3e-434b-9281-53e51f14aee5@github.com>
 <Fattdqa4dbczjn6liEQSOXC43PvJvj8eLjwUEr04pZI=.96aff513-ae9a-4d1b-94db-e8f70a24d9bf@github.com>
 <sXaK76co35_hIDAPXtViFtv0SQUTA6lw5ndiwJIiIfA=.3f7fb3d6-45e6-4982-bc9e-8da993d8b6f9@github.com>
 <9LT0SGub6teI-ivZ42BL-0E8pCc2qPtyexKiVvDNZAg=.ab65a26d-1c08-4c0e-8a46-f03cb5f87347@github.com>
Message-ID: <l-tvG2t_9zvSApPK-bODOxSeJE5lxOTK635CYncE6_4=.113b0263-93ef-4742-8587-8a49bb8d7cdb@github.com>

On Wed, 29 Jun 2022 13:41:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> The test can be much simpler than the program included in the bug report. Something like this:
>>> 
>>>     1. Create an empty `X509CertImpl`
>>> 
>>>     2. Add "x509.info"
>>> 
>>>     3. Add "x509.info.issuer"
>>> 
>>>     4. Remove "x509.info.issuer"
>>> 
>>>     5. Add "x509.info.issuer" again
>>> 
>>> 
>>> Without the fix, step 4 removes the whole info and step 5 would fail.
>> I am not a getting a clear idea about how to add issuer and delete etc. 
>> Could you please point me to some example?
>
> import sun.security.x509.X500Name;
> import sun.security.x509.X509CertImpl;
> import sun.security.x509.X509CertInfo;
> 
> public class A {
>     public static void main(String[] args) throws Exception {
>         var c = new X509CertImpl();
>         c.set("x509.info", new X509CertInfo());
>         c.set("x509.info.issuer", new X500Name("CN=one"));
>         c.delete("x509.info.issuer");
>         c.set("x509.info.issuer", new X500Name("CN=two"));
>     }
> }

Thank you for providing this!

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

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

From duke at openjdk.org  Wed Jun 29 14:15:54 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 29 Jun 2022 14:15:54 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>
 <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>
Message-ID: <EF1N7nbfxDN-wZg_OCVNB-Fj9X-27aDfAzAjQOj513o=.342ed01e-70d4-4c0a-8d79-fae7751e9372@github.com>

On Wed, 29 Jun 2022 13:44:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 742:
> 
>> 740: 
>> 741:         if (id.equalsIgnoreCase(INFO)) {
>> 742:             if ((attr.getSuffix() == null)) {
> 
> You can remove the parentheses that were added last time.

Sure I will do that :)

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

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

From duke at openjdk.org  Wed Jun 29 16:08:01 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 29 Jun 2022 16:08:01 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v3]
In-Reply-To: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
Message-ID: <Zxft7h2QnF1SMXLmvwAGCxARqYCFg28mGghxQqZs9jY=.72635478-69dd-433d-b8d6-a8d8ede67dc3@github.com>

> Could you please review the changes?
> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

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

  Address review comments. Add regression test for the change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9306/files
  - new: https://git.openjdk.org/jdk/pull/9306/files/e93be28f..5d89e9b0

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

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

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

From duke at openjdk.org  Wed Jun 29 16:15:33 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Wed, 29 Jun 2022 16:15:33 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>
 <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>
Message-ID: <lkRfon7i8kkzHkqDB-427qxmhgv95Opu9P1FJ4DSz3A=.a8b4c470-f871-43a5-8d42-2b42dce8e443@github.com>

On Wed, 29 Jun 2022 13:44:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 742:
> 
>> 740: 
>> 741:         if (id.equalsIgnoreCase(INFO)) {
>> 742:             if ((attr.getSuffix() == null)) {
> 
> You can remove the parentheses that were added last time.

@wangweij I have added the test case under: test/jdk/sun/security/x509/X509CertImpl/JDK8283082.java 
As this is the first I am adding regression test so I am not sure whether the naming convention for the test case is right or not.

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

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

From duke at openjdk.org  Wed Jun 29 17:22:45 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 29 Jun 2022 17:22:45 GMT
Subject: Integrated: 8288985: P11TlsKeyMaterialGenerator should work with
 ChaCha20-Poly1305
In-Reply-To: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
References: <_2Osbx8xF6eGSQgGlEwGf4OA6Y_0vMBoiNhZDn3-Dhs=.bf6451b6-9415-405b-8abd-07b9f73f3182@github.com>
Message-ID: <ViSxx8zZ0xw3ZQxp1Ll9dhRWBfEr2lCOmeHrLwKGw9A=.497cbd2e-7ee2-4237-ba29-e6b91bd06718@github.com>

On Tue, 7 Jun 2022 22:07:17 GMT, zzambers <duke at openjdk.org> wrote:

> TLS `*_CHACHA20_POLY1305_*` cipher suites are currently broken when configuration with SunPKCS11 provider is used. I discovered this by my ssl-tests testsuite [1].
> 
> 
> make TEST_PKCS11_FIPS=1 SSLTESTS_SSL_CONFIG_FILTER=SunJSSE,Default,TLSv1.2,TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 SSLTESTS_CUSTOM_JAVA_PARAMS=-Djdk.tls.ephemeralDHKeySize=2048 ssl-tests
> ...
> javax.net.ssl.SSLException: Unknown algorithm: ChaCha20-Poly1305
> 	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:132)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> 	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
> 	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1712)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:470)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> 	at SSLSocketClient.test(SSLSocketClient.java:72)
> 	at SSLSocketTester.testConfiguration(SSLSocketTester.java:392)
> 	at SSLSocketTester.testConfigurations(SSLSocketTester.java:322)
> 	at SSLSocketTester.testProvider(SSLSocketTester.java:234)
> 	at SSLSocketTester.testProviders(SSLSocketTester.java:190)
> 	at Main.main(Main.java:30)
> Caused by: java.security.ProviderException: Unknown algorithm: ChaCha20-Poly1305
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsKeyMaterialGenerator.engineGenerateKey(P11TlsKeyMaterialGenerator.java:168)
> 	at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:564)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$LegacyTrafficKeyDerivation.<init>(SSLTrafficKeyDerivation.java:282)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation$T12TrafficKeyDerivationGenerator.createKeyDerivation(SSLTrafficKeyDerivation.java:117)
> 	at java.base/sun.security.ssl.SSLTrafficKeyDerivation.createKeyDerivation(SSLTrafficKeyDerivation.java:79)
> 	at java.base/sun.security.ssl.DHClientKeyExchange$DHClientKeyExchangeProducer.produce(DHClientKeyExchange.java:221)
> 	at java.base/sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65)
> 	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> 	at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
> 	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> 	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
> 	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
> 	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
> 	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
> 	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
> 	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> 	... 7 more
> 
> FAILED: SunJSSE/Default: TLSv1.2 + TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> 
> 
> Problem:
> Exception is thrown by P11TlsKeyMaterialGenerator.engineGenerateKey method [2], based on result of P11SecretKeyFactory.getKeyType method [3], which only "knows" "ChaCha20" key algorithm, but does not accept "ChaCha20-Poly1305" as algorithm. Algorithm value is passed from SSLTrafficKeyDerivation.LegacyTrafficKeyDerivation class [4], which leads to algorithm field in SSLCipher class [5]. Value of that field comes from cipher name in JsseJce class [6] (ending at first slash, if any).
> 
> Fix:
> This fix basically modifies P11SecretKeyFactory.getKeyType method to accept "ChaCha20-Poly1305" as alias for "ChaCha20". 
> 
> Testing:
> I ran jdk_security tests locally and they passed. Also failure in ssl-tests gets fixed.
> 
> [1] https://github.com/zzambers/ssl-tests
> [2] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java#L168
> [3] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L101
> [4] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java#L270
> [5] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/SSLCipher.java#L496
> [6] https://github.com/openjdk/jdk/blob/b7a34f728d0653d55ef01da045c9aad4c0471143/src/java.base/share/classes/sun/security/ssl/JsseJce.java#L81

This pull request has now been integrated.

Changeset: b6bd190d
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6bd190d8d10fdb177f9fb100c9f44c9f57a3cb5
Stats:     96 lines in 2 files changed: 95 ins; 0 del; 1 mod

8288985: P11TlsKeyMaterialGenerator should work with ChaCha20-Poly1305

Reviewed-by: valeriep

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

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

From valeriep at openjdk.org  Wed Jun 29 21:34:47 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 29 Jun 2022 21:34:47 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <fMPnztkyULIHXNYN7rHtcDjRZPPbnIs-8eTxYtEqfhI=.6f062442-b33b-49e7-b3f4-52326a61b52e@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
 <gil9_lprQ4gywyPw494PDGscxhs2XBgHGVDh2aBfaec=.9938d4e3-fd7b-4aa1-b827-de6b5368c1e5@github.com>
 <fMPnztkyULIHXNYN7rHtcDjRZPPbnIs-8eTxYtEqfhI=.6f062442-b33b-49e7-b3f4-52326a61b52e@github.com>
Message-ID: <qbx4xlSnipE4OMhCeQvLGT-imma9UG_g629pQXhxQpw=.04a98b81-3859-4757-b708-4b12edb031fe@github.com>

On Tue, 28 Jun 2022 21:09:56 GMT, Mark Powers <duke at openjdk.org> wrote:

>> Personally, I'd against making this change, i.e. changing all "cipher" occurrences to "{@code Cipher}". Can we just stick to fixing what's broken?
>
> In this case the sentence was about initializing a cipher object, so I changed it to `{@code Cipher}`. If a sentence says "cipher block size" then I tried to leave it alone because it's referring to an algorithm rather than a class or object. I could add "object" after `{@code Cipher} `if it's not present. That would make it more consistent.

Ok, add object afterwards would make it more consistent.

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

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

From valeriep at openjdk.org  Wed Jun 29 21:34:49 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 29 Jun 2022 21:34:49 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <5n7tn0qeUdhBs_UyTHO0GNiXy6aalc7TCrXLjiGmR1o=.8c06360e-3726-4b1f-bec8-19750337e9e9@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <DmSgNp1f6G_TqpA7zgl8J5NYGMb-FKvQpIf7QzExy5k=.85a9f7e9-ec06-4208-b374-ff64f5ac84b7@github.com>
 <5n7tn0qeUdhBs_UyTHO0GNiXy6aalc7TCrXLjiGmR1o=.8c06360e-3726-4b1f-bec8-19750337e9e9@github.com>
Message-ID: <3V0GsqDYq67YLBbXhdGDwKxn9Q5lT9IolmH0aT-CaiY=.4a99ad23-0ee3-49ae-94f6-5dca27cc5e98@github.com>

On Tue, 28 Jun 2022 21:50:17 GMT, Mark Powers <duke at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 47:
>> 
>>> 45:  * that JCE has new permission classes called
>>> 46:  * <code>javax.crypto.CryptoPermission</code> and
>>> 47:  * <code>javax.crypto.CryptoAllPermission</code>.
>> 
>> Use` {@code }` instead of `<code></code>` for all of the javadoc?
>
> Are you suggesting that whenever file is modified, **all** occurrences of `<code></code>` should be changed to `{@code }`?

At least for new changes, I prefer to use new notations.. If its easier to replace all, that's fine with me too.

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

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

From xuelei at openjdk.org  Thu Jun 30 15:26:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 15:26:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
Message-ID: <1_N-rntAbDIB3XXzrMZho1VD8VnVh8gOP9pRscyNt8w=.b3616afc-b9d6-40c1-a627-5f49cd44b764@github.com>

On Sat, 18 Jun 2022 05:55:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Master
>  - use Reference.refersTo
>  - remove trailing whitespaces
>  - use timeout factor
>  - Merge
>  - Merge master
>  - Merge
>  - add timeout parameter
>  - rollback is not in this branch
>  - rollback JDK-8287384
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282

ping ...

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

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

From rriggs at openjdk.org  Thu Jun 30 15:57:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 15:57:45 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
Message-ID: <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>

On Sat, 18 Jun 2022 05:55:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Master
>  - use Reference.refersTo
>  - remove trailing whitespaces
>  - use timeout factor
>  - Merge
>  - Merge master
>  - Merge
>  - add timeout parameter
>  - rollback is not in this branch
>  - rollback JDK-8287384
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282

Sorry for the delay.

test/lib/jdk/test/lib/util/ForceGC.java line 37:

> 35:     // The jtreg testing timeout factor.
> 36:     private static final double TIMEOUT_FACTOR = Double.valueOf(
> 37:             System.getProperty("test.timeout.factor", "1.0"));

If you don't mind the dependency, you can use jdk.test.lib.Utils.TIMEOUT_FACTOR
or `Utils.adjustTimeout(xx)` in the usage below.

test/lib/jdk/test/lib/util/ForceGC.java line 42:

> 40:      * Causes the current thread to wait until the {@code booleanSupplier}
> 41:      * returns true, or a specific waiting time elapses.  The waiting time
> 42:      * is 1 second scalled with the jtreg testing timeout factor.

typo: "scalled" -> "scaled"

test/lib/jdk/test/lib/util/ForceGC.java line 58:

> 56:         Reference.reachabilityFence(ref);
> 57: 
> 58:         for (int retries = (int)(timeout / 200); retries >= 0; retries--) {

The logic around the timeout might be clearer if it was only based on the number of retries,
and can be scaled by the TIMEOUT_FACTOR too.

test/lib/jdk/test/lib/util/ForceGC.java line 70:

> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
> 69:                 // to trigger and complete the cleanup.
> 70:                 queue.remove(200L);

If `remove()` returns a non-null value, then it is safe to break out of the loop.
The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.

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

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

From duke at openjdk.org  Thu Jun 30 16:21:50 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:21:50 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <7oP-3JHvH-GTFJOOO4q7KbmO_5uVyDKskXMjSH9fL4k=.25f41397-1f56-48bc-ba57-11bf5dea571f@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
 <7oP-3JHvH-GTFJOOO4q7KbmO_5uVyDKskXMjSH9fL4k=.25f41397-1f56-48bc-ba57-11bf5dea571f@github.com>
Message-ID: <DfmjO1tI0FcxnZ4L_jIUO1MeUqcVjYhw495EMJ7g-_k=.e650bae0-0ec9-4ef0-b184-2ede06cbe27e@github.com>

On Tue, 28 Jun 2022 20:47:56 GMT, Mark Powers <duke at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/AEADBadTagException.java line 41:
>> 
>>> 39: 
>>> 40:     /**
>>> 41:      * Constructs an <code>AEADBadTagException</code> with no detail message.
>> 
>> Why not using the {@code } as in other files?
>
> I started with java.crypto first, and the first few files I looked at had  `<code>` so I used `<code>`. I later realized there was a mix of styles. I tried to continue with whatever style a file was using.

using `{@code }`

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

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

From duke at openjdk.org  Thu Jun 30 16:22:22 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:22:22 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
Message-ID: <bz8vrsVAzSmlFQJFpM8cH9LxpkYa41QAyOmbaNv1jcM=.6414412a-df47-4d70-878d-34e98643e0f5@github.com>

On Tue, 28 Jun 2022 20:17:23 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/javax/crypto/AEADBadTagException.java line 48:
> 
>> 46: 
>> 47:     /**
>> 48:      * Constructs an <code>AEADBadTagException</code> with the specified
> 
> Same as above, use {@code }?

using `{@code }`

> src/java.base/share/classes/javax/crypto/BadPaddingException.java line 44:
> 
>> 42: 
>> 43:     /**
>> 44:      * Constructs a <code>BadPaddingException</code> with no detail
> 
> Use `{@code }`?

using `{@code }`

> src/java.base/share/classes/javax/crypto/BadPaddingException.java line 53:
> 
>> 51: 
>> 52:     /**
>> 53:      * Constructs a <code>BadPaddingException</code> with the specified
> 
> Use `{@code }`?

using `{@code }`

> src/java.base/share/classes/javax/crypto/CipherInputStream.java line 33:
> 
>> 31: 
>> 32: /**
>> 33:  * A <code>CipherInputStream</code> is composed of an <code>InputStream</code>
> 
> Use `{@code }`? Applies to the rest of changes of this file.

using `{@code }`

> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * A <code>CipherOutputStream</code> is composed of an <code>OutputStream</code>
> 
> Use `{@code }` for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 108:
> 
>> 106:      * <code>OutputStream</code> and a <code>Cipher</code>.
>> 107:      * <br>Note: if the specified output stream or cipher is
>> 108:      * <code>null</code>, a NullPointerException may be thrown later when
> 
> Add {@code } to NullPointerException also

using `{@code }`

> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 126:
> 
>> 124:      * using a <code>NullCipher</code>.
>> 125:      * <br>Note: if the specified output stream is <code>null</code>, a
>> 126:      * NullPointerException may be thrown later when it is used.
> 
> Add {@code } to NullPointerException also.

using `{@code }`

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 227:
> 
>> 225: 
>> 226:     /**
>> 227:      * Sets the mode of this {@code Cipher}.
> 
> Same comment as in the one in Cipher.java, prefer to leave cipher alone.

I believe we're doing `{@code Cipher}` object.

> src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 64:
> 
>> 62:      *
>> 63:      * @return true if the specified permission is an
>> 64:      * instance of <code>CryptoPermission</code>.
> 
> Use {@code } for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 40:
> 
>> 38:  * The <code>CryptoPermission</code> class extends the
>> 39:  * <code>java.security.Permission</code> class. A
>> 40:  * <code>CryptoPermission</code> object is used to represent
> 
> Use {@code } for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 481:
> 
>> 479:      * @param permission the <code>Permission</code> object to add.
>> 480:      *
>> 481:      * @exception SecurityException - if this
> 
> Should be ok to remove "-"?

removed

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 46:
> 
>> 44: 
>> 45: /**
>> 46:  * This class contains <code>CryptoPermission</code> objects, organized into
> 
> Use {@code } for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 78:
> 
>> 76:      * the array are copied to protect against subsequent modification.
>> 77:      * @exception NullPointerException if the <code>encoded</code> is
>> 78:      * <code>null</code>.
> 
> Use `{@code }` instead of `<code></code>` for all of the javadoc?

using `{@code }`

> src/java.base/share/classes/javax/crypto/ExemptionMechanism.java line 74:
> 
>> 72: 
>> 73:     /**
>> 74:      * Creates an <code>ExemptionMechanism</code> object.
> 
> Use `{@code }` instead of `<code></code>` for all of the javadoc?

Yes.

> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 60:
> 
>> 58:  * method in this {@code KeyGenerator} class that takes these two universally
>> 59:  * shared types of arguments. There is also one that takes just a
>> 60:  * {@code keysize} argument, and uses the SecureRandom implementation
> 
> Add `{@code }` to the SecureRandom?

Fixed.

> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 207:
> 
>> 205:      * for the specified algorithm.
>> 206:      *
>> 207:      * <p> This method traverses the list of registered security Providers,
> 
> Providers -> providers

Fixed.

> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 208:
> 
>> 206:      *
>> 207:      * <p> This method traverses the list of registered security Providers,
>> 208:      * starting with the most preferred Provider.
> 
> Provider -> provider

Fixed.

> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 211:
> 
>> 209:      * A new {@code KeyGenerator} object encapsulating the
>> 210:      * {@code KeyGeneratorSpi} implementation from the first
>> 211:      * Provider that supports the specified algorithm is returned.
> 
> Provider -> provider

Fixed.

> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 298:
> 
>> 296:      * <p> A new {@code KeyGenerator} object encapsulating the
>> 297:      * {@code KeyGeneratorSpi} implementation from the specified Provider
>> 298:      * object is returned.  Note that the specified Provider object
> 
> Same for this one as well.

Fixed.

> src/java.base/share/classes/javax/crypto/Mac.java line 146:
> 
>> 144:      *
>> 145:      * <p> This method traverses the list of registered security Providers,
>> 146:      * starting with the most preferred Provider.
> 
> Change "Providers"/"Provider" to start with lowercase.

Fixed.

> src/java.base/share/classes/javax/crypto/Mac.java line 149:
> 
>> 147:      * A new {@code Mac} object encapsulating the
>> 148:      * {@code MacSpi} implementation from the first
>> 149:      * Provider that supports the specified algorithm is returned.
> 
> Provider -> provider

Fixed.

> src/java.base/share/classes/javax/crypto/Mac.java line 243:
> 
>> 241:      *
>> 242:      * <p> A new {@code Mac} object encapsulating the
>> 243:      * {@code MacSpi} implementation from the specified Provider
> 
> Provider -> provider

Fixed.

> src/java.base/share/classes/javax/crypto/NoSuchPaddingException.java line 45:
> 
>> 43: 
>> 44:     /**
>> 45:      * Constructs a <code>NoSuchPaddingException</code> with no detail
> 
> Use `{@code }` for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/NoSuchPaddingException.java line 46:
> 
>> 44:     /**
>> 45:      * Constructs a <code>NoSuchPaddingException</code> with no detail
>> 46:      * message. A detail message is a String that describes this
> 
> Add `{@code }` to String

Fixed everywhere.

> src/java.base/share/classes/javax/crypto/NullCipher.java line 29:
> 
>> 27: 
>> 28: /**
>> 29:  * The <code>NullCipher</code> class is a class that provides an
> 
> Use `{@code }` for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/ProviderVerifier.java line 54:
> 
>> 52: 
>> 53:     /**
>> 54:      * Creates a <code>ProviderVerifier</code> object to verify the given URL.
> 
> Use `{@code }` for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/SealedObject.java line 43:
> 
>> 41:  * confidentiality with a cryptographic algorithm.
>> 42:  *
>> 43:  * <p> Given any Serializable object, one can create a <code>SealedObject</code>
> 
> Use `{@code }` for all of the javadoc in this class?

using `{@code }`

> src/java.base/share/classes/javax/crypto/SealedObject.java line 195:
> 
>> 193:     /**
>> 194:      * Constructs a <code>SealedObject</code> object from the passed-in
>> 195:      * SealedObject.
> 
> Add `{@code }` to SealedObject?

using `{@code }`

> src/java.base/share/classes/javax/crypto/SealedObject.java line 198:
> 
>> 196:      *
>> 197:      * @param so a <code>SealedObject</code> object
>> 198:      * @exception NullPointerException if the given sealed object is null.
> 
> Add `{@code }` to null?

Fixed.

> src/java.base/share/classes/javax/crypto/SecretKeyFactory.java line 131:
> 
>> 129:      * A new {@code SecretKeyFactory} object encapsulating the
>> 130:      * {@code SecretKeyFactorySpi} implementation from the first
>> 131:      * Provider that supports the specified algorithm is returned.
> 
> Provider -> provider

Fixed.

> src/java.base/share/classes/javax/crypto/SecretKeyFactory.java line 219:
> 
>> 217:      *
>> 218:      * <p> A new {@code SecretKeyFactory} object encapsulating the
>> 219:      * {@code SecretKeyFactorySpi} implementation from the specified Provider
> 
> Provider->provider

Fixed.

> src/java.base/share/classes/javax/crypto/ShortBufferException.java line 45:
> 
>> 43: 
>> 44:     /**
>> 45:      * Constructs a <code>ShortBufferException</code> with no detail
> 
> Use `{@code }` for all of the javadoc in this class?

using `{@code }`

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

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

From duke at openjdk.org  Thu Jun 30 16:22:26 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:22:26 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <3V0GsqDYq67YLBbXhdGDwKxn9Q5lT9IolmH0aT-CaiY=.4a99ad23-0ee3-49ae-94f6-5dca27cc5e98@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <DmSgNp1f6G_TqpA7zgl8J5NYGMb-FKvQpIf7QzExy5k=.85a9f7e9-ec06-4208-b374-ff64f5ac84b7@github.com>
 <5n7tn0qeUdhBs_UyTHO0GNiXy6aalc7TCrXLjiGmR1o=.8c06360e-3726-4b1f-bec8-19750337e9e9@github.com>
 <3V0GsqDYq67YLBbXhdGDwKxn9Q5lT9IolmH0aT-CaiY=.4a99ad23-0ee3-49ae-94f6-5dca27cc5e98@github.com>
Message-ID: <JUdf1VqkRDV-sWqe9XdHK2lcoMpg-NsL9qphru_TSpw=.602087f9-cc8f-4a4c-a9b3-c217e817db98@github.com>

On Wed, 29 Jun 2022 21:31:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Are you suggesting that whenever file is modified, **all** occurrences of `<code></code>` should be changed to `{@code }`?
>
> At least for new changes, I prefer to use new notations.. If its easier to replace all, that's fine with me too.

Changed **all** occurrences of `<code></code>` in all files to `{@code }`.

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

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

From duke at openjdk.org  Thu Jun 30 16:22:24 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:22:24 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <qbx4xlSnipE4OMhCeQvLGT-imma9UG_g629pQXhxQpw=.04a98b81-3859-4757-b708-4b12edb031fe@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
 <gil9_lprQ4gywyPw494PDGscxhs2XBgHGVDh2aBfaec=.9938d4e3-fd7b-4aa1-b827-de6b5368c1e5@github.com>
 <fMPnztkyULIHXNYN7rHtcDjRZPPbnIs-8eTxYtEqfhI=.6f062442-b33b-49e7-b3f4-52326a61b52e@github.com>
 <qbx4xlSnipE4OMhCeQvLGT-imma9UG_g629pQXhxQpw=.04a98b81-3859-4757-b708-4b12edb031fe@github.com>
Message-ID: <G4fon1zLyCD-7479mZdi_f-YoLGh1Q_3zYXiAtZ5RPY=.013301c4-2710-4d6f-ac32-f0004324986a@github.com>

On Wed, 29 Jun 2022 21:29:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> In this case the sentence was about initializing a cipher object, so I changed it to `{@code Cipher}`. If a sentence says "cipher block size" then I tried to leave it alone because it's referring to an algorithm rather than a class or object. I could add "object" after `{@code Cipher} `if it's not present. That would make it more consistent.
>
> Ok, add object afterwards would make it more consistent.

fixed: `{@code Cipher} `object

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

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

From duke at openjdk.org  Thu Jun 30 16:22:28 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:22:28 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <ZSBDKDc_SaxCioxNANj6lg03oNjShC51reb2ri0lEoA=.5a570e3f-ef97-4649-9ff8-514d830e9541@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>
 <ZSBDKDc_SaxCioxNANj6lg03oNjShC51reb2ri0lEoA=.5a570e3f-ef97-4649-9ff8-514d830e9541@github.com>
Message-ID: <kdf6MDf73qqgVEngc28hJ0osk60Nl3034lEIXNVrARU=.2345e0c7-fac9-4350-b768-94e3df104f46@github.com>

On Tue, 28 Jun 2022 22:06:00 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KeyGenerator.java line 297:
>> 
>>> 295:      *
>>> 296:      * <p> A new {@code KeyGenerator} object encapsulating the
>>> 297:      * {@code KeyGeneratorSpi} implementation from the specified Provider
>> 
>> Change "Provider" to start with lowercase or add `{@code }`
>
> Other methods seem to use "provider".

Using lowercase.

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

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

From duke at openjdk.org  Thu Jun 30 16:22:29 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:22:29 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <AtPtV5FZSK_poM_d4EQ2yodFjjTUfVwQ0ROWzHNSsvE=.c6be8ccf-6f52-4497-b936-c898eda4c7cf@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <IsL4ZumSCT7Y3mGO2ZC74BbzeajI20YdiYrvZNMtU-U=.23f60c1a-bf85-4b2f-b61f-566865bf9ce4@github.com>
 <AtPtV5FZSK_poM_d4EQ2yodFjjTUfVwQ0ROWzHNSsvE=.c6be8ccf-6f52-4497-b936-c898eda4c7cf@github.com>
Message-ID: <WZ2w9Y3j8cCWrW-tifO8-ZLTygxNseoWqU00DBW-4I4=.2c8800e7-1265-46f8-8313-96ed3193701a@github.com>

On Wed, 29 Jun 2022 01:01:44 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/ProviderVerifier.java line 170:
>> 
>>> 168:      * NOTE: if this <code>ProviderVerifier</code> instance is constructed
>>> 169:      * with "savePerms" equal to false, then this method would always
>>> 170:      * return null.
>> 
>> Add `{@code }` to "false" and "null"
>
> I had wasn't aware that this was as common as it is.

Fixed here and elsewhere.

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

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

From duke at openjdk.org  Thu Jun 30 16:37:49 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 16:37:49 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v3]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <ZBBAASwS2iWAaZrmggZ8S_GpvHTUbImpww1cswAC7iU=.22ee5c81-e290-4a2e-8c66-ddc2b679e612@github.com>

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

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

  Valerie fix continued

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/eadba29f..8cef9b66

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

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

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

From xuelei at openjdk.org  Thu Jun 30 18:27:46 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 18:27:46 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
Message-ID: <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>

On Thu, 30 Jun 2022 15:53:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Master
>>  - use Reference.refersTo
>>  - remove trailing whitespaces
>>  - use timeout factor
>>  - Merge
>>  - Merge master
>>  - Merge
>>  - add timeout parameter
>>  - rollback is not in this branch
>>  - rollback JDK-8287384
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282
>
> test/lib/jdk/test/lib/util/ForceGC.java line 70:
> 
>> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
>> 69:                 // to trigger and complete the cleanup.
>> 70:                 queue.remove(200L);
> 
> If `remove()` returns a non-null value, then it is safe to break out of the loop.
> The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.

I'm not sure if all unused object will be collected in one GC call always.  The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued."  But from the spec, I did not get a clear answer for the question.

If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer.

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

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

From xuelei at openjdk.org  Thu Jun 30 18:44:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 18:44:30 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update per feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8979/files
  - new: https://git.openjdk.org/jdk/pull/8979/files/0f196282..31dffa98

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

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

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

From xuelei at openjdk.org  Thu Jun 30 18:44:33 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 18:44:33 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
Message-ID: <VbltzvNUauy1u4WSzKZh_nCRBijebSNfSWWgSxW-3j4=.5e0d6fd6-0e87-4578-8b49-4e4db5ae0fe1@github.com>

On Thu, 30 Jun 2022 15:48:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Master
>>  - use Reference.refersTo
>>  - remove trailing whitespaces
>>  - use timeout factor
>>  - Merge
>>  - Merge master
>>  - Merge
>>  - add timeout parameter
>>  - rollback is not in this branch
>>  - rollback JDK-8287384
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282
>
> test/lib/jdk/test/lib/util/ForceGC.java line 58:
> 
>> 56:         Reference.reachabilityFence(ref);
>> 57: 
>> 58:         for (int retries = (int)(timeout / 200); retries >= 0; retries--) {
> 
> The logic around the timeout might be clearer if it was only based on the number of retries,
> and can be scaled by the TIMEOUT_FACTOR too.

I just curious if the factor could be set to some unusual values like "1.25".  Scaling on timeout, and then calculating the retires could be more accuracy for such circumstances, although it may be not necessary.  I moved the retries calculation close to the for-loop.  Hope it is better for readers.

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

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

From rriggs at openjdk.org  Thu Jun 30 20:38:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 20:38:40 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
Message-ID: <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>

On Thu, 30 Jun 2022 18:24:14 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 70:
>> 
>>> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
>>> 69:                 // to trigger and complete the cleanup.
>>> 70:                 queue.remove(200L);
>> 
>> If `remove()` returns a non-null value, then it is safe to break out of the loop.
>> The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.
>
> I'm not sure if all unused object will be collected in one GC call always.  The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued."  But from the spec, I did not get a clear answer for the question.
> 
> If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer.

True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object.
System.gc is just a request, the checking for an object can more quickly exit the loop.
The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed.  Ok as it.

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

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

From rriggs at openjdk.org  Thu Jun 30 20:49:42 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 20:49:42 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
Message-ID: <kdeNVRI0a2WhTZ4QHKXQQUib_H0ZEzLT4lnwKovAO-U=.87564f83-7bf2-431e-9e62-90e226b8e097@github.com>

On Thu, 30 Jun 2022 18:44:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update per feedback

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.org  Thu Jun 30 20:49:44 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 20:49:44 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <VbltzvNUauy1u4WSzKZh_nCRBijebSNfSWWgSxW-3j4=.5e0d6fd6-0e87-4578-8b49-4e4db5ae0fe1@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <VbltzvNUauy1u4WSzKZh_nCRBijebSNfSWWgSxW-3j4=.5e0d6fd6-0e87-4578-8b49-4e4db5ae0fe1@github.com>
Message-ID: <a3HMm9632zy9X53fvV3ePez8zQs0rc79nM6SBCtNPaE=.daad8e84-e8ec-4234-abd8-5db289581d24@github.com>

On Thu, 30 Jun 2022 18:39:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 58:
>> 
>>> 56:         Reference.reachabilityFence(ref);
>>> 57: 
>>> 58:         for (int retries = (int)(timeout / 200); retries >= 0; retries--) {
>> 
>> The logic around the timeout might be clearer if it was only based on the number of retries,
>> and can be scaled by the TIMEOUT_FACTOR too.
>
> I just curious if the factor could be set to some unusual values like "1.25".  Scaling on timeout, and then calculating the retires could be more accuracy for such circumstances, although it may be not necessary.  I moved the retries calculation close to the for-loop.  Hope it is better for readers.

Yes, `Utils.adjustTimeout(long x)` uses floating point and then converts back.

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

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

From valeriep at openjdk.org  Thu Jun 30 22:14:44 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 30 Jun 2022 22:14:44 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
Message-ID: <KfsB5pjuppcXty36x87fx0sFID0eGy5pxboOD1L9EXY=.2aaa35b2-2610-4413-a119-4fecf3b1b365@github.com>

On Tue, 28 Jun 2022 13:20:53 GMT, zzambers <duke at openjdk.org> wrote:

>> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
>> 
>> Exception:
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
>> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
>> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
>> ...
>> 
>> 
>> Details:
>> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
>> 
>> Solution:
>> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
>> 
>> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug number and copyright date

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 822:

> 820:                         // block is created
> 821:                         if (padBufferLen == padBuffer.length) {
> 822:                             k += token.p11.C_EncryptUpdate(session.id(),

can just be "="?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 920:

> 918:                         // block is created
> 919:                         if (padBufferLen == padBuffer.length) {
> 920:                             k += token.p11.C_EncryptUpdate(session.id(),

can just be "="?

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

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

From duke at openjdk.org  Thu Jun 30 22:29:19 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 22:29:19 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
Message-ID: <h8vwBK3INkIx1BkRGcgnqjijaT4G5v-7I4V6k7asMZ8=.90cb4816-9d1d-4734-9a1f-369bcf81bde6@github.com>

On Tue, 28 Jun 2022 19:59:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/java/security/AccessController.java line 983:
> 
>> 981: 
>> 982:     /**
>> 983:      * Returns the "inherited" AccessControl context. This is the context
> 
> Not sure what "AccessControl context" is. Either "access control context" or "{@code AccessControlContext}".

using `{@code AccessControlContext}`

> src/java.base/share/classes/java/security/AccessController.java line 993:
> 
>> 991:     /**
>> 992:      * This method takes a "snapshot" of the current calling context, which
>> 993:      * includes the current Thread's inherited {@code AccessControlContext}
> 
> "Thread" to "thread".

Fixed in this file and a couple of others.

> src/java.base/share/classes/java/security/AccessController.java line 1021:
> 
>> 1019:      * the current {@code AccessControlContext} and security policy.
>> 1020:      * This method quietly returns if the access request
>> 1021:      * is permitted, or throws an AccessControlException otherwise. The
> 
> Want to code-ify "AccessControlException" as well?

Fixed.

> src/java.base/share/classes/java/security/AccessController.java line 1023:
> 
>> 1021:      * is permitted, or throws an AccessControlException otherwise. The
>> 1022:      * {@code getPermission} method of the AccessControlException returns the
>> 1023:      * {@code perm} {@code Permission} object instance.
> 
> Two "{@code" together. Maybe move "{@code perm}" to the end?

Moved to end.

> src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java line 144:
> 
>> 142:      * A new {@code AlgorithmParameterGenerator} object encapsulating the
>> 143:      * {@code AlgorithmParameterGeneratorSpi} implementation from the first
>> 144:      * Provider that supports the specified algorithm is returned.
> 
> "Provider" -> "provider".

Fixed.

> src/java.base/share/classes/java/security/Security.java line 1032:
> 
>> 1030:      * Returns a Set of Strings containing the names of all available
>> 1031:      * algorithms or types for the specified Java cryptographic service
>> 1032:      * (e.g., Signature, MessageDigest, Cipher, Mac, KeyStore). Returns
> 
> All these Java cryptographic service type names.

using `{@code }`

> src/java.base/share/classes/java/security/Security.java line 1033:
> 
>> 1031:      * algorithms or types for the specified Java cryptographic service
>> 1032:      * (e.g., Signature, MessageDigest, Cipher, Mac, KeyStore). Returns
>> 1033:      * an empty Set if there is no provider that supports the
> 
> "set" is OK.

Fixed.

> src/java.base/share/classes/java/security/Security.java line 1034:
> 
>> 1032:      * (e.g., Signature, MessageDigest, Cipher, Mac, KeyStore). Returns
>> 1033:      * an empty Set if there is no provider that supports the
>> 1034:      * specified service or if serviceName is {@code null}. For a complete list
> 
> `{@code serviceName}`.

Fixed.

> src/java.base/share/classes/java/security/UnresolvedPermission.java line 67:
> 
>> 65:  * containing information about the permission.
>> 66:  *
>> 67:  * <p>Later, when code calls AccessController.checkPermission
> 
> AccessController.checkPermission. Maybe make it a link.

made it a link

> src/java.base/share/classes/java/security/UnresolvedPermission.java line 329:
> 
>> 327:      * @param obj the object we are testing for equality with this object.
>> 328:      *
>> 329:      * @return true if obj is an {@code UnresolvedPermission}, and has the same
> 
> `{@code obj}`.

fixed

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

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

From duke at openjdk.org  Thu Jun 30 22:33:05 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 30 Jun 2022 22:33:05 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v4]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <KPSt9mmWm1iSvOuNXGM3suq302X-yeg3JeG9l_z6Owo=.bbc59309-b18b-4a7f-bc14-8fbde48cda1b@github.com>

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

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

  Max comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/8cef9b66..e21432f5

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

  Stats: 37 lines in 7 files changed: 2 ins; 1 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/9282.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9282/head:pull/9282

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

From valeriep at openjdk.org  Thu Jun 30 22:47:52 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 30 Jun 2022 22:47:52 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
Message-ID: <c6b5PkrXFutHsszjKG72lDUeNrpr32xpV7VjJBT0mZk=.eabc39e5-6ee7-4c59-931e-ce02bb45d851@github.com>

On Tue, 28 Jun 2022 13:20:53 GMT, zzambers <duke at openjdk.org> wrote:

>> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
>> 
>> Exception:
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
>> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
>> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
>> ...
>> 
>> 
>> Details:
>> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
>> 
>> Solution:
>> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
>> 
>> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug number and copyright date

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 820:

> 818:                         // unless padBuffer is already full in which case
> 819:                         // EncryptUpdate is performed and whole new padding
> 820:                         // block is created

suggestion on comment: 
// call C_EncryptUpdate first if the padBuffer is full to make room for padding bytes

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 918:

> 916:                         // unless padBuffer is already full in which case
> 917:                         // EncryptUpdate is performed and whole new padding
> 918:                         // block is created

Same suggestion on this as above.

test/jdk/sun/security/pkcs11/Cipher/TestPaddingOOB.java line 27:

> 25:  * @test
> 26:  * @bug 8289301
> 27:  * @summary P11Cipher should not throw OOB exception during padding

nit: add when "reqBlockUpdates" == true

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

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

From valeriep at openjdk.org  Thu Jun 30 23:00:52 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 30 Jun 2022 23:00:52 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
Message-ID: <UswhV-rilb_n0ca5sQl1frD85GTGivCPhPMpzRs6HEI=.7227ddeb-c149-466b-a437-fc5765f1438f@github.com>

On Tue, 28 Jun 2022 13:20:53 GMT, zzambers <duke at openjdk.org> wrote:

>> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
>> 
>> Exception:
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
>> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
>> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
>> ...
>> 
>> 
>> Details:
>> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
>> 
>> Solution:
>> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
>> 
>> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug number and copyright date

test/jdk/sun/security/pkcs11/Cipher/TestPaddingOOB.java line 61:

> 59:         off += c.doFinal(plainArr, 1, plainArr.length - 1, encArr, off);
> 60:         if (off != 2 * bs) {
> 61:             throw new Exception("Unexpected encrypted size (array)");

nit: add the value of "off" to the exception message which may come in handy if the test were to fail later.

test/jdk/sun/security/pkcs11/Cipher/TestPaddingOOB.java line 67:

> 65:         off = c.doFinal(encArr, 0, encArr.length, plainArr2, 0);
> 66:         if (off != bs) {
> 67:             throw new Exception("Unexpected decrypted size (array)");

nit: add the value of "off" to the exception message which may come in handy if the test were to fail later.

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

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