From shade at openjdk.java.net  Mon Jan  3 08:57:18 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 3 Jan 2022 08:57:18 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v2]
In-Reply-To: <n0aDv18E-vXk34SqgW3rf7HOhpbG81pi5ERLoRcOaWc=.a6f3d68e-152d-4e84-aa88-d5d619a388e5@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <DO57qsClAqxzZfO9Jr23kwnxx-LUGw3PqZo266cFbpQ=.2e9d51f3-6d35-4dd0-848c-dd937e37f9f7@github.com>
 <Ioz_Dx-_aELhbjHdqPqhlk8ofkXPiWk1zfy-zkeG57s=.1592014b-7f73-49a6-9b52-72132f0b0cd0@github.com>
 <n0aDv18E-vXk34SqgW3rf7HOhpbG81pi5ERLoRcOaWc=.a6f3d68e-152d-4e84-aa88-d5d619a388e5@github.com>
Message-ID: <YRDoSAP1ByXOGacj5pb5ikkpHcqd-2oXurDR2hqpZ9M=.d3855152-ca91-45c2-b261-cdc3932eade1@github.com>

On Thu, 23 Dec 2021 21:06:51 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Hmm, this "ADD" case should be covered by existing regression tests. I will take a look. Thanks.
>
> Hmm, existing test does add an alias, the legacyMap.get() would returns null upon 'aliasAlg' (type: String). To test this particular scenario, I enhanced existing regression test to re-assign an alias and then check if the returned impl is as expected. The proposed test patch is attached. If we are including this test patch into this PR, then good to add the bug id to the test too.
> [patch.txt](https://github.com/openjdk/jdk18/files/7771389/patch.txt)

Ping @valeriepeng ^^^

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From mbaesken at openjdk.java.net  Mon Jan  3 15:00:27 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 3 Jan 2022 15:00:27 GMT
Subject: RFR: JDK-8279385: [test] Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
Message-ID: <A-w0ujoYCFKjEqOU39TsLkzIDRPYHGRDfprIhwOuEhk=.9a642dec-15bc-4e84-b15a-9c63617ed89b@github.com>

Hello , please review this XXS test adjustment.  After 8278344, it has been commented that better shouldMatch should be used for the adjusted test parsing output of different OpenSSL versions.

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

Commit messages:
 - JDK-8279385

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

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

From weijun at openjdk.java.net  Mon Jan  3 15:46:14 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 3 Jan 2022 15:46:14 GMT
Subject: RFR: JDK-8279385: [test] Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
In-Reply-To: <A-w0ujoYCFKjEqOU39TsLkzIDRPYHGRDfprIhwOuEhk=.9a642dec-15bc-4e84-b15a-9c63617ed89b@github.com>
References: <A-w0ujoYCFKjEqOU39TsLkzIDRPYHGRDfprIhwOuEhk=.9a642dec-15bc-4e84-b15a-9c63617ed89b@github.com>
Message-ID: <U0NboTGb-bXr7MPjFnDOTlk7MgLwbeMJWqyXswmSbiI=.f39381b8-3fc6-4eee-b4ad-38c4426a2852@github.com>

On Mon, 3 Jan 2022 14:52:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello , please review this XXS test adjustment.  After 8278344, it has been commented that better shouldMatch should be used for the adjusted test parsing output of different OpenSSL versions.

Hurray! I see 2022!

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

Marked as reviewed by weijun (Reviewer).

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

From valeriep at openjdk.java.net  Mon Jan  3 21:43:19 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 3 Jan 2022 21:43:19 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v2]
In-Reply-To: <YRDoSAP1ByXOGacj5pb5ikkpHcqd-2oXurDR2hqpZ9M=.d3855152-ca91-45c2-b261-cdc3932eade1@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <DO57qsClAqxzZfO9Jr23kwnxx-LUGw3PqZo266cFbpQ=.2e9d51f3-6d35-4dd0-848c-dd937e37f9f7@github.com>
 <Ioz_Dx-_aELhbjHdqPqhlk8ofkXPiWk1zfy-zkeG57s=.1592014b-7f73-49a6-9b52-72132f0b0cd0@github.com>
 <n0aDv18E-vXk34SqgW3rf7HOhpbG81pi5ERLoRcOaWc=.a6f3d68e-152d-4e84-aa88-d5d619a388e5@github.com>
 <YRDoSAP1ByXOGacj5pb5ikkpHcqd-2oXurDR2hqpZ9M=.d3855152-ca91-45c2-b261-cdc3932eade1@github.com>
Message-ID: <c1WVv1lfF5bOMy4j-bDk34Wqbg1m9Ix1TcEFu5DUKJw=.035b4cbf-67aa-418d-98e4-ba3ed5868032@github.com>

On Mon, 3 Jan 2022 08:53:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hmm, existing test does add an alias, the legacyMap.get() would returns null upon 'aliasAlg' (type: String). To test this particular scenario, I enhanced existing regression test to re-assign an alias and then check if the returned impl is as expected. The proposed test patch is attached. If we are including this test patch into this PR, then good to add the bug id to the test too.
>> [patch.txt](https://github.com/openjdk/jdk18/files/7771389/patch.txt)
>
> Ping @valeriepeng ^^^

The test update checks that the alias maps to the right algorithm. However, the particular code change covered by this fix is for removing the alias from the previous algorithm which is not triggered by the test change. Alias is an internal property of the Service object. Let me explore more and see if it can be triggered.

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From valeriep at openjdk.java.net  Mon Jan  3 22:40:30 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 3 Jan 2022 22:40:30 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v2]
In-Reply-To: <c1WVv1lfF5bOMy4j-bDk34Wqbg1m9Ix1TcEFu5DUKJw=.035b4cbf-67aa-418d-98e4-ba3ed5868032@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <DO57qsClAqxzZfO9Jr23kwnxx-LUGw3PqZo266cFbpQ=.2e9d51f3-6d35-4dd0-848c-dd937e37f9f7@github.com>
 <Ioz_Dx-_aELhbjHdqPqhlk8ofkXPiWk1zfy-zkeG57s=.1592014b-7f73-49a6-9b52-72132f0b0cd0@github.com>
 <n0aDv18E-vXk34SqgW3rf7HOhpbG81pi5ERLoRcOaWc=.a6f3d68e-152d-4e84-aa88-d5d619a388e5@github.com>
 <YRDoSAP1ByXOGacj5pb5ikkpHcqd-2oXurDR2hqpZ9M=.d3855152-ca91-45c2-b261-cdc3932eade1@github.com>
 <c1WVv1lfF5bOMy4j-bDk34Wqbg1m9Ix1TcEFu5DUKJw=.035b4cbf-67aa-418d-98e4-ba3ed5868032@github.com>
Message-ID: <ft06MSI5Rr3dwhEsyyL-cjC-vo4S_BEb9JZWrURymfo=.dfc83ce3-a1dc-4001-9b6b-8f9de9157145@github.com>

On Mon, 3 Jan 2022 21:39:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Ping @valeriepeng ^^^
>
> The test update checks that the alias maps to the right algorithm. However, the particular code change covered by this fix is for removing the alias from the previous algorithm which is not triggered by the test change. Alias is an internal property of the Service object. Let me explore more and see if it can be triggered.

There is no public API for retrieving the aliases from a given Service object. However, it's reported as part of toString(). So, we can check the toString() output to see if the alias is removed from the previous service. Updated test patch attached.
[patch.txt](https://github.com/openjdk/jdk18/files/7804357/patch.txt)

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From shade at openjdk.java.net  Tue Jan  4 06:59:58 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 4 Jan 2022 06:59:58 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v3]
In-Reply-To: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
Message-ID: <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>

> SonarCloud reports:
>  A "Map<ServiceKey, Service>" cannot contain a "String" in a "ServiceKey" type.
> 
> 
>      // clean up old alias if present
>      Service prevAliasService = legacyMap.get(aliasAlg);
> 
> 
> Should be `aliasKey`, like other accesses to `legacyMap`. This code is introduced by [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it affects JDK 18.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `jdk_security`

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

 - Whitespace
 - Metadata updates
 - Merge branch 'master' into JDK-8279222-jsp-get
 - Test addition by Valerie
 - Merge branch 'master' into JDK-8279222-jsp-get
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/70/files
  - new: https://git.openjdk.java.net/jdk18/pull/70/files/9c6af4bb..590442dc

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

  Stats: 528 lines in 43 files changed: 430 ins; 0 del; 98 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/70.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/70/head:pull/70

PR: https://git.openjdk.java.net/jdk18/pull/70

From shade at openjdk.java.net  Tue Jan  4 06:59:59 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 4 Jan 2022 06:59:59 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v3]
In-Reply-To: <ft06MSI5Rr3dwhEsyyL-cjC-vo4S_BEb9JZWrURymfo=.dfc83ce3-a1dc-4001-9b6b-8f9de9157145@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <DO57qsClAqxzZfO9Jr23kwnxx-LUGw3PqZo266cFbpQ=.2e9d51f3-6d35-4dd0-848c-dd937e37f9f7@github.com>
 <Ioz_Dx-_aELhbjHdqPqhlk8ofkXPiWk1zfy-zkeG57s=.1592014b-7f73-49a6-9b52-72132f0b0cd0@github.com>
 <n0aDv18E-vXk34SqgW3rf7HOhpbG81pi5ERLoRcOaWc=.a6f3d68e-152d-4e84-aa88-d5d619a388e5@github.com>
 <YRDoSAP1ByXOGacj5pb5ikkpHcqd-2oXurDR2hqpZ9M=.d3855152-ca91-45c2-b261-cdc3932eade1@github.com>
 <c1WVv1lfF5bOMy4j-bDk34Wqbg1m9Ix1TcEFu5DUKJw=.035b4cbf-67aa-418d-98e4-ba3ed5868032@github.com>
 <ft06MSI5Rr3dwhEsyyL-cjC-vo4S_BEb9JZWrURymfo=.dfc83ce3-a1dc-4001-9b6b-8f9de9157145@github.com>
Message-ID: <I-g0JbM3EzDLCgJRQQWRfF4LNE3a-DyK57e2Sun2qLs=.0eea685f-3c28-4be0-87ea-f4219f43e3a8@github.com>

On Mon, 3 Jan 2022 22:36:32 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> The test update checks that the alias maps to the right algorithm. However, the particular code change covered by this fix is for removing the alias from the previous algorithm which is not triggered by the test change. Alias is an internal property of the Service object. Let me explore more and see if it can be triggered.
>
> There is no public API for retrieving the aliases from a given Service object. However, it's reported as part of toString(). So, we can check the toString() output to see if the alias is removed from the previous service. Updated test patch attached.
> [patch.txt](https://github.com/openjdk/jdk18/files/7804357/patch.txt)

All right, thank you, @valeriepeng! The new test fails without the patch, and passes with it. I added it to PR.

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From mbaesken at openjdk.java.net  Tue Jan  4 07:59:15 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 4 Jan 2022 07:59:15 GMT
Subject: Integrated: JDK-8279385: [test] Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
In-Reply-To: <A-w0ujoYCFKjEqOU39TsLkzIDRPYHGRDfprIhwOuEhk=.9a642dec-15bc-4e84-b15a-9c63617ed89b@github.com>
References: <A-w0ujoYCFKjEqOU39TsLkzIDRPYHGRDfprIhwOuEhk=.9a642dec-15bc-4e84-b15a-9c63617ed89b@github.com>
Message-ID: <UesgP57-s3h3dxxQGgiQ8pWgJk8rP6MmJal73Pb4Grg=.9027b4e8-a696-483f-b990-76484e1db340@github.com>

On Mon, 3 Jan 2022 14:52:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello , please review this XXS test adjustment.  After 8278344, it has been commented that better shouldMatch should be used for the adjusted test parsing output of different OpenSSL versions.

This pull request has now been integrated.

Changeset: 9bdf6eb7
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

Reviewed-by: weijun

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

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

From alanb at openjdk.java.net  Tue Jan  4 09:22:14 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 4 Jan 2022 09:22:14 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v3]
In-Reply-To: <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>
Message-ID: <PdvaG_ek1ozQweLebG0Bl_beAbZIo_IpyjI8hSYvPHs=.f359c9e4-424a-411e-803c-fc325073594d@github.com>

On Tue, 4 Jan 2022 06:59:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports:
>>  A "Map<ServiceKey, Service>" cannot contain a "String" in a "ServiceKey" type.
>> 
>> 
>>      // clean up old alias if present
>>      Service prevAliasService = legacyMap.get(aliasAlg);
>> 
>> 
>> Should be `aliasKey`, like other accesses to `legacyMap`. This code is introduced by [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it affects JDK 18.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `jdk_security`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Whitespace
>  - Metadata updates
>  - Merge branch 'master' into JDK-8279222-jsp-get
>  - Test addition by Valerie
>  - Merge branch 'master' into JDK-8279222-jsp-get
>  - Fix

Thanks for coordinating on this to ensure the change has a test.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/70

From mcimadamore at openjdk.java.net  Tue Jan  4 11:39:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 4 Jan 2022 11:39:08 GMT
Subject: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced
 correctly [v2]
In-Reply-To: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
References: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
Message-ID: <2IS_pwdOIbjzmlgcLlj5FjVcfpthKqpnCRxmoAVJxlg=.b3d58dcc-c006-45ec-8e66-a432d4e6cf2f@github.com>

> This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used.
> 
> For more details about the problem and the solution please refer to:
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html

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

 - Merge branch 'master' into heap-align
 - Initial push

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/37/files
  - new: https://git.openjdk.java.net/jdk18/pull/37/files/40a3acc3..3a860afa

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

  Stats: 2046 lines in 116 files changed: 1430 ins; 125 del; 491 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk18/pull/37

From jvernee at openjdk.java.net  Tue Jan  4 15:26:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 4 Jan 2022 15:26:11 GMT
Subject: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced
 correctly [v2]
In-Reply-To: <2IS_pwdOIbjzmlgcLlj5FjVcfpthKqpnCRxmoAVJxlg=.b3d58dcc-c006-45ec-8e66-a432d4e6cf2f@github.com>
References: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
 <2IS_pwdOIbjzmlgcLlj5FjVcfpthKqpnCRxmoAVJxlg=.b3d58dcc-c006-45ec-8e66-a432d4e6cf2f@github.com>
Message-ID: <pBQZfO5xIrlOwt67yBVE3KVXJ2bUnbHyyq0k52YXGIw=.5611d080-44eb-41f3-8a11-f768d001eb46@github.com>

On Tue, 4 Jan 2022 11:39:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used.
>> 
>> For more details about the problem and the solution please refer to:
>> https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into heap-align
>  - Initial push

Marked as reviewed by jvernee (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/37

From valeriep at openjdk.java.net  Tue Jan  4 18:10:19 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 4 Jan 2022 18:10:19 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v3]
In-Reply-To: <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>
Message-ID: <shZVGUzEdVTkgagkNZl9tAsf-5mdZjKCIoFbyOhCLMs=.19661cf3-d49b-4fc0-9d43-7f0b8f299e0e@github.com>

On Tue, 4 Jan 2022 06:59:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports:
>>  A "Map<ServiceKey, Service>" cannot contain a "String" in a "ServiceKey" type.
>> 
>> 
>>      // clean up old alias if present
>>      Service prevAliasService = legacyMap.get(aliasAlg);
>> 
>> 
>> Should be `aliasKey`, like other accesses to `legacyMap`. This code is introduced by [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it affects JDK 18.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `jdk_security`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Whitespace
>  - Metadata updates
>  - Merge branch 'master' into JDK-8279222-jsp-get
>  - Test addition by Valerie
>  - Merge branch 'master' into JDK-8279222-jsp-get
>  - Fix

Marked as reviewed by valeriep (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From shade at openjdk.java.net  Wed Jan  5 07:32:31 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 07:32:31 GMT
Subject: [jdk18] Integrated: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660
In-Reply-To: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
Message-ID: <CgWEZZQ8o3gB5hecropiiipy9Nphaa0QsuJO-14UJ7A=.9da97b2e-504b-406f-b6f1-ded29859c3a6@github.com>

On Thu, 23 Dec 2021 13:33:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports:
>  A "Map<ServiceKey, Service>" cannot contain a "String" in a "ServiceKey" type.
> 
> 
>      // clean up old alias if present
>      Service prevAliasService = legacyMap.get(aliasAlg);
> 
> 
> Should be `aliasKey`, like other accesses to `legacyMap`. This code is introduced by [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it affects JDK 18.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `jdk_security`

This pull request has now been integrated.

Changeset: 0f4807e8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/0f4807e8fe2468f303b32a6f2dc9ccc7ecad82a1
Stats:     18 lines in 2 files changed: 12 ins; 0 del; 6 mod

8279222: Incorrect legacyMap.get in java.security.Provider after JDK-8276660

Co-authored-by: Valerie Peng <valeriep at openjdk.org>
Reviewed-by: alanb, valeriep

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From shade at openjdk.java.net  Wed Jan  5 07:32:30 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 07:32:30 GMT
Subject: [jdk18] RFR: 8279222: Incorrect legacyMap.get in
 java.security.Provider after JDK-8276660 [v3]
In-Reply-To: <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>
References: <HoDZ8OeleHhfHFnljC9Y3ZkF3LGE6PcBuAcrDVM2tTc=.1c9d39b0-b6c1-4484-ad9f-d41f3b740ab8@github.com>
 <7IWy8DXeYdp337Ll_jLseVVzGe2tEeLatVvQxN7hjYE=.41694c7c-8b77-40e9-8462-18154d9de268@github.com>
Message-ID: <rdlQci6AyFi_s0vR8bzrzVjZAoc4yVkESENHkWh-7CU=.e5778414-d345-4e41-a5cc-03a90f49459b@github.com>

On Tue, 4 Jan 2022 06:59:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports:
>>  A "Map<ServiceKey, Service>" cannot contain a "String" in a "ServiceKey" type.
>> 
>> 
>>      // clean up old alias if present
>>      Service prevAliasService = legacyMap.get(aliasAlg);
>> 
>> 
>> Should be `aliasKey`, like other accesses to `legacyMap`. This code is introduced by [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660), so it affects JDK 18.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `jdk_security`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Whitespace
>  - Metadata updates
>  - Merge branch 'master' into JDK-8279222-jsp-get
>  - Test addition by Valerie
>  - Merge branch 'master' into JDK-8279222-jsp-get
>  - Fix

Thanks for reviews!

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

PR: https://git.openjdk.java.net/jdk18/pull/70

From duke at openjdk.java.net  Wed Jan  5 08:04:23 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 5 Jan 2022 08:04:23 GMT
Subject: Withdrawn: 8274308: Improve efficiency for HandshakeContext
 initialization.
In-Reply-To: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
Message-ID: <EZj27u525QDF0e9tMzX2-H1SbN1NbvndRudHOI1T9UM=.dd67ef0e-0485-4c8a-a2dd-c5f19ccf7804@github.com>

On Sat, 2 Oct 2021 05:45:47 GMT, Clive Verghese <cverghese at openjdk.org> wrote:

> Hi,
> 
> We have identified that the `HandshakeContext` initialization takes up a close to 50% of the flame graph for startHandshake. I have moved the computation of the `activeProtocols` and `activeCipherSuites` from the HandshakeContext constructor to SSLConfiguration class because the values used to compute the two list are available in the SSLConfiguration. 
> 
> In order to reuse this, I have initialized SSLConfiguration in the SSLSocketFactory and reused this when possible for Client Socket Constructors in the SSLSocketImpl. 
> 
> Sockets created from the SSLSocketFactory see this improvements. 
> 
> Old Benchmarks
> 
> Benchmark                                   Mode  Cnt  Score   Error   Units
> SSLStartHandshake.handshakeBenchmark       thrpt   25  0.247 ? 0.011  ops/ms
> SSLStartHandshake.handshakeBenchmark        avgt   25  4.210 ? 0.445   ms/op
> 
> New Benchmarks
> 
> SSLStartHandshake.handshakeBenchmark       thrpt   25  0.257 ? 0.017  ops/ms
> SSLStartHandshake.handshakeBenchmark        avgt   25  3.967 ? 0.208   ms/op
> 
> 
> 
> I have also attached the JFR profiles from before and after the change.
> Before
> <img width="2325" alt="SSLOverhead-old" src="https://user-images.githubusercontent.com/934461/135705010-a8502966-c6be-4cb5-b743-4a5b382c8e1f.png">
> 
> After 
> <img width="2310" alt="SSLOverhead-new" src="https://user-images.githubusercontent.com/934461/135705007-ea852b36-e10f-4741-a166-249270b34465.png">
>  
> We have been able to optimize the `TransportContext.kickstart` function by removing the `HandshakeContext.<init>`  initialization and reduce the time to start the handshake by reusing `activeProtocols` and `activeCipherSuites`
> 
> In addition to the SSL and http tests, I have run tier-1 and tier-2 tests and ensure that they pass. 
> 
> Looking for your feedback

This pull request has been closed without being integrated.

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

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

From myano at openjdk.java.net  Wed Jan  5 10:14:09 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 5 Jan 2022 10:14:09 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames
In-Reply-To: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
Message-ID: <jh1ahuoM_Nj2arQHd8EXYJ8QtDm8HUpdUarViqAupNI=.d4b98fbc-11f8-4056-8718-da6bccfe8204@github.com>

On Thu, 23 Dec 2021 11:59:18 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the JDK-8255739 bug fix?
> 
> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
> 
> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.

Could someone please review this pull request?

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

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

From mcimadamore at openjdk.java.net  Wed Jan  5 10:51:32 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 5 Jan 2022 10:51:32 GMT
Subject: [jdk18] Integrated: 8278897: Alignment of heap segments is not
 enforced correctly
In-Reply-To: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
References: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
Message-ID: <vLbC-BiPlGT1lE1JpN1cZxOo7oUWStnihEQtP0qDm44=.77da6055-3324-45e4-8190-fe1d66400586@github.com>

On Thu, 16 Dec 2021 12:31:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used.
> 
> For more details about the problem and the solution please refer to:
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html

This pull request has now been integrated.

Changeset: 9d43d25d
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/9d43d25da8bcfff425a795dcc230914a384a5c82
Stats:     600 lines in 20 files changed: 566 ins; 0 del; 34 mod

8278897: Alignment of heap segments is not enforced correctly

Reviewed-by: jvernee

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

PR: https://git.openjdk.java.net/jdk18/pull/37

From weijun at openjdk.java.net  Wed Jan  5 16:34:39 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 5 Jan 2022 16:34:39 GMT
Subject: RFR: 8279520: SPNEGO has not passed channel binding info into the
 underlying mechanism
Message-ID: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>

8279520: SPNEGO has not passed channel binding info into the underlying mechanism

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

Commit messages:
 - 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

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

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

From dcubed at openjdk.java.net  Wed Jan  5 17:34:33 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 5 Jan 2022 17:34:33 GMT
Subject: [jdk18] RFR: 8279529: ProblemList
 java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
Message-ID: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>

A couple of trivial ProblemListings:

JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java

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

Commit messages:
 - 8279532: ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java
 - 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64

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

PR: https://git.openjdk.java.net/jdk18/pull/83

From jnimeh at openjdk.java.net  Wed Jan  5 17:42:22 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 5 Jan 2022 17:42:22 GMT
Subject: [jdk18] RFR: 8279529: ProblemList
 java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
In-Reply-To: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
References: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
Message-ID: <x7I_IYfKmcYDcbuOVU-6zNa5fVLyYl_9KX_29ytUbLY=.f4f15d46-0a5a-4f3b-b214-42d69171a9f4@github.com>

On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial ProblemListings:
> 
> JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
> JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java

Looks good to me.

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

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/83

From alanb at openjdk.java.net  Wed Jan  5 18:13:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 5 Jan 2022 18:13:25 GMT
Subject: [jdk18] RFR: 8279529: ProblemList
 java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
In-Reply-To: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
References: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
Message-ID: <yAxrtBtFZ2fyUzxeos1bnhP0X32YaHLJfneb52HIYsA=.958e438a-2cfc-4cbc-8bc1-43833c5a33b7@github.com>

On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial ProblemListings:
> 
> JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
> JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java

This looks okay although I think we're working around a macOS or configuration issue rather than a JDK or test issue.

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

PR: https://git.openjdk.java.net/jdk18/pull/83

From dcubed at openjdk.java.net  Wed Jan  5 18:37:18 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 5 Jan 2022 18:37:18 GMT
Subject: [jdk18] RFR: 8279529: ProblemList
 java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
In-Reply-To: <x7I_IYfKmcYDcbuOVU-6zNa5fVLyYl_9KX_29ytUbLY=.f4f15d46-0a5a-4f3b-b214-42d69171a9f4@github.com>
References: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
 <x7I_IYfKmcYDcbuOVU-6zNa5fVLyYl_9KX_29ytUbLY=.f4f15d46-0a5a-4f3b-b214-42d69171a9f4@github.com>
Message-ID: <JN50fnDqahLQ_C9T1bx7OP4d_Pbs4v3N2umfjZkEvBQ=.44c4a04c-07b3-4b1a-8b5c-35c49372b59e@github.com>

On Wed, 5 Jan 2022 17:39:16 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> A couple of trivial ProblemListings:
>> 
>> JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
>> JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java
>
> Looks good to me.

@jnimeh - Thanks for the review.

@AlanBateman - I presume you are talking about
java/nio/channels/DatagramChannel/ManySourcesAndTargets.java.
It could be a macosx-aarch64 config issue and if we can get to the
bottom of that issue, then we can re-enable the test. For now, with
the JDK18 clock ticking down, I'd like to reduce the noise in the CI.

Did you plan on adding your reviewer approval here?

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

PR: https://git.openjdk.java.net/jdk18/pull/83

From dcubed at openjdk.java.net  Wed Jan  5 19:04:18 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 5 Jan 2022 19:04:18 GMT
Subject: [jdk18] Integrated: 8279529: ProblemList
 java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
In-Reply-To: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
References: <r2SVVv08IaIROG6ltNfc6Av9btUQwVWGta7Q2DfIpAg=.9c53b490-76a3-4a58-b439-f47a0ddb90f5@github.com>
Message-ID: <2BPWevmssx0ch_cnM_yKhgVKfrxzdyM7qGggLBquG4A=.a56aedf9-c272-4cee-9e45-f53c51de6288@github.com>

On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial ProblemListings:
> 
> JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
> JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java

This pull request has now been integrated.

Changeset: 564c8c63
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/564c8c6390ee380ab2e2eb73ef22c3184c369f9f
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
8279532: ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java

Reviewed-by: jnimeh

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

PR: https://git.openjdk.java.net/jdk18/pull/83

From jwilhelm at openjdk.java.net  Thu Jan  6 00:52:49 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 6 Jan 2022 00:52:49 GMT
Subject: RFR: Merge jdk18
Message-ID: <kDznDSRknZuL6_YIcikb_iYSWb9I_olD3_mZuM2tUrQ=.c3e92d60-0716-44af-ac9d-4c00675162bd@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18
 - 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
 - 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS
 - 8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64
 - 8278897: Alignment of heap segments is not enforced correctly
 - 8279222: Incorrect legacyMap.get in java.security.Provider after JDK-8276660
 - 8278948: compiler/vectorapi/reshape/TestVectorCastAVX1.java crashes in assembler

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6975&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6975&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6975/files
  Stats: 750 lines in 28 files changed: 687 ins; 8 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6975/head:pull/6975

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

From jwilhelm at openjdk.java.net  Thu Jan  6 01:30:25 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 6 Jan 2022 01:30:25 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <kDznDSRknZuL6_YIcikb_iYSWb9I_olD3_mZuM2tUrQ=.c3e92d60-0716-44af-ac9d-4c00675162bd@github.com>
References: <kDznDSRknZuL6_YIcikb_iYSWb9I_olD3_mZuM2tUrQ=.c3e92d60-0716-44af-ac9d-4c00675162bd@github.com>
Message-ID: <T3U1fecEM_kjFzm9hlfUE93R9wVvPXXg4_Bsay8Ppbk=.75dded0d-1b32-475e-8da1-3a6cd47fbac4@github.com>

On Thu, 6 Jan 2022 00:42:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 844dfb3a
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/844dfb3ab6a1d8b68ccdcc73726ee0f73cfcb3c8
Stats:     750 lines in 28 files changed: 687 ins; 8 del; 55 mod

Merge

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

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

From duke at openjdk.java.net  Thu Jan  6 03:13:18 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 6 Jan 2022 03:13:18 GMT
Subject: Withdrawn: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
Message-ID: <cOCP4itwDuqc2Ksiqe-HyU4A-xe4U8S2fu5xcwTRJxs=.be9f7049-59d3-411a-96a6-562e3b73418d@github.com>

On Wed, 29 Sep 2021 19:31:53 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the patch for JDK-8274524
> 
> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed

This pull request has been closed without being integrated.

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

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

From mullan at openjdk.java.net  Thu Jan  6 20:31:19 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 6 Jan 2022 20:31:19 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames
In-Reply-To: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
Message-ID: <af7C2TFYwcldrmahOFKvHuzVsmVmxJ1wAUJi9drMEMA=.cb6a9ccf-69fa-4748-9dea-dd1f8af2a9f1@github.com>

On Thu, 23 Dec 2021 11:59:18 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the JDK-8255739 bug fix?
> 
> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
> 
> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.

I understand the reasons for making the code more robust and detecting invalid DER encodings, but this may have a non-trivial compatibility risk. In general, I think detecting invalid encodings is generally the right thing to do, but compatibility needs to be considered. Sometimes other implementations have encoding bugs that we need to workaround, etc. This change affects not only certificates but other security components that use DER in the JDK. Certificates already treat non-critical extensions that are badly encoded as not a failure, so there is some compatibility built-in already. But I think it makes sense to look at other code that calls into the DerValue methods and evaluate the potential compatibility risk. At a minimum, a CSR must be filed. As a compromise, it may make sense to (at least initially) reduce the compatibility risk by allowing the caller (ex: `sun.security.x509.DNSName`) to decide if it wants a stricter parsing of the DER-encoded string.

I would like @wangweij or @valeriepeng to also review this. 

With respect to the test, it seems like overkill to launch a java process inside the test to run each test. Instead, I would just have separate methods for each test and run them in the same process as the main test.

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

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

From valeriep at openjdk.java.net  Thu Jan  6 20:33:13 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 6 Jan 2022 20:33:13 GMT
Subject: RFR: 8279520: SPNEGO has not passed channel binding info into the
 underlying mechanism
In-Reply-To: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
References: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
Message-ID: <FtQlgnXV5krXfvWTZOuxiLmnhtAmN60m0e1dEzcKGVc=.3b3a2c82-ae1e-43d6-8124-32c6659666ee@github.com>

On Wed, 5 Jan 2022 16:25:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

I will take a look.

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

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

From mullan at openjdk.java.net  Thu Jan  6 20:45:11 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 6 Jan 2022 20:45:11 GMT
Subject: RFR: 8279520: SPNEGO has not passed channel binding info into the
 underlying mechanism
In-Reply-To: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
References: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
Message-ID: <llBPI9G297TvgBkpJSsKjDa3jNSV8VBWAVvAz9Bzqvs=.7abe2aca-a80a-4b0b-97bf-b24979838bbf@github.com>

On Wed, 5 Jan 2022 16:25:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

Marked as reviewed by mullan (Reviewer).

src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoContext.java line 2:

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

2022 now :)

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

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

From valeriep at openjdk.java.net  Thu Jan  6 21:31:19 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 6 Jan 2022 21:31:19 GMT
Subject: RFR: 8279520: SPNEGO has not passed channel binding info into the
 underlying mechanism
In-Reply-To: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
References: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
Message-ID: <htiWzTRWrqaLSHnJsvH_VXj2AoVu0Ez0qFUAn25uAVk=.efff523a-c854-48d9-bec2-ff7f25cde1d6@github.com>

On Wed, 5 Jan 2022 16:25:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

Looks good. Thanks.

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

Marked as reviewed by valeriep (Reviewer).

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

From weijun at openjdk.java.net  Thu Jan  6 22:06:23 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 6 Jan 2022 22:06:23 GMT
Subject: Integrated: 8279520: SPNEGO has not passed channel binding info into
 the underlying mechanism
In-Reply-To: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
References: <mv8i-BO27AN79eu-JXCZO4Y_nI3loNz2qEGzArxbm_E=.9563a528-0e5e-41f1-96e1-eefa2b29db3f@github.com>
Message-ID: <8B2n3hl3A-gpVe9n6YXdjn1ksUFGXcW9TxL0p76-tE0=.2f5ae0ce-37e9-4df5-8962-a6acccc58861@github.com>

On Wed, 5 Jan 2022 16:25:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

This pull request has now been integrated.

Changeset: 8d0f385f
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8d0f385fd0243c3e38b400f463b8d9727b0a5956
Stats:     21 lines in 2 files changed: 8 ins; 0 del; 13 mod

8279520: SPNEGO has not passed channel binding info into the underlying mechanism

Reviewed-by: mullan, valeriep

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

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

From weijun at openjdk.java.net  Thu Jan  6 23:38:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 6 Jan 2022 23:38:10 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames
In-Reply-To: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
Message-ID: <9vDFZ8QDV0krEGC6BUkolH2I9Ce9MLxV8lpXpFyZOFQ=.933ee5fc-65e0-4b1e-aba7-b03f8face143@github.com>

On Thu, 23 Dec 2021 11:59:18 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the JDK-8255739 bug fix?
> 
> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
> 
> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.

The method modified has effect on all the string reading methods in `DerValue`. I wonder if this is worth doing. How harmful is this bug?

BTW, openssl seems to be reading them as UTF-8 strings:

    X509v3 Subject Alternative Name:
        DNS:?.com, DNS:K.com

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

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

From duke at openjdk.java.net  Fri Jan  7 05:16:19 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 7 Jan 2022 05:16:19 GMT
Subject: Withdrawn: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <yiliCDBKpkYdho_Ka45ADOFlWQQvBU3vquvJq3PPrRk=.4ca6855f-25e8-4616-b647-baa3c9efc330@github.com>

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

This pull request has been closed without being integrated.

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

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

From weijun at openjdk.java.net  Fri Jan  7 19:44:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 7 Jan 2022 19:44:49 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
Message-ID: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>

Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.

I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.

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

Commit messages:
 - 8279064: New options for ktab to provide non-default salt

Changes: https://git.openjdk.java.net/jdk/pull/6991/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6991&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279064
  Stats: 155 lines in 5 files changed: 135 ins; 1 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6991.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6991/head:pull/6991

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

From kevinw at openjdk.java.net  Fri Jan  7 20:28:33 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 7 Jan 2022 20:28:33 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed
In-Reply-To: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
Message-ID: <r78kPKX92bKhc73v2s6sCjM0T_m0oQiu4EiA8r8I8n4=.3537f4a1-fb0b-4734-bf12-03cb122cbdde@github.com>

On Wed, 22 Dec 2021 18:14:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
> 
> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
> ..as that is no longer needed.
> 
> Docs/man page update to follow (JDK-8278619).

Thanks for the comments - 

The proxy objects are needed in the filter for this to work at all.

The proxy names/numbers and innner class names/numbers are predictable and stable IF we are using jstatd and jstat as standalone programs.

But they are unstable if there is other relevant activity in the VM process, e.g. a JMX connection comes in before they are created.  We should wildcard the proxy names to work in such a situation:  com.sun.proxy.jdk.proxy*

I'll mention also that jstatd has always been an experimental feature.  The man page warns about lack of authentication and advises usage with caution.

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

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

From duke at openjdk.java.net  Fri Jan  7 20:44:32 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 7 Jan 2022 20:44:32 GMT
Subject: Withdrawn: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <z4SA_54KCcmaBAkkKa7TKnOMDA8_Pq1Dy_XdEkpE_CM=.3d264709-7b76-4549-9513-35db6cf161d5@github.com>

On Wed, 13 Oct 2021 22:04:23 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.java.net  Fri Jan  7 22:32:28 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 7 Jan 2022 22:32:28 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed
In-Reply-To: <3Z6pFX6xVhKhEjki2Hoyniz26-vYZNd4IfN7-xkzduc=.1ff636ec-749c-4ed7-8a9b-db206d4191e1@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <3Z6pFX6xVhKhEjki2Hoyniz26-vYZNd4IfN7-xkzduc=.1ff636ec-749c-4ed7-8a9b-db206d4191e1@github.com>
Message-ID: <_NWlPSNQtK6GcKiGYQ39-djPw03dFLT-RbaqKFwFY0A=.472e7c4a-9bf2-4062-8799-6a95cf6afdab@github.com>

On Wed, 22 Dec 2021 21:41:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 51:
> 
>> 49:     private static RemoteHost remoteHost;
>> 50: 
>> 51:     private static final String rmiFilterPattern = "sun.jvmstat.monitor.remote.RemoteVm;com.sun.proxy.jdk.proxy1.$Proxy1;com.sun.proxy.jdk.proxy1.$Proxy2;java.lang.reflect.Proxy;java.rmi.server.RemoteObjectInvocationHandler;java.rmi.server.RemoteObject;!*";
> 
> The class name of the dynamic proxy is generated at runtime and can be different.   As Bernd commented, the proxy classes cannot/should not be listed in the filter pattern.

@mlchung The Proxy class passed to the filter has been created in this VM from the interfaces listed.
The interfaces have already been filtered prior to creating the proxy.
The Proxy classes can safely be allowed based on a wildcard of the name. (As Stuart said).

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

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

From mbaesken at openjdk.java.net  Mon Jan 10 09:21:54 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 10 Jan 2022 09:21:54 GMT
Subject: [jdk18] RFR: 8278344:
 sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of
 different openssl output
Message-ID: <lkZDMrALv5zhaJcTdUqbwOTFI6sP06FzZNw7JK3jGtU=.cb9ae337-07c0-4303-8712-745ef019e225@github.com>

8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output

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

Commit messages:
 - Backport 8b5ff4bdffc8f32317d67b00c085071d6c772b30

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

PR: https://git.openjdk.java.net/jdk18/pull/90

From duke at openjdk.java.net  Mon Jan 10 11:08:26 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 11:08:26 GMT
Subject: RFR: 8275918: Remove unused local variables in java.base security
 code [v3]
In-Reply-To: <lTyLjRnAp4oVh9UC5ph0cAziFOdM798z-D3iBJrmldw=.b612e6ce-50f0-468a-93d7-436a45161161@github.com>
References: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
 <lTyLjRnAp4oVh9UC5ph0cAziFOdM798z-D3iBJrmldw=.b612e6ce-50f0-468a-93d7-436a45161161@github.com>
Message-ID: <VqWGZSKo2NPkga8Vm1yrhtm1IexDvoTqY_uCtgWfvTE=.65c16777-6ae1-48ac-a9a0-59e5719fadab@github.com>

On Wed, 27 Oct 2021 18:49:26 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Cleanup unused local variables. Looks like they are leftovers after refactoring.
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/master' into remove_unused_local_variables_java.base_security
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java
>  - 8275918: Remove unused local variables in java.base security code
>    remove local variable
>  - [PATCH] Remove unused local variables in java.base security code

@wangweij would you like to review latest changes?

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

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

From kevinw at openjdk.java.net  Mon Jan 10 11:17:12 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 10 Jan 2022 11:17:12 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
Message-ID: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>

> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
> 
> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
> ..as that is no longer needed.
> 
> Docs/man page update to follow (JDK-8278619).

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

  Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6919/files
  - new: https://git.openjdk.java.net/jdk/pull/6919/files/25ed85e7..e49b9fe2

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

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

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

From mbaesken at openjdk.java.net  Mon Jan 10 11:44:39 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 10 Jan 2022 11:44:39 GMT
Subject: [jdk18] Integrated: 8278344:
 sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of
 different openssl output
In-Reply-To: <lkZDMrALv5zhaJcTdUqbwOTFI6sP06FzZNw7JK3jGtU=.cb9ae337-07c0-4303-8712-745ef019e225@github.com>
References: <lkZDMrALv5zhaJcTdUqbwOTFI6sP06FzZNw7JK3jGtU=.cb9ae337-07c0-4303-8712-745ef019e225@github.com>
Message-ID: <rIUBpEBDnFOU3yc-MIiF4RXugQ4rdHkrODLyVHaFVy8=.2760a76c-aa34-4ebf-8676-c6c4374e97c4@github.com>

On Mon, 10 Jan 2022 09:09:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output

This pull request has now been integrated.

Changeset: 06b4d494
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/06b4d494bf7bfec7db83351f0df372cba2b22bae
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output

Backport-of: 8b5ff4bdffc8f32317d67b00c085071d6c772b30

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

PR: https://git.openjdk.java.net/jdk18/pull/90

From mbaesken at openjdk.java.net  Mon Jan 10 13:47:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 10 Jan 2022 13:47:58 GMT
Subject: [jdk18] RFR: 8279385: [test]  Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
Message-ID: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>

8279385: [test]  Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

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

Commit messages:
 - Backport 9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09

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

PR: https://git.openjdk.java.net/jdk18/pull/91

From olivier.cailloux at dauphine.fr  Mon Jan 10 14:22:24 2022
From: olivier.cailloux at dauphine.fr (Olivier Cailloux)
Date: Mon, 10 Jan 2022 15:22:24 +0100
Subject: JEP 411: sandboxing use case
Message-ID: <ab92b4affba37ad8f0f0dc0677e4a0e6e3253c84.camel@dauphine.fr>

Dear list,

I would like to share my use case for currently using the security
manager mechanism (SM) in my software. Now that JEP 411 is there, any
advice about any currently existing solution for replacement would be
welcome, if this is already possible; alternatively, I hope that a
replacement for these needs will be available soon.

My software grades student work. It download their code from GitHub,
compiles it, runs it, and observe the results (similar to running JUnit
tests, but on pluggable code). Their code is then graded automatically
depending on the expected versus actual results.

I currently use SM to prevent student code to alter the system on which
the code runs or have external impact. I don?t want them to read files
or send network requests (they usually do not need to do anything like
this for the exercices assigned to them). I currently use a simple ?no
priviledged calls at all? configuration, where everything that can be
forbidden by SM is forbidden for their code, as they only need to be
able to deal with their own objects and classes from the JDK that
operate ?taint-free? (as Chapman Flak puts it), such as classical List
or Set structures.

Though I do not currently need such more advanced feature, I considered
as a good bonus that SM allowed me, if I wanted to, to give exercices
that also deal with file writing (through telling SM that their code
can access a restricted set of files). If any replacement solution
could also allow this kind of flexibility, that would be nice.

I am aware that their code could implement a denial of service; I am
okay to live with this risk as any resulting damage would be low (worst
case, just restart the computer). But I?d like to reduce the risk that
their code would read or modify files or other aspects of the system it
is running on, for example, as the resulting damage could be much
higher (such as: alter the way the system works so that the grading of
other students, graded next, would be modified; read personal files
from the account that is running the grading software and posting their
content on the internet; inadvertently delete files on the host
system?)

I implement code isolation so that one student code does not see or
interact with the code of other students classical using class loader
mechanisms, for which JEP 411 does not create problems. But I ignore
how to prevent file writing, socket opening, or similar stuff, using
other means than SM.

My needs resemble (but are not identical to) the ones exposed by
Chapman Flack in ?JEP 411: Missing use-case: user functions in an
RDBMS?,?https://marc.info/?m=162216583127042. I share the concern of
this poster (https://marc.info/?m=162221303911911) that it currently
seems that I?d have to come up with various, specialized mechanisms to
prevent various kinds of operations (file system access, socket
access,??), which seems inelegant and error-prone.

Even after reading the insightful article of Ron Pressler, Shallow Java
Sandboxes
(https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/),
it is unclear to me whether I can get rid of SecurityManager with
existing Java 17 technology. Any advice would be welcome. If not
possible, please consider this use case when thinking about further
progress in replacing the security related APIs. (I am quite worried by
the wording of JEP 411 Future Work not mentioning this kind of
sandboxing need.)

Olivier



From weijun at openjdk.java.net  Mon Jan 10 14:59:37 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 10 Jan 2022 14:59:37 GMT
Subject: RFR: 8275918: Remove unused local variables in java.base security
 code [v3]
In-Reply-To: <lTyLjRnAp4oVh9UC5ph0cAziFOdM798z-D3iBJrmldw=.b612e6ce-50f0-468a-93d7-436a45161161@github.com>
References: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
 <lTyLjRnAp4oVh9UC5ph0cAziFOdM798z-D3iBJrmldw=.b612e6ce-50f0-468a-93d7-436a45161161@github.com>
Message-ID: <m_g9ECOMJIYctzy54Q9DkU7YN0kBvTtmQFGRNwnzslk=.2eefd671-fd59-42f9-8c1b-58c22f3939f6@github.com>

On Wed, 27 Oct 2021 18:49:26 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Cleanup unused local variables. Looks like they are leftovers after refactoring.
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/master' into remove_unused_local_variables_java.base_security
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java
>  - 8275918: Remove unused local variables in java.base security code
>    remove local variable
>  - [PATCH] Remove unused local variables in java.base security code

Sorry for the (super) late reply. Everything looks fine to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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

From duke at openjdk.java.net  Mon Jan 10 15:06:31 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 15:06:31 GMT
Subject: Integrated: 8274679: Remove unnecessary conversion to String in
 security code in java.base
In-Reply-To: <6dwlq8Qcojm7hEvmWW1AHyd-Ucs40xbvNZnW70uFnh0=.49999deb-c869-4da1-9904-f1e4ddd5b6e9@github.com>
References: <6dwlq8Qcojm7hEvmWW1AHyd-Ucs40xbvNZnW70uFnh0=.49999deb-c869-4da1-9904-f1e4ddd5b6e9@github.com>
Message-ID: <BPm-wvojSI5s4Ui0gqxeyBRyZ-2VOS2cf7gLCUz9fBw=.202590f3-860f-4fa3-b3ee-a0b574be0ab7@github.com>

On Sun, 3 Oct 2021 16:24:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway.

This pull request has now been integrated.

Changeset: debaa28e
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/debaa28e9c0bcb01d0551df907a851bd1e1c3e78
Stats:     55 lines in 14 files changed: 0 ins; 7 del; 48 mod

8274679: Remove unnecessary conversion to String in security code in java.base

Reviewed-by: weijun

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

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

From duke at openjdk.java.net  Mon Jan 10 16:24:36 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 16:24:36 GMT
Subject: Integrated: 8274809: Update java.base classes to use
 try-with-resources
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <zUqenIJUWBnOkQapzGOE8ULVPieCJki0F9iZjT3ZBQM=.0cba2db1-cd3f-4656-91fc-faa12bfbb3b5@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8274809: Update java.base classes to use try-with-resources

This pull request has now been integrated.

Changeset: dee447f8
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dee447f8ae788c6c1f6cd1e1fcb93faceab37b6c
Stats:     60 lines in 7 files changed: 2 ins; 40 del; 18 mod

8274809: Update java.base classes to use try-with-resources

Reviewed-by: mullan, alanb, dfuchs

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

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

From jwilhelm at openjdk.java.net  Mon Jan 10 17:10:40 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 10 Jan 2022 17:10:40 GMT
Subject: Integrated: Merge jdk18
Message-ID: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8274679: Remove unnecessary conversion to String in security code in java.base
 - 8142362: Lots of code duplication in Copy class
 - 8218857: Confusing overloads for os::open
 - 8183227: read/write APIs in class os shall return ssize_t
 - 8279300: [arm32] SIGILL when running GetObjectSizeIntrinsicsTest
 - 8278329: some TraceDeoptimization code not included in PRODUCT build
 - 8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc
 - 8279522: Serial: Remove unused Generation::clear_remembered_set
 - 8279528: Unused TypeEnter.diag after JDK-8205187
 - ... and 163 more: https://git.openjdk.java.net/jdk/compare/40df5df9...6ff1c607

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/7017/files
  Stats: 27994 lines in 750 files changed: 20678 ins; 5315 del; 2001 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7017/head:pull/7017

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

From jwilhelm at openjdk.java.net  Mon Jan 10 17:10:41 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 10 Jan 2022 17:10:41 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com>
References: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com>
Message-ID: <LWy6sTkBpk83budJQIqgEjCdEgq62d3JuxhZCubMyR0=.49c56cd4-a4b8-49f8-9bf0-00ebb2c874cf@github.com>

On Mon, 10 Jan 2022 17:00:05 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: d9b1bb58
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d9b1bb58600c03cee43387864d1530d4dd5f1422
Stats:     615 lines in 24 files changed: 478 ins; 77 del; 60 mod

Merge

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

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

From valeriep at openjdk.java.net  Mon Jan 10 18:41:35 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 10 Jan 2022 18:41:35 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
Message-ID: <5a9CLw8tSPe6sCl4TDN4yZec5A0eV4DU4VdjbVWr24M=.8e1e3589-c4d4-4a24-a377-48cd22640b81@github.com>

On Fri, 7 Jan 2022 19:35:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
> 
> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
> 
> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.

I will take a look. Thanks~

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

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

From weijun at openjdk.java.net  Tue Jan 11 20:42:42 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 11 Jan 2022 20:42:42 GMT
Subject: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases
 for OID format
Message-ID: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>

Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for.

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

Commit messages:
 - 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format

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

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

From weijun at openjdk.java.net  Tue Jan 11 20:45:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 11 Jan 2022 20:45:52 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
Message-ID: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>

Change the order so parent class is at the left.

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

Commit messages:
 - 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

Changes: https://git.openjdk.java.net/jdk/pull/7037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7037&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279800
  Stats: 106 lines in 12 files changed: 84 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7037/head:pull/7037

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

From sean.mullan at oracle.com  Tue Jan 11 21:49:00 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 11 Jan 2022 16:49:00 -0500
Subject: JEP 411: sandboxing use case
In-Reply-To: <ab92b4affba37ad8f0f0dc0677e4a0e6e3253c84.camel@dauphine.fr>
References: <ab92b4affba37ad8f0f0dc0677e4a0e6e3253c84.camel@dauphine.fr>
Message-ID: <75c3bb25-1894-325b-b4e7-3a37d32710bd@oracle.com>



On 1/10/22 9:22 AM, Olivier Cailloux wrote:
> Dear list,
> 
> I would like to share my use case for currently using the security
> manager mechanism (SM) in my software. Now that JEP 411 is there, any
> advice about any currently existing solution for replacement would be
> welcome, if this is already possible; alternatively, I hope that a
> replacement for these needs will be available soon.

You may want to consider container technologies. This is mentioned in 
the last paragraph of the Motivation section of JEP 411.

--Sean

> 
> My software grades student work. It download their code from GitHub,
> compiles it, runs it, and observe the results (similar to running JUnit
> tests, but on pluggable code). Their code is then graded automatically
> depending on the expected versus actual results.
> 
> I currently use SM to prevent student code to alter the system on which
> the code runs or have external impact. I don?t want them to read files
> or send network requests (they usually do not need to do anything like
> this for the exercices assigned to them). I currently use a simple ?no
> priviledged calls at all? configuration, where everything that can be
> forbidden by SM is forbidden for their code, as they only need to be
> able to deal with their own objects and classes from the JDK that
> operate ?taint-free? (as Chapman Flak puts it), such as classical List
> or Set structures.
> 
> Though I do not currently need such more advanced feature, I considered
> as a good bonus that SM allowed me, if I wanted to, to give exercices
> that also deal with file writing (through telling SM that their code
> can access a restricted set of files). If any replacement solution
> could also allow this kind of flexibility, that would be nice.
> 
> I am aware that their code could implement a denial of service; I am
> okay to live with this risk as any resulting damage would be low (worst
> case, just restart the computer). But I?d like to reduce the risk that
> their code would read or modify files or other aspects of the system it
> is running on, for example, as the resulting damage could be much
> higher (such as: alter the way the system works so that the grading of
> other students, graded next, would be modified; read personal files
> from the account that is running the grading software and posting their
> content on the internet; inadvertently delete files on the host
> system?)
> 
> I implement code isolation so that one student code does not see or
> interact with the code of other students classical using class loader
> mechanisms, for which JEP 411 does not create problems. But I ignore
> how to prevent file writing, socket opening, or similar stuff, using
> other means than SM.
> 
> My needs resemble (but are not identical to) the ones exposed by
> Chapman Flack in ?JEP 411: Missing use-case: user functions in an
> RDBMS?,?https://marc.info/?m=162216583127042. I share the concern of
> this poster (https://marc.info/?m=162221303911911) that it currently
> seems that I?d have to come up with various, specialized mechanisms to
> prevent various kinds of operations (file system access, socket
> access,??), which seems inelegant and error-prone.
> 
> Even after reading the insightful article of Ron Pressler, Shallow Java
> Sandboxes
> (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/),
> it is unclear to me whether I can get rid of SecurityManager with
> existing Java 17 technology. Any advice would be welcome. If not
> possible, please consider this use case when thinking about further
> progress in replacing the security related APIs. (I am quite worried by
> the wording of JEP 411 Future Work not mentioning this kind of
> sandboxing need.)
> 
> Olivier
> 
> 

From hchao at openjdk.java.net  Wed Jan 12 02:23:41 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 12 Jan 2022 02:23:41 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms that
 are disabled but have additional constraints
Message-ID: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>

`keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

Commit messages:
 - 8273236: keytool does not accurately warn about algorithms that are disabled but have additional constraints

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

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

From xuelei at openjdk.java.net  Wed Jan 12 05:53:25 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 12 Jan 2022 05:53:25 GMT
Subject: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have
 aliases for OID format
In-Reply-To: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
References: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
Message-ID: <TtlZVwcyjsQrRfR1mq_qFTKFK0AE9mmP0FMARkqNNV4=.430fdb0e-80bd-4bea-9556-dbced5d2d406@github.com>

On Tue, 11 Jan 2022 20:34:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for.

It is not obvious about the description "Add OID aliases for the 2 service", but I think I got the idea.  Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From xuelei at openjdk.java.net  Wed Jan 12 06:22:23 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 12 Jan 2022 06:22:23 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
Message-ID: <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>

On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change the order so parent class is at the left.

Hm, an interesting catch.  I have a concern, although.

src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 111:

> 109:     <T extends AlgorithmParameterSpec> T getParameterSpec(Class<T> paramSpec)
> 110:         throws InvalidParameterSpecException {
> 111:         if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {

The call to cast() is confusing.   But if the paramSpec is AlgorithmParameterSpec.class or Object.class, what's the expected behavior?  There are potential casting exception, I guess.  Maybe, a exactly class matching could be better.

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

Changes requested by xuelei (Reviewer).

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

From jjiang at openjdk.java.net  Wed Jan 12 07:04:42 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Wed, 12 Jan 2022 07:04:42 GMT
Subject: RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement
Message-ID: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>

In class `sun.security.ec.ECDHKeyAgreement.java`, the last `mod()` in the below line looks redundant,

BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);

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

Commit messages:
 - 8279903: Redundant modulo operation in ECDHKeyAgreement

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

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

From jjiang at openjdk.java.net  Wed Jan 12 07:29:04 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Wed, 12 Jan 2022 07:29:04 GMT
Subject: RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement [v2]
In-Reply-To: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>
References: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>
Message-ID: <5WrqYf7xD4pb689xGa3UtjaFuK6PnUWiE67D_-c4Hcs=.57a98e45-b83a-4ff0-97ca-4bd9cdf44a06@github.com>

> In class `sun.security.ec.ECDHKeyAgreement.java`, the last `mod()` in the below line looks redundant,
> 
> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);

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

  update copyright notes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7042/files
  - new: https://git.openjdk.java.net/jdk/pull/7042/files/4b44997f..6504ac3d

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

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

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

From peter.firmstone at zeus.net.au  Wed Jan 12 10:04:05 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 12 Jan 2022 20:04:05 +1000
Subject: JEP 411: sandboxing use case
In-Reply-To: <75c3bb25-1894-325b-b4e7-3a37d32710bd@oracle.com>
References: <ab92b4affba37ad8f0f0dc0677e4a0e6e3253c84.camel@dauphine.fr>
 <75c3bb25-1894-325b-b4e7-3a37d32710bd@oracle.com>
Message-ID: <19c3e57e-a0fa-97d7-5997-afeac0adab69@zeus.net.au>

Hi Olivier,

After JEP 421 (deprecation of finalizers) and a JEP is assigned to 
removal of finalizers, it will be possible to instrument java methods 
and intercept their calls.?? While finalizers exist, instrumenting 
constructors would allow finalizer attacks to circumvent the permission 
check.

OpenJDK has no intention of developing a new authorization framework / 
api.?? Until such time as finalizers are removed, SM is the only option 
currently available for authorization within the JVM.

You can make a JVM process less privileged, or sandbox a JVM within a 
VM, but if the JVM (without SM) is able to generate a students result, 
then student code will also be able to.?? I did consider briefly the 
possibility of using two processes, one for the student code (isolated 
in an unprivileged process or VM) and one for the grading code, but I 
think the grading jvm would be susceptible to some form of injection 
attack, as it has to parse untrusted data.

Be sure to disable Serialization, as SM doesn't prevent its use and any 
other forms of potentially dangerous data parsing.

-Djdk.serialFilter=!*,\

-Dcom.sun.jndi.ldap.object.trustSerialData=false,\

Regards,

Peter.


On 12/01/2022 7:49 am, Sean Mullan wrote:
>
>
> On 1/10/22 9:22 AM, Olivier Cailloux wrote:
>> Dear list,
>>
>> I would like to share my use case for currently using the security
>> manager mechanism (SM) in my software. Now that JEP 411 is there, any
>> advice about any currently existing solution for replacement would be
>> welcome, if this is already possible; alternatively, I hope that a
>> replacement for these needs will be available soon.
>
> You may want to consider container technologies. This is mentioned in 
> the last paragraph of the Motivation section of JEP 411.
>
> --Sean
>
>>
>> My software grades student work. It download their code from GitHub,
>> compiles it, runs it, and observe the results (similar to running JUnit
>> tests, but on pluggable code). Their code is then graded automatically
>> depending on the expected versus actual results.
>>
>> I currently use SM to prevent student code to alter the system on which
>> the code runs or have external impact. I don?t want them to read files
>> or send network requests (they usually do not need to do anything like
>> this for the exercices assigned to them). I currently use a simple ?no
>> priviledged calls at all? configuration, where everything that can be
>> forbidden by SM is forbidden for their code, as they only need to be
>> able to deal with their own objects and classes from the JDK that
>> operate ?taint-free? (as Chapman Flak puts it), such as classical List
>> or Set structures.
>>
>> Though I do not currently need such more advanced feature, I considered
>> as a good bonus that SM allowed me, if I wanted to, to give exercices
>> that also deal with file writing (through telling SM that their code
>> can access a restricted set of files). If any replacement solution
>> could also allow this kind of flexibility, that would be nice.
>>
>> I am aware that their code could implement a denial of service; I am
>> okay to live with this risk as any resulting damage would be low (worst
>> case, just restart the computer). But I?d like to reduce the risk that
>> their code would read or modify files or other aspects of the system it
>> is running on, for example, as the resulting damage could be much
>> higher (such as: alter the way the system works so that the grading of
>> other students, graded next, would be modified; read personal files
>> from the account that is running the grading software and posting their
>> content on the internet; inadvertently delete files on the host
>> system?)
>>
>> I implement code isolation so that one student code does not see or
>> interact with the code of other students classical using class loader
>> mechanisms, for which JEP 411 does not create problems. But I ignore
>> how to prevent file writing, socket opening, or similar stuff, using
>> other means than SM.
>>
>> My needs resemble (but are not identical to) the ones exposed by
>> Chapman Flack in ?JEP 411: Missing use-case: user functions in an
>> RDBMS?,?https://marc.info/?m=162216583127042. I share the concern of
>> this poster (https://marc.info/?m=162221303911911) that it currently
>> seems that I?d have to come up with various, specialized mechanisms to
>> prevent various kinds of operations (file system access, socket
>> access,??), which seems inelegant and error-prone.
>>
>> Even after reading the insightful article of Ron Pressler, Shallow Java
>> Sandboxes
>> (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/), 
>>
>> it is unclear to me whether I can get rid of SecurityManager with
>> existing Java 17 technology. Any advice would be welcome. If not
>> possible, please consider this use case when thinking about further
>> progress in replacing the security related APIs. (I am quite worried by
>> the wording of JEP 411 Future Work not mentioning this kind of
>> sandboxing need.)
>>
>> Olivier
>>
>>

From weijun at openjdk.java.net  Wed Jan 12 14:53:27 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 12 Jan 2022 14:53:27 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
Message-ID: <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>

On Wed, 12 Jan 2022 06:08:29 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Change the order so parent class is at the left.
>
> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 111:
> 
>> 109:     <T extends AlgorithmParameterSpec> T getParameterSpec(Class<T> paramSpec)
>> 110:         throws InvalidParameterSpecException {
>> 111:         if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {
> 
> The call to cast() is confusing.   But if the paramSpec is AlgorithmParameterSpec.class or Object.class, what's the expected behavior?  There are potential casting exception, I guess.  Maybe, a exactly class matching could be better.

If so, then the `if` block will be true and the spec object is casted to your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and it always succeeds.

This is exactly what I want to achieve. In fact, this bug and the other `getInstance(oid)` bug have the same root. I was trying to decode an algorithm identifier from its encoding. First, the encoding of the algorithm is in OID so `AlgorithmParameters.getInstance()` must support OID. Second, I want to get the spec from the parameters without knowing the algorithm name and the child `AlgorithmParametersSpec` class type, so `AlgorithmParameters::getParameterSpec` must support `AlgorithmParameterSpec.class` as the argument.

Otherwise, the program needs to know name and parameter spec type on all supported algorithms.

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

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

From weijun at openjdk.java.net  Wed Jan 12 17:16:28 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 12 Jan 2022 17:16:28 GMT
Subject: RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement [v2]
In-Reply-To: <5WrqYf7xD4pb689xGa3UtjaFuK6PnUWiE67D_-c4Hcs=.57a98e45-b83a-4ff0-97ca-4bd9cdf44a06@github.com>
References: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>
 <5WrqYf7xD4pb689xGa3UtjaFuK6PnUWiE67D_-c4Hcs=.57a98e45-b83a-4ff0-97ca-4bd9cdf44a06@github.com>
Message-ID: <8JKYTukNtb_d8PE72YCnFOowVGrMn76tJQLHrzzEqtE=.3698a287-9639-4f59-a08a-cbcb39687b0d@github.com>

On Wed, 12 Jan 2022 07:29:04 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> In class `sun.security.ec.ECDHKeyAgreement`, the last `mod()` in the below line looks redundant,
>> 
>> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);
>> 
>> I think this tiny change just be a code cleanup, so no test for it and label `noreg-cleanup` is added for this JBS issue.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright notes

Good catch. Looks good to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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

From valeriep at openjdk.java.net  Wed Jan 12 19:34:27 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 19:34:27 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
 <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
Message-ID: <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>

On Wed, 12 Jan 2022 14:50:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 111:
>> 
>>> 109:     <T extends AlgorithmParameterSpec> T getParameterSpec(Class<T> paramSpec)
>>> 110:         throws InvalidParameterSpecException {
>>> 111:         if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {
>> 
>> The call to cast() is confusing.   But if the paramSpec is AlgorithmParameterSpec.class or Object.class, what's the expected behavior?  There are potential casting exception, I guess.  Maybe, a exactly class matching could be better.
>
> If so, then the `if` block will be true and the spec object is casted to your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and it always succeeds.
> 
> This is exactly what I want to achieve. In fact, this bug and the other `getInstance(oid)` bug have the same root. I was trying to decode an algorithm identifier from its encoding. First, the encoding of the algorithm is in OID so `AlgorithmParameters.getInstance()` must support OID. Second, I want to get the spec from the parameters without knowing the algorithm name and the child `AlgorithmParametersSpec` class type, so `AlgorithmParameters::getParameterSpec` must support `AlgorithmParameterSpec.class` as the argument.
> 
> Otherwise, the program needs to know name and parameter spec type on all supported algorithms.

Interesting... In hindsight, the cast call sort of confirms that the intended ordering is the suggested one.

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

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

From valeriep at openjdk.java.net  Wed Jan 12 19:44:28 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 19:44:28 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
Message-ID: <AFwDIKRN6zSqOFs2WEwQCoGEKAmvBKVE8HF_y9aTON4=.858a1aa9-0849-4c41-8d07-1bf493b53833@github.com>

On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change the order so parent class is at the left.

test/jdk/java/security/spec/IsAssignableFromOrder.java line 72:

> 70:     static void test(String algorithm, AlgorithmParameterSpec spec,
> 71:             Class<? extends AlgorithmParameterSpec>... classes) throws Exception {
> 72:         var ap1 = AlgorithmParameters.getInstance(algorithm);

nit: Print out the algorithm which has been tested?

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

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

From weijun at openjdk.java.net  Wed Jan 12 19:49:30 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 12 Jan 2022 19:49:30 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <AFwDIKRN6zSqOFs2WEwQCoGEKAmvBKVE8HF_y9aTON4=.858a1aa9-0849-4c41-8d07-1bf493b53833@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <AFwDIKRN6zSqOFs2WEwQCoGEKAmvBKVE8HF_y9aTON4=.858a1aa9-0849-4c41-8d07-1bf493b53833@github.com>
Message-ID: <cIRlhf0-T5wVy0INdbGfO-ttPEf2b86T4tpxTN_8UP8=.d2c17829-1aad-4d63-aab0-cd190d068e44@github.com>

On Wed, 12 Jan 2022 19:41:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Change the order so parent class is at the left.
>
> test/jdk/java/security/spec/IsAssignableFromOrder.java line 72:
> 
>> 70:     static void test(String algorithm, AlgorithmParameterSpec spec,
>> 71:             Class<? extends AlgorithmParameterSpec>... classes) throws Exception {
>> 72:         var ap1 = AlgorithmParameters.getInstance(algorithm);
> 
> nit: Print out the algorithm which has been tested?

I can, but if an exception is thrown, I can find out which algorithm has a problem by looking at the line number.

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

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

From weijun at openjdk.java.net  Wed Jan 12 19:52:25 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 12 Jan 2022 19:52:25 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
 <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
 <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>
Message-ID: <wfLxDflBUGnwWcQN1VLXHJD1QhslpEQwDWs53idf79k=.b70e6cde-29a4-4603-8631-d75ba40b8476@github.com>

On Wed, 12 Jan 2022 19:31:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> If so, then the `if` block will be true and the spec object is casted to your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and it always succeeds.
>> 
>> This is exactly what I want to achieve. In fact, this bug and the other `getInstance(oid)` bug have the same root. I was trying to decode an algorithm identifier from its encoding. First, the encoding of the algorithm is in OID so `AlgorithmParameters.getInstance()` must support OID. Second, I want to get the spec from the parameters without knowing the algorithm name and the child `AlgorithmParametersSpec` class type, so `AlgorithmParameters::getParameterSpec` must support `AlgorithmParameterSpec.class` as the argument.
>> 
>> Otherwise, the program needs to know name and parameter spec type on all supported algorithms.
>
> Interesting... In hindsight, the cast call sort of confirms that the intended ordering is the suggested one.

The check ensures casting always succeeds. The fact that this has not been noticed for such a long time means everyone is using the exact subclass type when calling the method.

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

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

From valeriep at openjdk.java.net  Wed Jan 12 19:59:29 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 19:59:29 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <wfLxDflBUGnwWcQN1VLXHJD1QhslpEQwDWs53idf79k=.b70e6cde-29a4-4603-8631-d75ba40b8476@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
 <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
 <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>
 <wfLxDflBUGnwWcQN1VLXHJD1QhslpEQwDWs53idf79k=.b70e6cde-29a4-4603-8631-d75ba40b8476@github.com>
Message-ID: <QOaFQ0iE8GlztLWfE_2XkMmxj_DLEdLh9m97USL6aqc=.00d32dd0-5ce6-4a66-89f0-39623c49e833@github.com>

On Wed, 12 Jan 2022 19:49:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Interesting... In hindsight, the cast call sort of confirms that the intended ordering is the suggested one.
>
> The check ensures casting always succeeds. The fact that this has not been noticed for such a long time means everyone is using the exact subclass type when calling the method.

Right, I suppose so.

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

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

From valeriep at openjdk.java.net  Wed Jan 12 19:59:29 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 19:59:29 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <cIRlhf0-T5wVy0INdbGfO-ttPEf2b86T4tpxTN_8UP8=.d2c17829-1aad-4d63-aab0-cd190d068e44@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <AFwDIKRN6zSqOFs2WEwQCoGEKAmvBKVE8HF_y9aTON4=.858a1aa9-0849-4c41-8d07-1bf493b53833@github.com>
 <cIRlhf0-T5wVy0INdbGfO-ttPEf2b86T4tpxTN_8UP8=.d2c17829-1aad-4d63-aab0-cd190d068e44@github.com>
Message-ID: <qXR2qq2MQU9hDKwhD9dM5rrm9F91qUgJi7PKljFCXIk=.0619b600-02b5-4a4b-9849-f13165276898@github.com>

On Wed, 12 Jan 2022 19:45:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/java/security/spec/IsAssignableFromOrder.java line 72:
>> 
>>> 70:     static void test(String algorithm, AlgorithmParameterSpec spec,
>>> 71:             Class<? extends AlgorithmParameterSpec>... classes) throws Exception {
>>> 72:         var ap1 = AlgorithmParameters.getInstance(algorithm);
>> 
>> nit: Print out the algorithm which has been tested?
>
> I can, but if an exception is thrown, I can find out which algorithm has a problem by looking at the line number.

Yes, just thought that reporting the algorithm to the test output seems more informative. Otherwise, always have to dig out the source to find out what has been covered.

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

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

From valeriep at openjdk.java.net  Wed Jan 12 20:04:30 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 20:04:30 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <QOaFQ0iE8GlztLWfE_2XkMmxj_DLEdLh9m97USL6aqc=.00d32dd0-5ce6-4a66-89f0-39623c49e833@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
 <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
 <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>
 <wfLxDflBUGnwWcQN1VLXHJD1QhslpEQwDWs53idf79k=.b70e6cde-29a4-4603-8631-d75ba40b8476@github.com>
 <QOaFQ0iE8GlztLWfE_2XkMmxj_DLEdLh9m97USL6aqc=.00d32dd0-5ce6-4a66-89f0-39623c49e833@github.com>
Message-ID: <wr2JRtSAJmXM7PTndRXutPPjRfGDQ3FUIM_pQD-oaf4=.243fd473-34a7-4141-bfc1-7d3d189dd7a3@github.com>

On Wed, 12 Jan 2022 19:54:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> The check ensures casting always succeeds. The fact that this has not been noticed for such a long time means everyone is using the exact subclass type when calling the method.
>
> Right, I suppose so.

PBEKeyFactory.java, PBKDF2Core.java and PBKDF2HmacSHA1Factory.java also have isAssignableFrom() calls which seem backward. Perhaps covering them as well?

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

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

From xuelei at openjdk.java.net  Wed Jan 12 20:52:28 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 12 Jan 2022 20:52:28 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <wr2JRtSAJmXM7PTndRXutPPjRfGDQ3FUIM_pQD-oaf4=.243fd473-34a7-4141-bfc1-7d3d189dd7a3@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
 <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
 <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>
 <wfLxDflBUGnwWcQN1VLXHJD1QhslpEQwDWs53idf79k=.b70e6cde-29a4-4603-8631-d75ba40b8476@github.com>
 <QOaFQ0iE8GlztLWfE_2XkMmxj_DLEdLh9m97USL6aqc=.00d32dd0-5ce6-4a66-89f0-39623c49e833@github.com>
 <wr2JRtSAJmXM7PTndRXutPPjRfGDQ3FUIM_pQD-oaf4=.243fd473-34a7-4141-bfc1-7d3d189dd7a3@github.com>
Message-ID: <4WYr2ykNGplRF9oXAE2w9WR7VVq2iaUmVJh614tBlDs=.1969dddd-fed6-424d-94b3-68610933f477@github.com>

On Wed, 12 Jan 2022 20:01:10 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Right, I suppose so.
>
> PBEKeyFactory.java, PBKDF2Core.java and PBKDF2HmacSHA1Factory.java also have isAssignableFrom() calls which seem backward. Perhaps covering them as well?

> If so, then the `if` block will be true and the spec object is casted to your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and it always succeeds.
> 
> This is exactly what I want to achieve.

Unfortunately, there is a returned value that we cannot return an object of any class.

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

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

From xuelei at openjdk.java.net  Wed Jan 12 20:55:23 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 12 Jan 2022 20:55:23 GMT
Subject: RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement [v2]
In-Reply-To: <5WrqYf7xD4pb689xGa3UtjaFuK6PnUWiE67D_-c4Hcs=.57a98e45-b83a-4ff0-97ca-4bd9cdf44a06@github.com>
References: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>
 <5WrqYf7xD4pb689xGa3UtjaFuK6PnUWiE67D_-c4Hcs=.57a98e45-b83a-4ff0-97ca-4bd9cdf44a06@github.com>
Message-ID: <JNGRaWIpNM203AxEKPJZ7_a7dsELjPH1kjR5e3Z2SAE=.780b6ee7-1602-4931-bd58-4047614391fa@github.com>

On Wed, 12 Jan 2022 07:29:04 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> In class `sun.security.ec.ECDHKeyAgreement`, the last `mod()` in the below line looks redundant,
>> 
>> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);
>> 
>> I think this tiny change just be a code cleanup, so no test for it and label `noreg-cleanup` is added for this JBS issue.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright notes

Marked as reviewed by xuelei (Reviewer).

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

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

From valeriep at openjdk.java.net  Wed Jan 12 21:20:23 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 21:20:23 GMT
Subject: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have
 aliases for OID format
In-Reply-To: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
References: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
Message-ID: <YCbILvTX1zfJI7tU1MDdG4Wi1teDvZW0icfQOQSx4P4=.e044c2ea-97c8-46d8-87bb-9204b1d46a7a@github.com>

On Tue, 11 Jan 2022 20:34:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for.

src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 322:

> 320:          */
> 321:         putService(new ProviderServiceA(this, "KeyPairGenerator",
> 322:             "EC", "sun.security.ec.ECKeyPairGenerator", ATTRS));

How about the EllipticCurve alias? Are we dropping it?

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

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

From valeriep at openjdk.java.net  Wed Jan 12 21:25:25 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 Jan 2022 21:25:25 GMT
Subject: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have
 aliases for OID format
In-Reply-To: <YCbILvTX1zfJI7tU1MDdG4Wi1teDvZW0icfQOQSx4P4=.e044c2ea-97c8-46d8-87bb-9204b1d46a7a@github.com>
References: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
 <YCbILvTX1zfJI7tU1MDdG4Wi1teDvZW0icfQOQSx4P4=.e044c2ea-97c8-46d8-87bb-9204b1d46a7a@github.com>
Message-ID: <iQrzPlW7ja-9OtrBlvBIibPEAxcZYWAOiPLZ9VmgPsY=.b2cbd912-bda4-4dbc-9547-bc96472e5e1b@github.com>

On Wed, 12 Jan 2022 21:17:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for.
>
> src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 322:
> 
>> 320:          */
>> 321:         putService(new ProviderServiceA(this, "KeyPairGenerator",
>> 322:             "EC", "sun.security.ec.ECKeyPairGenerator", ATTRS));
> 
> How about the EllipticCurve alias? Are we dropping it?

Hmm, I searched various security docs such as SunEC provider and standard names, there is no mentioning of EllipticCurve alias. So probably ok to drop it.

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

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

From mullan at openjdk.java.net  Wed Jan 12 22:04:55 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 12 Jan 2022 22:04:55 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
Message-ID: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>

If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 

This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 

An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.

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

Commit messages:
 - Initial revision.

Changes: https://git.openjdk.java.net/jdk/pull/7056/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7056&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278851
  Stats: 263 lines in 3 files changed: 213 ins; 20 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7056.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7056/head:pull/7056

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

From weijun at openjdk.java.net  Wed Jan 12 22:40:09 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 12 Jan 2022 22:40:09 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards [v2]
In-Reply-To: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
Message-ID: <2ONRKYO_gjEpLUcB8t7aPFLhDqRQ5Y3-KsPpVfe_2P4=.2e97634c-a42d-48af-8c32-715da86a9394@github.com>

> Change the order so parent class is at the left.

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

  8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7037/files
  - new: https://git.openjdk.java.net/jdk/pull/7037/files/5dccd0ed..a5b20563

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

  Stats: 215 lines in 4 files changed: 33 ins; 167 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7037/head:pull/7037

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

From weijun at openjdk.java.net  Wed Jan 12 22:40:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 12 Jan 2022 22:40:10 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
Message-ID: <TcICZyjgJIbR7SrZNnFf4an9oDKhrvcHaQzUIl-rhDg=.fec7ea4f-95a7-49a2-99a3-1fe79427850b@github.com>

On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change the order so parent class is at the left.

New commit pushed. Turns out `PBKDF2HmacSHA1Factory.java` is useless now. The algorithm is now implemented as a sub-class of `PBKDF2Core`.

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

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

From xuelei at openjdk.java.net  Wed Jan 12 22:55:28 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 12 Jan 2022 22:55:28 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards [v2]
In-Reply-To: <2ONRKYO_gjEpLUcB8t7aPFLhDqRQ5Y3-KsPpVfe_2P4=.2e97634c-a42d-48af-8c32-715da86a9394@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <2ONRKYO_gjEpLUcB8t7aPFLhDqRQ5Y3-KsPpVfe_2P4=.2e97634c-a42d-48af-8c32-715da86a9394@github.com>
Message-ID: <RaNREDcv3iicZovtePJ9ffqfOjpnpZrQJH5q_Lf8DKQ=.1ca5f5e4-19f4-4e11-8652-0e60d8f44efe@github.com>

On Wed, 12 Jan 2022 22:40:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change the order so parent class is at the left.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

Marked as reviewed by xuelei (Reviewer).

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

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

From xuelei at openjdk.java.net  Wed Jan 12 22:55:29 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 12 Jan 2022 22:55:29 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards [v2]
In-Reply-To: <4WYr2ykNGplRF9oXAE2w9WR7VVq2iaUmVJh614tBlDs=.1969dddd-fed6-424d-94b3-68610933f477@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <5U5dNv4ZbJCGxP5ykuEUGHc5tF6M5qfIxJs0hBPC9eg=.b512b2d2-7dbd-45a8-b8b8-6cfd6bead555@github.com>
 <GZWgwwLCGg30wmwmB0wnflKW5xB1JXCyPh5Ilbh_AXA=.6d37b1a4-62f7-439d-b81c-84194f9bc23e@github.com>
 <BNe5aY7CnyLnxQVjcbjk7fyhknkCxCRAa6bAjR5k54c=.0e9afb78-9fa8-4f4e-8784-228621a1bf9d@github.com>
 <wfLxDflBUGnwWcQN1VLXHJD1QhslpEQwDWs53idf79k=.b70e6cde-29a4-4603-8631-d75ba40b8476@github.com>
 <QOaFQ0iE8GlztLWfE_2XkMmxj_DLEdLh9m97USL6aqc=.00d32dd0-5ce6-4a66-89f0-39623c49e833@github.com>
 <wr2JRtSAJmXM7PTndRXutPPjRfGDQ3FUIM_pQD-oaf4=.243fd473-34a7-4141-bfc1-7d3d189dd7a3@github.com>
 <4WYr2ykNGplRF9oXAE2w9WR7VVq2iaUmVJh614tBlDs=.1969dddd-fed6-424d-94b3-68610933f477@github.com>
Message-ID: <F6vVukGJaUTpp6ITkfFeC8H8FTVpMQuOT0ZTW5KpC14=.0b5abf3e-216e-4a13-b065-dd96c9d1b51d@github.com>

On Wed, 12 Jan 2022 20:49:13 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > If so, then the `if` block will be true and the spec object is casted to your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and it always succeeds.
> > This is exactly what I want to achieve.
> 
> Unfortunately, there is a returned value that we cannot return an object of any class.

Oh, I missed that the paramSpec should be of class T, which extends AlgorithmParameterSpec.  Then, I have no more concerns.

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

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

From valeriep at openjdk.java.net  Thu Jan 13 00:16:29 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 00:16:29 GMT
Subject: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have
 aliases for OID format
In-Reply-To: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
References: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
Message-ID: <ih2a31d1CdSSRGztgnBZ47kTNWvIZJjwh6Vwb-G1F7U=.5b94082b-7765-4761-8eab-6ac1e0a99896@github.com>

On Tue, 11 Jan 2022 20:34:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for.

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.java.net  Thu Jan 13 00:22:28 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 00:22:28 GMT
Subject: RFR: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards [v2]
In-Reply-To: <2ONRKYO_gjEpLUcB8t7aPFLhDqRQ5Y3-KsPpVfe_2P4=.2e97634c-a42d-48af-8c32-715da86a9394@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
 <2ONRKYO_gjEpLUcB8t7aPFLhDqRQ5Y3-KsPpVfe_2P4=.2e97634c-a42d-48af-8c32-715da86a9394@github.com>
Message-ID: <U8EOSyDN1O0kbxxUgsywWHkLTZDXlbTZwYTVktXnJTI=.a7563255-977b-4f10-8ccb-c24e9e288939@github.com>

On Wed, 12 Jan 2022 22:40:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change the order so parent class is at the left.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

Changes look good. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

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

From weijun at openjdk.java.net  Thu Jan 13 00:46:28 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 00:46:28 GMT
Subject: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have
 aliases for OID format
In-Reply-To: <iQrzPlW7ja-9OtrBlvBIibPEAxcZYWAOiPLZ9VmgPsY=.b2cbd912-bda4-4dbc-9547-bc96472e5e1b@github.com>
References: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
 <YCbILvTX1zfJI7tU1MDdG4Wi1teDvZW0icfQOQSx4P4=.e044c2ea-97c8-46d8-87bb-9204b1d46a7a@github.com>
 <iQrzPlW7ja-9OtrBlvBIibPEAxcZYWAOiPLZ9VmgPsY=.b2cbd912-bda4-4dbc-9547-bc96472e5e1b@github.com>
Message-ID: <KGoItQGYApdIDoaxTmBM2cWPSgrnZxOUb78KPM-A4Iw=.0cfb4c80-4bb0-4821-b302-a0bab2ae3177@github.com>

On Wed, 12 Jan 2022 21:22:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 322:
>> 
>>> 320:          */
>>> 321:         putService(new ProviderServiceA(this, "KeyPairGenerator",
>>> 322:             "EC", "sun.security.ec.ECKeyPairGenerator", ATTRS));
>> 
>> How about the EllipticCurve alias? Are we dropping it?
>
> Hmm, I searched various security docs such as SunEC provider and standard names, there is no mentioning of EllipticCurve alias. So probably ok to drop it.

Er, maybe I can add it into KnownOIDs? `EC("1.2.840.10045.2.1", "EC", "EllipticCurve")`.

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

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

From weijun at openjdk.java.net  Thu Jan 13 00:46:31 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 00:46:31 GMT
Subject: Integrated: 8279800: isAssignableFrom checks in
 AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
In-Reply-To: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
References: <xxnVFdrsa7loaiAqXHb2f3DYHLUNKOiB_eq1tHyqKq4=.03c1f078-279c-4610-80e4-af424d0eea18@github.com>
Message-ID: <36YJDfwIJ_iaumVxyZBcjdhcWM6ScI9BadWV7lEbnj8=.5f2c3dac-70eb-4aca-89f6-85ac772d1638@github.com>

On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change the order so parent class is at the left.

This pull request has now been integrated.

Changeset: cb250298
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb25029885b176be9ebbc84ac1a8ba71be96a6a7
Stats:     308 lines in 15 files changed: 117 ins; 167 del; 24 mod

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

Reviewed-by: xuelei, valeriep

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

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

From jjiang at openjdk.java.net  Thu Jan 13 02:21:24 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Thu, 13 Jan 2022 02:21:24 GMT
Subject: Integrated: 8279903: Redundant modulo operation in ECDHKeyAgreement
In-Reply-To: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>
References: <5Rq46QCpyB0JOcez-5whjXY_T4-GDFGaPjOirGOSs7w=.88ff3a3a-7b0f-448e-844a-29fc9e0d8540@github.com>
Message-ID: <dwVTgycM027dwv4K1bNtS5ep0pasLcZT7ILyomOtvLk=.bee4f650-5c75-4c9a-95e5-91121a73879d@github.com>

On Wed, 12 Jan 2022 06:57:45 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In class `sun.security.ec.ECDHKeyAgreement`, the last `mod()` in the below line looks redundant,
> 
> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);
> 
> I think this tiny change just be a code cleanup, so no test for it and label `noreg-cleanup` is added for this JBS issue.

This pull request has now been integrated.

Changeset: 48519480
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/485194805966e8dbb76473fa26276e5ba26d8097
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8279903: Redundant modulo operation in ECDHKeyAgreement

Reviewed-by: weijun, xuelei

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

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

From prappo at openjdk.java.net  Thu Jan 13 10:35:39 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 10:35:39 GMT
Subject: RFR: 8279918: Fix various doc typos
Message-ID: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>

- Most of the typos are of a trivial kind: missing whitespace.
- If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
- As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
- &#39; is an apostrophe, which does not require to be encoded.

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

Commit messages:
 - Initial commit

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

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

From kevinw at openjdk.java.net  Thu Jan 13 10:49:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 10:49:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - &#39; is an apostrophe, which does not require to be encoded.

src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:

> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
> 73:  * positions never occur before ignore characters.</p>

"before ignored characters"

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:04:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - &#39; is an apostrophe, which does not require to be encoded.

src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:

> 56:  * A JDBC driver implementation should use
> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of

While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
Similarly at line 81, 118, 151, 247, 277, 318, 354.

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

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

From prappo at openjdk.java.net  Thu Jan 13 11:04:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
Message-ID: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>

On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - &#39; is an apostrophe, which does not require to be encoded.
>
> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
> 
>> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
>> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
>> 73:  * positions never occur before ignore characters.</p>
> 
> "before ignored characters"

I believe it's the name of a concept, so I will leave it as is:

> There is one special substitution.  If the description defines a substitution called "<ignore>", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.

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

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

From prappo at openjdk.java.net  Thu Jan 13 11:07:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:07:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID: <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>

On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - &#39; is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
> 
>> 56:  * A JDBC driver implementation should use
>> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
>> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of
> 
> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
> Similarly at line 81, 118, 151, 247, 277, 318, 354.

I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:21:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:21:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

src/java.sql/share/classes/java/sql/Statement.java line 784:

> 782:      * statement returns a {@code ResultSet} object, the second argument
> 783:      * supplied to this method is not an
> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a

Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <pjHWjVnBclRVnojpj7BEIAYuSdlwTLMEkAYhI3iPovw=.6e4cd7fe-f085-4572-856d-44d6ecace75c@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Marked as reviewed by kevinw (Committer).

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
Message-ID: <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>

On Thu, 13 Jan 2022 11:04:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
>> 
>>> 56:  * A JDBC driver implementation should use
>>> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
>>> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of
>> 
>> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
>> Similarly at line 81, 118, 151, 247, 277, 318, 354.
>
> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.

OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
I'll leave it up to you. 8-)

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

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

From prappo at openjdk.java.net  Thu Jan 13 11:33:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:33:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
Message-ID: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>

On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/Statement.java line 784:
> 
>> 782:      * statement returns a {@code ResultSet} object, the second argument
>> 783:      * supplied to this method is not an
>> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a
> 
> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.

You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.

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

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

From lancea at openjdk.java.net  Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
 <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
Message-ID: <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>

On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.
>
> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
> I'll leave it up to you. 8-)

I think that can be a follow on clean up.

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

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

From lancea at openjdk.java.net  Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Overall this looks good, thanks for the clean up :-)

A few comments below

src/java.base/share/classes/java/io/DataInput.java line 496:

> 494:      * ceases. If the character {@code '\r'}
> 495:      * is encountered, it is discarded and, if
> 496:      * the following byte converts to the

The above is a bit confusing as it reads(same in ImageInputStream.java).  I think that that can be looked at later.

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

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

From lancea at openjdk.java.net  Thu Jan 13 11:46:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
Message-ID: <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>

On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.sql/share/classes/java/sql/Statement.java line 784:
>> 
>>> 782:      * statement returns a {@code ResultSet} object, the second argument
>>> 783:      * supplied to this method is not an
>>> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a
>> 
>> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.
>
> You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.

Yes an "or" is probably worthwhile to add.

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

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

From prappo at openjdk.java.net  Thu Jan 13 12:40:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 12:40:45 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
Message-ID: <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>

On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.

Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.

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

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

From coffeys at openjdk.java.net  Thu Jan 13 12:47:27 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 13 Jan 2022 12:47:27 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
Message-ID: <mA28YRSynQP5-ZMV9WyyF1sxb9LRo1pIWqgGCN3VDXM=.87f9435c-4f54-466b-94ae-8f2840db06a2@github.com>

On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
> 
> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
> 
> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.

src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212:

> 210: 
> 211:         CodeSigner[] entrySigners = sigFileSigners.get(name);
> 212:         Map<String, Boolean> permittedAlgs =

maybe permittedAlgsChecker as variable name ?  the Map contains both permitted and non-permitted algs.

src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239:

> 237: 
> 238:             // A non-disabled algorithm was used.
> 239:             disabledAlgs = false;

this usage doesn't seem right. I think it's always set to false no matter what algs are detected.

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

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

From mullan at openjdk.java.net  Thu Jan 13 13:45:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 13:45:30 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <GoTfQ0njQABWrD7SFvPbmOPuKBIMNKsS3jJHnHMZfDY=.b11b8d73-4c8b-4eb1-8078-33dcd70b013c@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

The change in the one security class (KeyStoreLoginModule) looks fine.

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

Marked as reviewed by mullan (Reviewer).

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

From prappo at openjdk.java.net  Thu Jan 13 13:51:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 13:51:34 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
 <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
Message-ID: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>

On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Yes an "or" is probably worthwhile to add.

I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:

* java/sql/Statement.java:59
* java/sql/Statement.java:85
* java/sql/Statement.java:346
* java/sql/Statement.java:524
* java/sql/Statement.java:745
* java/sql/Statement.java:814
* java/sql/Statement.java:860
* java/sql/Statement.java:913
* java/sql/Statement.java:962
* java/sql/Statement.java:1225
* java/sql/Statement.java:1269
* java/sql/Statement.java:1314

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

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

From mullan at openjdk.java.net  Thu Jan 13 13:59:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 13:59:30 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
In-Reply-To: <mA28YRSynQP5-ZMV9WyyF1sxb9LRo1pIWqgGCN3VDXM=.87f9435c-4f54-466b-94ae-8f2840db06a2@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <mA28YRSynQP5-ZMV9WyyF1sxb9LRo1pIWqgGCN3VDXM=.87f9435c-4f54-466b-94ae-8f2840db06a2@github.com>
Message-ID: <h95cd8u_pfGIx5CSvJWRicz_6a5IAMbYFUukfTXwFjA=.1d099f2f-232c-4a29-81e3-45f06dcec9db@github.com>

On Thu, 13 Jan 2022 12:33:53 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
>> 
>> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
>> 
>> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.
>
> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212:
> 
>> 210: 
>> 211:         CodeSigner[] entrySigners = sigFileSigners.get(name);
>> 212:         Map<String, Boolean> permittedAlgs =
> 
> maybe permittedAlgsChecker as variable name ?  the Map contains both permitted and non-permitted algs.

`Checker` sounds like it going to do something. But I agree the name could be better. I was mostly being consistent with the `permittedAlgs` variable in `SignatureFileVerifier`. Maybe `algsPermittedStatus`?

> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239:
> 
>> 237: 
>> 238:             // A non-disabled algorithm was used.
>> 239:             disabledAlgs = false;
> 
> this usage doesn't seem right. I think it's always set to false no matter what algs are detected.

If all algs are disabled, it will never get here, because it will either continue on line 231 or 234.

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

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

From prappo at openjdk.java.net  Thu Jan 13 14:01:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 14:01:04 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

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

  Additional typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7063/files
  - new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f

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

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

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

From weijun at openjdk.java.net  Thu Jan 13 15:30:38 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 15:30:38 GMT
Subject: Integrated: 8279801: EC KeyFactory and KeyPairGenerator do not have
 aliases for OID format
In-Reply-To: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
References: <tBK1DvE0aYqlpLgu9JY6-lk5Kwy-Yj6OBV5n94Imaic=.10dd899e-658d-4d3a-b8a4-31ed87a22000@github.com>
Message-ID: <WkP7d4vGdl24_B8FhEyZJ2Sb3WqiCS77-b4IYxaL5YQ=.c04cfc4f-0a93-4b35-b3a1-4d0cbcdaceb5@github.com>

On Tue, 11 Jan 2022 20:34:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for.

This pull request has now been integrated.

Changeset: 0a839b43
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a839b434b8454e22d6e5084af6e45cab3daa538
Stats:     52 lines in 2 files changed: 45 ins; 2 del; 5 mod

8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format

Reviewed-by: xuelei, valeriep

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

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

From coffeys at openjdk.java.net  Thu Jan 13 15:31:29 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 13 Jan 2022 15:31:29 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
Message-ID: <f1a5BFo9PStjh4f21RJKW4pbRHcR2ehw9UtWpZGYptQ=.22e9f37a-b3b9-43f0-b900-10de7fc1a144@github.com>

On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
> 
> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
> 
> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.

Marked as reviewed by coffeys (Reviewer).

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

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

From coffeys at openjdk.java.net  Thu Jan 13 15:31:29 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 13 Jan 2022 15:31:29 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
In-Reply-To: <h95cd8u_pfGIx5CSvJWRicz_6a5IAMbYFUukfTXwFjA=.1d099f2f-232c-4a29-81e3-45f06dcec9db@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <mA28YRSynQP5-ZMV9WyyF1sxb9LRo1pIWqgGCN3VDXM=.87f9435c-4f54-466b-94ae-8f2840db06a2@github.com>
 <h95cd8u_pfGIx5CSvJWRicz_6a5IAMbYFUukfTXwFjA=.1d099f2f-232c-4a29-81e3-45f06dcec9db@github.com>
Message-ID: <nddYptgS61TSqYoG1To0yX4d1qeACqpQtZznI-CjtM8=.4ae145c6-9507-4c01-9182-d282da3b0809@github.com>

On Thu, 13 Jan 2022 13:56:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212:
>> 
>>> 210: 
>>> 211:         CodeSigner[] entrySigners = sigFileSigners.get(name);
>>> 212:         Map<String, Boolean> permittedAlgs =
>> 
>> maybe permittedAlgsChecker as variable name ?  the Map contains both permitted and non-permitted algs.
>
> `Checker` sounds like it going to do something. But I agree the name could be better. I was mostly being consistent with the `permittedAlgs` variable in `SignatureFileVerifier`. Maybe `algsPermittedStatus`?

yes, algsPermittedStatus sounds better. Thanks.

>> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239:
>> 
>>> 237: 
>>> 238:             // A non-disabled algorithm was used.
>>> 239:             disabledAlgs = false;
>> 
>> this usage doesn't seem right. I think it's always set to false no matter what algs are detected.
>
> If all algs are disabled, it will never get here, because it will either continue on line 231 or 234.

Ah yes - I was reading the scope of for loop incorrectly. Thanks for clarifying!

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

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

From sspitsyn at openjdk.java.net  Thu Jan 13 16:53:27 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 13 Jan 2022 16:53:27 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <Ibur44h4Co3CBFiirsNKloOUVl2G0KUC1pCEbFz5DII=.80447fd1-effd-4cba-9d5c-572ebcf12e72@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Hi Pavel,
Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From weijun at openjdk.java.net  Thu Jan 13 16:58:27 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 16:58:27 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
Message-ID: <oEPz71NOz4RlCuPXNvny7nQ1_VCCZE86m7rUv2Ilu14=.5b28f41e-c1e8-4eee-90f9-caac0095416a@github.com>

On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
> 
> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
> 
> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.

src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 211:

> 209:         }
> 210: 
> 211:         CodeSigner[] entrySigners = sigFileSigners.get(name);

What if we return here if `entrySigners == null`? It seems the hash comparison will be skipped, but at the end there is no difference in `verifiedSigners`.

src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 230:

> 228:                         params = new JarConstraintsParameters(entrySigners);
> 229:                     }
> 230:                     if (!checkConstraints(digestAlg, permittedAlgs, params)) {

Can we move the `permittedAlgs::put` call from inside the `checkConstraints` method to here? You can even call `computeIfAbsent` to make the intention clearer.

src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 272:

> 270:     }
> 271: 
> 272:     // Gets the permitted algs for the signers of this entry.

This can probably be another `computeIfAbsent`.

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

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

From lancea at openjdk.java.net  Thu Jan 13 17:18:23 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:18:23 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
 <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>
Message-ID: <irVQg_VsXH7St95vPZp8vVD3oaWCefUdqLxDETFhN5I=.ebbbb6d8-eba8-4e17-996d-32ffb15716f3@github.com>

On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.
> 
> Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.

Yes I am.  It just does not flow as well as it could IMHO

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

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

From naoto at openjdk.java.net  Thu Jan 13 17:25:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
 <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
Message-ID: <4-d5YVHaRmPcyMlFYm2fxtIaRq6Z5PVooC8yd0OIbag=.cbd015b1-b2bd-43ba-b12f-8727087364b5@github.com>

On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
>> 
>>> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
>>> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
>>> 73:  * positions never occur before ignore characters.</p>
>> 
>> "before ignored characters"
>
> I believe it's the name of a concept, so I will leave it as is:
> 
>> There is one special substitution.  If the description defines a substitution called "<ignore>", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.

Yes, that is correct.

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

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

From naoto at openjdk.java.net  Thu Jan 13 17:25:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:30 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <CmrsmcEGepottkt6pPurYZ3cPdM7oK7v1DInHe5jqbQ=.d9dd81e5-18b2-4e2c-9881-97d586442a35@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by naoto (Reviewer).

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

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

From lancea at openjdk.java.net  Thu Jan 13 17:25:31 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
 <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
 <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
Message-ID: <-4rLp_8_PwigKKpD1gGONCS8QMfDkNNNP4uZU1k9u9M=.9119e3bf-b879-42eb-a3a7-af6442a0551e@github.com>

On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > Yes an "or" is probably worthwhile to add.
> 
> I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:
> 
> * java/sql/Statement.java:59
> * java/sql/Statement.java:85
> * java/sql/Statement.java:346
> * java/sql/Statement.java:524
> * java/sql/Statement.java:745
> * java/sql/Statement.java:814
> * java/sql/Statement.java:860
> * java/sql/Statement.java:913
> * java/sql/Statement.java:962
> * java/sql/Statement.java:1225
> * java/sql/Statement.java:1269
> * java/sql/Statement.java:1314

I am fine with that.  I guess a semi-colon could also be used vs. a comma to divide the Exception scenarios listed

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

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

From lancea at openjdk.java.net  Thu Jan 13 17:35:25 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:35:25 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <wFh5PNvl7A_Oui3iDHyjFGEYyurAzJmGjVKD2bEF1tg=.e962af55-7886-4678-8a7b-39d1a695ae22@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by lancea (Reviewer).

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

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

From valeriep at openjdk.java.net  Thu Jan 13 19:21:28 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 19:21:28 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
Message-ID: <Gr_E_x5LjFz7DqAcdkFYb3DwBedWclfErnmujQ1eNm4=.189dcc47-c43c-4396-bca8-4e75126e215a@github.com>

On Fri, 7 Jan 2022 19:35:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
> 
> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
> 
> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.

I added myself to the CSR as reviewer. Made minor edits, re-ordered the command line option ordering based on the ordering mentioned in the description.

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

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

From valeriep at openjdk.java.net  Thu Jan 13 19:56:24 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 19:56:24 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
Message-ID: <qzvrDISZDI7DiMwdrBm6P73BiErGKDIZ8WnK7ZXXT3U=.63afdcc0-a191-4895-9dab-5aaa0c714486@github.com>

On Fri, 7 Jan 2022 19:35:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
> 
> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
> 
> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.

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

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

2022

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

> 455:         System.out.println("-l [-e] [-t]\n"
> 456:                 + "    list the keytab name and entries. -e with etype, -t with timestamp.");
> 457:         System.out.println("-a <principal name> [<password>] [-s <salt>] [-n <kvno>] [-f | -s <salt>] [-append]\n"

The first [-s <salt\>] looks redundant? Hmm, I edited your CSR from [-s <salt\>] to [-s <salt\> | -f]. Maybe you want to change that to be consistent with what you have here.

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

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

From valeriep at openjdk.java.net  Thu Jan 13 19:56:25 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 19:56:25 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <qzvrDISZDI7DiMwdrBm6P73BiErGKDIZ8WnK7ZXXT3U=.63afdcc0-a191-4895-9dab-5aaa0c714486@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <qzvrDISZDI7DiMwdrBm6P73BiErGKDIZ8WnK7ZXXT3U=.63afdcc0-a191-4895-9dab-5aaa0c714486@github.com>
Message-ID: <a3pVHV9S-6uKFvnzpNtUL-DV-6PZCIbibqeLq6jhYA8=.98f3181a-6fa0-4613-b82c-02185faf2e47@github.com>

On Thu, 13 Jan 2022 19:51:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
>> 
>> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
>> 
>> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.
>
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> 2022

Same goes for sun/security/krb5/internal/ktab/KeyTab.java.

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

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

From mullan at openjdk.java.net  Thu Jan 13 20:03:25 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 20:03:25 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs
In-Reply-To: <oEPz71NOz4RlCuPXNvny7nQ1_VCCZE86m7rUv2Ilu14=.5b28f41e-c1e8-4eee-90f9-caac0095416a@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <oEPz71NOz4RlCuPXNvny7nQ1_VCCZE86m7rUv2Ilu14=.5b28f41e-c1e8-4eee-90f9-caac0095416a@github.com>
Message-ID: <H-iib-gOWhvn2L-ZNlCxxe0uJHexazY3WGg1BEsF8nk=.c398faa7-67fd-417e-a264-f1791307eb03@github.com>

On Thu, 13 Jan 2022 16:55:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
>> 
>> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
>> 
>> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.
>
> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 211:
> 
>> 209:         }
>> 210: 
>> 211:         CodeSigner[] entrySigners = sigFileSigners.get(name);
> 
> What if we return here if `entrySigners == null`? It seems the hash comparison will be skipped, but at the end there is no difference in `verifiedSigners`.

The algorithm constraints check will be skipped (because `permittedAlgs` will be `null`) but the hash check will not be skipped.

I don't think `null` would be returned in a normal case. The only case I can think of is if there was an entry in the Manifest, but no corresponding entry in the SF file.  I suppose we could still do a constraints check as if there were no signers. However, it doesn't seem that useful since technically the entry is not protected by the signature and the hash check is still done, unless I am missing something.

> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 230:
> 
>> 228:                         params = new JarConstraintsParameters(entrySigners);
>> 229:                     }
>> 230:                     if (!checkConstraints(digestAlg, permittedAlgs, params)) {
> 
> Can we move the `permittedAlgs::put` call from inside the `checkConstraints` method to here? You can even call `computeIfAbsent` to make the intention clearer.

Yes, I can do that. However, I'm a bit wary of using lambdas in this code which may get exercised early in app startup. WDYT?

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

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

From valeriep at openjdk.java.net  Thu Jan 13 20:09:34 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 20:09:34 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <x03bUof0DoOqMOYt6-XK4jVKi4-yLq1XFDjUV01ClEg=.763f1543-241a-4089-a13b-ea22f8b0391c@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <x03bUof0DoOqMOYt6-XK4jVKi4-yLq1XFDjUV01ClEg=.763f1543-241a-4089-a13b-ea22f8b0391c@github.com>
Message-ID: <jSziHkPhknrvSKjiGrBXmfY89qkDrk-HCD2tdVULiaQ=.53c6cb28-0485-4de8-8991-c7e29d3010eb@github.com>

On Thu, 13 Jan 2022 20:06:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
>> 
>> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
>> 
>> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.
>
> test/jdk/sun/security/krb5/auto/tools/KtabSalt.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> 2022

Same goes for test/jdk/sun/security/krb5/auto/Context.java.

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

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

From valeriep at openjdk.java.net  Thu Jan 13 20:09:34 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 20:09:34 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
Message-ID: <x03bUof0DoOqMOYt6-XK4jVKi4-yLq1XFDjUV01ClEg=.763f1543-241a-4089-a13b-ea22f8b0391c@github.com>

On Fri, 7 Jan 2022 19:35:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
> 
> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
> 
> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.

test/jdk/sun/security/krb5/auto/tools/KtabSalt.java line 2:

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

2022

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

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

From valeriep at openjdk.java.net  Thu Jan 13 20:29:29 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 20:29:29 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <jSziHkPhknrvSKjiGrBXmfY89qkDrk-HCD2tdVULiaQ=.53c6cb28-0485-4de8-8991-c7e29d3010eb@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <x03bUof0DoOqMOYt6-XK4jVKi4-yLq1XFDjUV01ClEg=.763f1543-241a-4089-a13b-ea22f8b0391c@github.com>
 <jSziHkPhknrvSKjiGrBXmfY89qkDrk-HCD2tdVULiaQ=.53c6cb28-0485-4de8-8991-c7e29d3010eb@github.com>
Message-ID: <C87XohbdLzch32htlUs-7Vt-SJTMsLFW6OfdSgRmKrM=.4494ae21-08b4-4b88-a169-b8488374d17f@github.com>

On Thu, 13 Jan 2022 20:07:30 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> test/jdk/sun/security/krb5/auto/tools/KtabSalt.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>> 
>> 2022
>
> Same goes for test/jdk/sun/security/krb5/auto/Context.java.

And test/jdk/sun/security/krb5/tools/KtabCheck.java.

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

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

From mullan at openjdk.java.net  Thu Jan 13 21:35:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 21:35:30 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <LmrGR5tsT3fv0Ftg8aS6hYGbQJPCgX4UX9LPhFXkeB0=.0ed97028-2956-48ed-876e-7a39abeb12eb@github.com>

On Wed, 12 Jan 2022 02:15:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

Some comments so far. Will continue reviewing later.

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

> 185:     private List<String> weakWarnings = new ArrayList<>();
> 186: 
> 187:     Set<X509Certificate> trustedCerts = new HashSet<>();

Make private.

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

> 1127:         }
> 1128: 
> 1129:         buildTrustedCerts();

Can we reuse the keystore loaded by `buildTrustedCerts()` instead of reloading it again on line 1138?

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

> 1556:         checkWeakConstraint(rb.getString("the.issuer"),
> 1557:                 keyStore.getCertificateChain(alias));
> 1558:         cpcp = new CertPathConstraintsParameters(cert, null, null, null);

You could also specify the variant parameter if the certificate contains an EKU extension. The mapping from EKU to variant would be:

- anyExtendedKeyUsage -> VAR_GENERIC
- serverAuth -> VAR_TLS_SERVER
- clientAuth -> VAR_TLS_CLIENT
- codeSigning -> VAR_CODE_SIGNING
- emailProtection -> none defined, so just use null or VAR_GENERIC
- timeStamping -> VAR_TSA_SERVER
- OCSPSigning -> none defined, so just use null or VAR_GENERIC

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

> 1704:         }
> 1705:         dumpCert(cert, out);
> 1706:         CertPathConstraintsParameters cpcp =

Here you could also specify the variant if the cert contains an EKU extension. Same comment applies to other places where you are checking the algorithm constraints of a certificate.

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

> 5037:                         trustedCerts.add((X509Certificate)caks.getCertificate(a));
> 5038:                     } catch (Exception e2) {
> 5039:                         // ignore, when a SecretkeyEntry does not include a cert

Not sure I understand this comment, as these should not be SecretKeyEntries. You should still ignore it but this should not throw an Exception unless the KeyStore was not loaded/initialized properly (which normally won't occur).

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

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

From weijun at openjdk.java.net  Thu Jan 13 21:40:16 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 21:40:16 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
 [v2]
In-Reply-To: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
Message-ID: <-hQ-NPEvJzH4e8lW7uzhEeDFyzuWMu2z1DHK81S7Kq4=.cfe3a130-8c81-4d80-accb-e1ba2f980645@github.com>

> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
> 
> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
> 
> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.

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

  duplicate words, and another year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6991/files
  - new: https://git.openjdk.java.net/jdk/pull/6991/files/e85a20a3..59e2002a

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

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

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

From weijun at openjdk.java.net  Thu Jan 13 21:40:18 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 21:40:18 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
 [v2]
In-Reply-To: <a3pVHV9S-6uKFvnzpNtUL-DV-6PZCIbibqeLq6jhYA8=.98f3181a-6fa0-4613-b82c-02185faf2e47@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <qzvrDISZDI7DiMwdrBm6P73BiErGKDIZ8WnK7ZXXT3U=.63afdcc0-a191-4895-9dab-5aaa0c714486@github.com>
 <a3pVHV9S-6uKFvnzpNtUL-DV-6PZCIbibqeLq6jhYA8=.98f3181a-6fa0-4613-b82c-02185faf2e47@github.com>
Message-ID: <dL3BXw2bA0QXCuAemIvJ6uYjJVNtsUK1fqiYk88_TEs=.fab982d1-9b60-45f9-b628-003470d1d55a@github.com>

On Thu, 13 Jan 2022 19:52:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2003, 2021, Oracle and/or its affiliates. All rights reserved.
>> 
>> 2022
>
> Same goes for sun/security/krb5/internal/ktab/KeyTab.java.

Yes.

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

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

From weijun at openjdk.java.net  Thu Jan 13 21:40:20 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 21:40:20 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
 [v2]
In-Reply-To: <qzvrDISZDI7DiMwdrBm6P73BiErGKDIZ8WnK7ZXXT3U=.63afdcc0-a191-4895-9dab-5aaa0c714486@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <qzvrDISZDI7DiMwdrBm6P73BiErGKDIZ8WnK7ZXXT3U=.63afdcc0-a191-4895-9dab-5aaa0c714486@github.com>
Message-ID: <bcFnEEZg89x_6tv-zvEXLn59QexKxqP5Im_DjLts2TE=.bb9ab361-b733-40ae-93ae-a0c1a0a3efaf@github.com>

On Thu, 13 Jan 2022 19:45:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   duplicate words, and another year
>
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 457:
> 
>> 455:         System.out.println("-l [-e] [-t]\n"
>> 456:                 + "    list the keytab name and entries. -e with etype, -t with timestamp.");
>> 457:         System.out.println("-a <principal name> [<password>] [-s <salt>] [-n <kvno>] [-f | -s <salt>] [-append]\n"
> 
> The first [-s <salt\>] looks redundant? Hmm, I edited your CSR from [-s <salt\>] to [-s <salt\> | -f]. Maybe you want to change that to be consistent with what you have here.

Oops, no idea why I typed twice. Thanks for fixing the CSR.

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

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

From weijun at openjdk.java.net  Thu Jan 13 21:40:22 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 21:40:22 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
 [v2]
In-Reply-To: <C87XohbdLzch32htlUs-7Vt-SJTMsLFW6OfdSgRmKrM=.4494ae21-08b4-4b88-a169-b8488374d17f@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <x03bUof0DoOqMOYt6-XK4jVKi4-yLq1XFDjUV01ClEg=.763f1543-241a-4089-a13b-ea22f8b0391c@github.com>
 <jSziHkPhknrvSKjiGrBXmfY89qkDrk-HCD2tdVULiaQ=.53c6cb28-0485-4de8-8991-c7e29d3010eb@github.com>
 <C87XohbdLzch32htlUs-7Vt-SJTMsLFW6OfdSgRmKrM=.4494ae21-08b4-4b88-a169-b8488374d17f@github.com>
Message-ID: <IZ7ggUP8vIvA4h2md0VcTv7GNWHIagzccs5ZK_EFOmA=.bb0d9a58-5071-4a7a-8e68-691a56b8856c@github.com>

On Thu, 13 Jan 2022 20:26:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Same goes for test/jdk/sun/security/krb5/auto/Context.java.
>
> And test/jdk/sun/security/krb5/tools/KtabCheck.java.

Yes.

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

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

From mullan at openjdk.java.net  Thu Jan 13 21:57:57 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 21:57:57 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs [v2]
In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
Message-ID: <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com>

> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
> 
> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
> 
> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.

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

  Change permittedAlgs variable name.
  Move put methods out of checkConstraints().

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7056/files
  - new: https://git.openjdk.java.net/jdk/pull/7056/files/056bcff2..b551c2b9

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

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

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

From weijun at openjdk.java.net  Thu Jan 13 21:57:59 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 21:57:59 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs [v2]
In-Reply-To: <H-iib-gOWhvn2L-ZNlCxxe0uJHexazY3WGg1BEsF8nk=.c398faa7-67fd-417e-a264-f1791307eb03@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <oEPz71NOz4RlCuPXNvny7nQ1_VCCZE86m7rUv2Ilu14=.5b28f41e-c1e8-4eee-90f9-caac0095416a@github.com>
 <H-iib-gOWhvn2L-ZNlCxxe0uJHexazY3WGg1BEsF8nk=.c398faa7-67fd-417e-a264-f1791307eb03@github.com>
Message-ID: <2kBoENEx_JzUsnIL-f5vYIT6PpK11powOukSPBMWNYo=.8a576051-bd65-495f-bf98-10dbfc10e272@github.com>

On Thu, 13 Jan 2022 19:54:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 211:
>> 
>>> 209:         }
>>> 210: 
>>> 211:         CodeSigner[] entrySigners = sigFileSigners.get(name);
>> 
>> What if we return here if `entrySigners == null`? It seems the hash comparison will be skipped, but at the end there is no difference in `verifiedSigners`.
>
> The algorithm constraints check will be skipped (because `permittedAlgs` will be `null`) but the hash check will not be skipped.
> 
> I don't think `null` would be returned in a normal case. The only case I can think of is if there was an entry in the Manifest, but no corresponding entry in the SF file.  I suppose we could still do a constraints check as if there were no signers. However, it doesn't seem that useful since technically the entry is not protected by the signature and the hash check is still done, unless I am missing something.

Or maybe the key/signature algorithm is weak and ignored. I was only thinking it's not worth calculating the hash anymore. Of course there will be a behavior change. If there's a hash mismatch, it used to be a security exception, but if ignored, it's just a plain unsigned entry.

>> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 230:
>> 
>>> 228:                         params = new JarConstraintsParameters(entrySigners);
>>> 229:                     }
>>> 230:                     if (!checkConstraints(digestAlg, permittedAlgs, params)) {
>> 
>> Can we move the `permittedAlgs::put` call from inside the `checkConstraints` method to here? You can even call `computeIfAbsent` to make the intention clearer.
>
> Yes, I can do that. However, I'm a bit wary of using lambdas in this code which may get exercised early in app startup. WDYT?

Maybe, I don't know how problematic if lambda is used this early.

Anyway, I still prefer moving the update of `permittedAlgs` here. Updating it inside the method seems too faraway.

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

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

From mullan at openjdk.java.net  Thu Jan 13 22:18:29 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 22:18:29 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs [v2]
In-Reply-To: <2kBoENEx_JzUsnIL-f5vYIT6PpK11powOukSPBMWNYo=.8a576051-bd65-495f-bf98-10dbfc10e272@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <oEPz71NOz4RlCuPXNvny7nQ1_VCCZE86m7rUv2Ilu14=.5b28f41e-c1e8-4eee-90f9-caac0095416a@github.com>
 <H-iib-gOWhvn2L-ZNlCxxe0uJHexazY3WGg1BEsF8nk=.c398faa7-67fd-417e-a264-f1791307eb03@github.com>
 <2kBoENEx_JzUsnIL-f5vYIT6PpK11powOukSPBMWNYo=.8a576051-bd65-495f-bf98-10dbfc10e272@github.com>
Message-ID: <mrkWfe1R0sxeYdVIBsX45nhMoSJxyk6tXHO2h-NKcww=.95899d7f-796e-4340-ab63-8a612c8796e5@github.com>

On Thu, 13 Jan 2022 21:54:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The algorithm constraints check will be skipped (because `permittedAlgs` will be `null`) but the hash check will not be skipped.
>> 
>> I don't think `null` would be returned in a normal case. The only case I can think of is if there was an entry in the Manifest, but no corresponding entry in the SF file.  I suppose we could still do a constraints check as if there were no signers. However, it doesn't seem that useful since technically the entry is not protected by the signature and the hash check is still done, unless I am missing something.
>
> Or maybe the key/signature algorithm is weak and ignored. I was only thinking it's not worth calculating the hash anymore. Of course there will be a behavior change. If there's a hash mismatch, it used to be a security exception, but if ignored, it's just a plain unsigned entry.

It will never get here if all of the signers are using disabled algorithms (or for some other reason cannot be parsed/verified) as `JarVerifier.nothingToVerify()` will return true. But I think it's possible if one of the signers is ok. But I'd prefer not to make that change because of the change in behavior. And I think in most cases, JARs will have a single signer.

>> Yes, I can do that. However, I'm a bit wary of using lambdas in this code which may get exercised early in app startup. WDYT?
>
> Maybe, I don't know how problematic if lambda is used this early.
> 
> Anyway, I still prefer moving the update of `permittedAlgs` here. Updating it inside the method seems too faraway.

Changed as suggested in latest revision.

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

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

From weijun at openjdk.java.net  Thu Jan 13 22:56:26 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 13 Jan 2022 22:56:26 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs [v2]
In-Reply-To: <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com>
Message-ID: <PKeuqFLRkV5EvO9z0e7y7aQOSN7vtVQkIhRw33gzB7A=.29e1f13e-3865-4132-8aa6-43ea6860e86f@github.com>

On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
>> 
>> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
>> 
>> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change permittedAlgs variable name.
>   Move put methods out of checkConstraints().

No more comment. Approved.

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

Marked as reviewed by weijun (Reviewer).

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

From jjg at openjdk.java.net  Thu Jan 13 23:01:28 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 13 Jan 2022 23:01:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
 <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
 <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>
Message-ID: <euQ2BZTUg-jsd4LJYaF9nTXRLsnozIsFNI3en-iH6a0=.1fb0785a-886c-41e7-870f-87b941bb82f6@github.com>

On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
>> I'll leave it up to you. 8-)
>
> I think that can be a follow on clean up.

The strange formatting of `long []updateCounts` looks very unusual and well worth a followup cleanup.

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

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

From valeriep at openjdk.java.net  Thu Jan 13 23:55:22 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 Jan 2022 23:55:22 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
 [v2]
In-Reply-To: <-hQ-NPEvJzH4e8lW7uzhEeDFyzuWMu2z1DHK81S7Kq4=.cfe3a130-8c81-4d80-accb-e1ba2f980645@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <-hQ-NPEvJzH4e8lW7uzhEeDFyzuWMu2z1DHK81S7Kq4=.cfe3a130-8c81-4d80-accb-e1ba2f980645@github.com>
Message-ID: <m_2SM2XFCaL6EC-ny7IJGUyll8A0RrO-tbBMIr6XsvM=.a8a0d5e9-ccd9-4052-ba7b-0d80d33720ea@github.com>

On Thu, 13 Jan 2022 21:40:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
>> 
>> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
>> 
>> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   duplicate words, and another year

Looks good. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

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

From michaelm at openjdk.java.net  Fri Jan 14 11:09:46 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 14 Jan 2022 11:09:46 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
Message-ID: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>

Hi,

This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:

A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.

A test will be added separately to the implementation.

Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842

Thanks,
Michael

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

Commit messages:
 - cleanup but still no test. Will be added in closed repo
 - First version of fix. No test and feature enabled always.

Changes: https://git.openjdk.java.net/jdk/pull/7065/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279842
  Stats: 149 lines in 7 files changed: 143 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From dfuchs at openjdk.java.net  Fri Jan 14 11:09:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 14 Jan 2022 11:09:46 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>

On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180:

> 178:     static String normalizeCBT(String s) {
> 179:         if (s == null || ! (s.equals("always") ||
> 180:                 s.equals("never") || s.startsWith("domain:"))) {

I guess there's a `!` missing in front of  `s.startsWith("domain:")` here?

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

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

From michaelm at openjdk.java.net  Fri Jan 14 11:09:46 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 14 Jan 2022 11:09:46 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>
Message-ID: <woMKEnWkpGqpDu-urOsiHUvXKD9OKL-T62fKunvYanI=.dd7f792e-a0a5-4281-9328-888081b968c4@github.com>

On Thu, 13 Jan 2022 18:18:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180:
> 
>> 178:     static String normalizeCBT(String s) {
>> 179:         if (s == null || ! (s.equals("always") ||
>> 180:                 s.equals("never") || s.startsWith("domain:"))) {
> 
> I guess there's a `!` missing in front of  `s.startsWith("domain:")` here?

This is what was intended (equivalent)

`if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))`

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

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

From dfuchs at openjdk.java.net  Fri Jan 14 11:09:47 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 14 Jan 2022 11:09:47 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <woMKEnWkpGqpDu-urOsiHUvXKD9OKL-T62fKunvYanI=.dd7f792e-a0a5-4281-9328-888081b968c4@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>
 <woMKEnWkpGqpDu-urOsiHUvXKD9OKL-T62fKunvYanI=.dd7f792e-a0a5-4281-9328-888081b968c4@github.com>
Message-ID: <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com>

On Fri, 14 Jan 2022 10:03:37 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180:
>> 
>>> 178:     static String normalizeCBT(String s) {
>>> 179:         if (s == null || ! (s.equals("always") ||
>>> 180:                 s.equals("never") || s.startsWith("domain:"))) {
>> 
>> I guess there's a `!` missing in front of  `s.startsWith("domain:")` here?
>
> This is what was intended (equivalent)
> 
> `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))`

Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as 

! (s.equals("always")) || ...

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

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

From myano at openjdk.java.net  Fri Jan 14 11:18:23 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 14 Jan 2022 11:18:23 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames [v2]
In-Reply-To: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
Message-ID: <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>

> Could you please review the JDK-8255739 bug fix?
> 
> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
> 
> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.

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

  8255739: x509Certificate returns ? for invalid subjectAlternativeNames

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6928/files
  - new: https://git.openjdk.java.net/jdk/pull/6928/files/b11495d9..a777ded0

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

  Stats: 103 lines in 3 files changed: 44 ins; 46 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6928/head:pull/6928

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

From myano at openjdk.java.net  Fri Jan 14 11:22:29 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 14 Jan 2022 11:22:29 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames [v2]
In-Reply-To: <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
Message-ID: <DHEFsMPsLYkWvmk8DWyxbwQsxuCsfK2tJj3bSmhX_vc=.691cd0ab-9443-495c-b694-b89d054dcfd3@github.com>

On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the JDK-8255739 bug fix?
>> 
>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>> 
>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255739: x509Certificate returns ? for invalid subjectAlternativeNames

Thank you for your comments.

@seanjmullan I agree that the fix has a compatibility risk.  
I made the fix again to check only DNSName to reduce the risk.
Could you please review the fix?
Is it necessary to issue CSR for the fix?

@wangweij I think the behavior of openssl is incorrect.
According to rfc5280, a certificate-using system MUST reject the certificate if it encounters
a critical extension it does not recognize.

https://datatracker.ietf.org/doc/html/rfc5280#section-4.2

Each extension in a certificate is designated as either critical or non-critical.  
A certificate-using system MUST reject the certificate if it encounters
a critical extension it does not recognize or a critical extension
that contains information that it cannot process.

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

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

From jlahoda at openjdk.java.net  Fri Jan 14 11:22:36 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 14 Jan 2022 11:22:36 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <mHTQhslPgaefsXLYiV_SvYHyzjK_ugDhBIpWzkdua3o=.d6cc09e9-9eb6-4dbb-9b9a-64b743d7eb37@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

javac changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From azvegint at openjdk.java.net  Fri Jan 14 12:19:28 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 14 Jan 2022 12:19:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <2NHrJp-0YZuLsk1to7auM4-WbJ0BxxfUImHMBAYHxs8=.012a0e0c-a9e7-4bb9-b822-21334744d4ed@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Client changes looks good to me.

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

Marked as reviewed by azvegint (Reviewer).

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

From serb at openjdk.java.net  Fri Jan 14 12:21:55 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 14 Jan 2022 12:21:55 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <rlzE5LP1GvYmJokJSX217LG9ZDiZ19UwpgjxaqEVIgw=.6ba07765-b53f-4e9a-ba4f-75dcce6a03e0@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

The code change looks fine, but can you please check the actual performance impact, will the perf be the same after the change?

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

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

From duke at openjdk.java.net  Fri Jan 14 12:21:54 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 14 Jan 2022 12:21:54 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
Message-ID: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>

`Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

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

Commit messages:
 - [PATCH] Remove double buffering of InputStream for Properties.load
 - [PATCH] Remove double buffering of InputStream for Properties.load

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

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

From duke at openjdk.java.net  Fri Jan 14 12:21:56 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 14 Jan 2022 12:21:56 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <ZyprBFZv-TtabE3aKYr6Zm5jVYMv4Axxz_Ky26hmtg0=.4675e14d-13b6-4901-931e-a99895f950b1@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Checked. `BufferedInputStream` add a bit of overhead.

Benchmark

@BenchmarkMode(value = Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 6, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@State(Scope.Benchmark)
public class PropertiesLoad {

    Properties properties;
    private InputStream arrayInputStream;
    private InputStream fileInputStream;
    private Path filePath;

    @Setup
    public void setupStrings() throws IOException {
        properties = new Properties();
        String content = """
                currentVersion=IdealGraphVisualizer {0}
                LBL_splash_window_title=Starting IdealGraphVisualizer
                SPLASH_WIDTH=475
                SplashProgressBarBounds=0,273,475,6
                SplashProgressBarColor=0xFFFFFF
                SplashRunningTextBounds=10,283,460,12
                SplashRunningTextColor=0xFFFFFF
                """;
        filePath = Files.createTempFile("benchmark", ".properties");
        Files.writeString(filePath, content);
        arrayInputStream = new ByteArrayInputStream(content.getBytes(StandardCharsets.UTF_8));
        fileInputStream = Files.newInputStream(filePath);
    }

    @TearDown
    public void tearDown() throws IOException {
        fileInputStream.close();
        Files.delete(filePath);
    }

    @Benchmark
    public Properties plain_ByteStream() throws IOException {
        properties.load(arrayInputStream);
        return properties;
    }

    @Benchmark
    public Properties plain_fileStream() throws IOException {
        properties.load(fileInputStream);
        return properties;
    }

    @Benchmark
    public Properties buffered_ByteStream() throws IOException {
        properties.load(new BufferedInputStream(arrayInputStream));
        return properties;
    }

    @Benchmark
    public Properties buffered_fileStream() throws IOException {
        properties.load(new BufferedInputStream(fileInputStream));
        return properties;
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(PropertiesLoad.class.getSimpleName())
                .build();

        new Runner(opt).run();
    }
}

Results:

Benchmark                           Mode  Cnt     Score     Error  Units
PropertiesLoad.buffered_ByteStream  avgt    5  2416,364 ?  46,209  ns/op
PropertiesLoad.buffered_fileStream  avgt    5  4276,015 ? 139,094  ns/op
PropertiesLoad.plain_ByteStream     avgt    5  1445,864 ? 649,779  ns/op
PropertiesLoad.plain_fileStream     avgt    5  3183,012 ? 198,974  ns/op

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

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

From egahlin at openjdk.java.net  Fri Jan 14 12:42:32 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 14 Jan 2022 12:42:32 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <V_tZ6iUCrtIDCAbwbWr8Pnj-hACcC7UbdEStP17e3BA=.5c64f1d4-9df7-4d9f-8bbc-f59b2748505f@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by egahlin (Reviewer).

The JFR related changes looks OK.

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

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

From amenkov at openjdk.java.net  Fri Jan 14 13:15:22 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 14 Jan 2022 13:15:22 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <BJ_TakGdqnUA_KqyNNzOjx2OHWDBJPWs-qx02dOm0wU=.ef481020-fd17-4f9b-9240-a92bacfed170@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Marked as reviewed by amenkov (Reviewer).

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

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

From dfuchs at openjdk.java.net  Fri Jan 14 14:51:23 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 14 Jan 2022 14:51:23 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <AjckcFhVCs6vyjv3G2rXoN6xc72qk4fg739kj6BW2wc=.cbf3e695-d333-4540-b7ae-75a02844e909@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Changes to `java.util.logging` look fine.

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

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

From dfuchs at openjdk.java.net  Fri Jan 14 15:09:25 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 14 Jan 2022 15:09:25 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>

On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

Have you been able to test this on a specific setup?
Would be good to hear from @msheppar too.

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152:

> 150:      * If enabled (for a particular destination) then SPNEGO authentication requests will include
> 151:      * a channel binding token for the destination server. The default behavior and setting for the
> 152:      * property is "never"

Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too?

src/java.security.jgss/share/classes/module-info.java line 36:

> 34: module java.security.jgss {
> 35:     requires java.naming;
> 36:     requires java.security.sasl;

Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK.

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

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

From mullan at openjdk.java.net  Fri Jan 14 15:16:28 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 14 Jan 2022 15:16:28 GMT
Subject: RFR: 8278851: Correct signer logic for jars signed with multiple
 digestalgs [v2]
In-Reply-To: <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
 <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com>
Message-ID: <_XhQIwiudN6adFO68cMeG19Q7OaSVmtVOxzMgVMYg9I=.af5b5ba8-726a-4587-a991-6651b6265062@github.com>

On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
>> 
>> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
>> 
>> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change permittedAlgs variable name.
>   Move put methods out of checkConstraints().

Each `CodeSigner[]` reference uniquely represents the signers of an entry. Multiple entries can map to the same `CodeSigner[]` reference. We only need reference equality for the keys as each JAR entry is already mapped to an array of `CodeSigner`. It's basically an `IdentityHashMap` but we don't need to specifically use that.

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

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

From mullan at openjdk.java.net  Fri Jan 14 15:26:37 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 14 Jan 2022 15:26:37 GMT
Subject: Integrated: 8278851: Correct signer logic for jars signed with
 multiple digestalgs
In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com>
Message-ID: <3FFvIAdVz8COQnCOuRrXPtCTqQnpZoHwM0Q7z6ctcCA=.34c42417-f567-47f5-9686-0bc6b6dd0fa5@github.com>

On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. 
> 
> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. 
> 
> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers.

This pull request has now been integrated.

Changeset: 61b89443
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61b8944327e3d12cf58dc3f6bc45ecbeba4ef611
Stats:     264 lines in 3 files changed: 214 ins; 20 del; 30 mod

8278851: Correct signer logic for jars signed with multiple digestalgs

Reviewed-by: coffeys, weijun

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

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

From jjg at openjdk.java.net  Fri Jan 14 16:08:31 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 14 Jan 2022 16:08:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <96bxwtnI-_Z67Udh4acEGwA2xzIy6dAV6CxOe9HLkRo=.dd8643aa-f3be-42e2-ad72-4a00d90363d9@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

jdk.compiler and jdk.javadoc look good

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

Marked as reviewed by jjg (Reviewer).

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

From prappo at openjdk.java.net  Fri Jan 14 16:13:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 14 Jan 2022 16:13:34 GMT
Subject: Integrated: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <iRT0-D_kHCqoTOO_tqTh0WH4UU1j-7Ju2SV6oLUBLhU=.73b73e8f-5608-4fc1-a147-bc569d647428@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

This pull request has now been integrated.

Changeset: f1805309
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224
Stats:     88 lines in 35 files changed: 0 ins; 0 del; 88 mod

8279918: Fix various doc typos

Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg

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

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

From mullan at openjdk.java.net  Fri Jan 14 16:34:27 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 14 Jan 2022 16:34:27 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <8hvTLJgEpq9NO_nLIPzf2_clWO4ZXDH0VJZ5G1vzzvE=.4495b2d0-009d-4e45-85d2-346a4b97f316@github.com>

On Wed, 12 Jan 2022 02:15:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

> 2196:                         ("Certificate.chain.length.") + chain.length);
> 2197: 
> 2198:                     X509Certificate[] xcerts = convertCerts(chain);

I think you can just cast to an `X509Certificate[]` instead of reparsing all the certificates, i.e.:

`X509Certificate[] xcerts = (X509Certificate[]) chain;`

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

> 2257:             }
> 2258:             cpcp = new CertPathConstraintsParameters((X509Certificate)cert,
> 2259:                     null,null, null);

Nit - add space between `null,null`.

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

> 5046:     }
> 5047: 
> 5048:     private TrustAnchor findTrustAnchor(List<X509Certificate> chain) {

I would consider having an initial check that returns `null` if `chain.isEmpty()`. Not sure if that is a valid scenario, but it would avoid an `IndexOOBException` just in case.

src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 486:

> 484:         {"verified.by.s.in.s.weak", "Verified by %1$s in %2$s with a %3$s"},
> 485:         {"whose.sigalg.disabled", "%1$s uses the %2$s signature algorithm which is considered a security risk and is disabled."},
> 486:         {"whose.sigalg.usagesignedjar", "%1$s uses the %2$s signature algorithm which is considered a security risk and cannot be used to sign JARs after 2019-01-01."},

Instead of hard-coding "2019-01-01", we should extract this date from the `denyAfter` attribute of the `jdk.certpath.disabledAlgorithms` security property and pass it in as a parameter.

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

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

From sspitsyn at openjdk.java.net  Fri Jan 14 17:59:29 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 14 Jan 2022 17:59:29 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <svTyMZjHhPPqYKFtRqAV4uiCY1cTzGj7hAj5jQ4QksU=.aab322cc-5262-4b24-9cca-566d3264622b@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Marked as reviewed by sspitsyn (Reviewer).

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

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

From michaelm at openjdk.java.net  Fri Jan 14 18:45:27 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 14 Jan 2022 18:45:27 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
Message-ID: <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>

On Fri, 14 Jan 2022 14:52:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152:
> 
>> 150:      * If enabled (for a particular destination) then SPNEGO authentication requests will include
>> 151:      * a channel binding token for the destination server. The default behavior and setting for the
>> 152:      * property is "never"
> 
> Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too?

It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?

> src/java.security.jgss/share/classes/module-info.java line 36:
> 
>> 34: module java.security.jgss {
>> 35:     requires java.naming;
>> 36:     requires java.security.sasl;
> 
> Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK.

Yes. I would like the security team to validate this.

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

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

From weijun at openjdk.java.net  Fri Jan 14 20:42:30 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 14 Jan 2022 20:42:30 GMT
Subject: RFR: 8279064: New options for ktab to provide non-default salt
 [v2]
In-Reply-To: <-hQ-NPEvJzH4e8lW7uzhEeDFyzuWMu2z1DHK81S7Kq4=.cfe3a130-8c81-4d80-accb-e1ba2f980645@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
 <-hQ-NPEvJzH4e8lW7uzhEeDFyzuWMu2z1DHK81S7Kq4=.cfe3a130-8c81-4d80-accb-e1ba2f980645@github.com>
Message-ID: <IA9Ue9phyzbli8u3o7BWHlOGCbzg4uYE0uyebdvq-sw=.fdd6763b-95cf-4703-adc0-1d3b58169c85@github.com>

On Thu, 13 Jan 2022 21:40:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
>> 
>> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
>> 
>> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   duplicate words, and another year

I heard the CSR is approved.

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

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

From weijun at openjdk.java.net  Fri Jan 14 20:49:59 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 14 Jan 2022 20:49:59 GMT
Subject: Integrated: 8279064: New options for ktab to provide non-default salt
In-Reply-To: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
References: <W_UxpBuPJP1z9n62lTtd60GmvfGmV_FUXdbaqiWxPoQ=.9d8c4f02-1c0a-4520-bfce-56b046405aff@github.com>
Message-ID: <bNqE3nReNDvaAOPKHfBZtvuhayTltZZ9WGPYaYpl76M=.d545c4c6-acac-49bf-bd03-5925afe39fc7@github.com>

On Fri, 7 Jan 2022 19:35:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries.
> 
> I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is already used in `ktab -d` to force removing entries. Hopefully not many people are writing their own wrappers on ktab that always include the `-f` option. I do want to be consistent with the naming in the MIT krb5 ktutil command.
> 
> Another thing worth mentioning is the [KerberosKey:&lt;new&gt;(KerberosPrincipal principal, char[] password, String algorithm)](https://github.com/openjdk/jdk/blob/3790e58090be25421e3e323eb29deea100b7608c/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java#L149) constructor which always uses the default salt. For consistency, it looks like a new constructor should be added that takes the salt string as a parameter as well. However, I don't intend to add it as I cannot see a proper usage for it. In fact, I now regret adding the constructor linked above.

This pull request has now been integrated.

Changeset: 0d1a97f7
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0d1a97f793309919bd6d67085630049eaafcced1
Stats:     158 lines in 5 files changed: 135 ins; 1 del; 22 mod

8279064: New options for ktab to provide non-default salt

Reviewed-by: valeriep

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

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

From weijun at openjdk.java.net  Sat Jan 15 00:30:28 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 15 Jan 2022 00:30:28 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
Message-ID: <lA4Dp9CF09__t3IeyT9JNMzxYVJRweEwDP3SApvzw3w=.fb2812a2-15e8-4ad5-9736-3bd904f609ce@github.com>

On Fri, 14 Jan 2022 18:42:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/module-info.java line 36:
>> 
>>> 34: module java.security.jgss {
>>> 35:     requires java.naming;
>>> 36:     requires java.security.sasl;
>> 
>> Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK.
>
> Yes. I would like the security team to validate this.

I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. You might need to modify the types of exceptions thrown in the class and move the 2 final strings to some other class inside `java.security.sasl`.

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

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

From weijun at openjdk.java.net  Sat Jan 15 00:47:27 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 15 Jan 2022 00:47:27 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
Message-ID: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>

On Fri, 14 Jan 2022 18:40:41 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152:
>> 
>>> 150:      * If enabled (for a particular destination) then SPNEGO authentication requests will include
>>> 151:      * a channel binding token for the destination server. The default behavior and setting for the
>>> 152:      * property is "never"
>> 
>> Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too?
>
> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?

This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate".

BTW, will you reuse this system property if we decide to support CBT in NTLM as well?

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

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

From weijun at openjdk.java.net  Sat Jan 15 00:52:27 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 15 Jan 2022 00:52:27 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>
 <woMKEnWkpGqpDu-urOsiHUvXKD9OKL-T62fKunvYanI=.dd7f792e-a0a5-4281-9328-888081b968c4@github.com>
 <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com>
Message-ID: <g40_YcOcxvCHoRfWT6PQ-rY7aJ8idcM1ohMAI2SkDAc=.00ecd1a9-2342-4490-a280-50bdcf5bc32c@github.com>

On Fri, 14 Jan 2022 10:18:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is what was intended (equivalent)
>> 
>> `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))`
>
> Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as 
> 
> ! (s.equals("always")) || ...

Shall we log a message if the value is not one of the 3 forms?

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

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

From serb at openjdk.java.net  Sat Jan 15 02:32:32 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 15 Jan 2022 02:32:32 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <YUDWGMcJWVXt0_z2KnNBNd4DCnA4kZOTLF4CKs8M2lA=.f56bafef-e12a-4595-ac9a-b7405b69b637@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Marked as reviewed by serb (Reviewer).

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

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

From duke at openjdk.java.net  Sat Jan 15 14:05:21 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Sat, 15 Jan 2022 14:05:21 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <lA4Dp9CF09__t3IeyT9JNMzxYVJRweEwDP3SApvzw3w=.fb2812a2-15e8-4ad5-9736-3bd904f609ce@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <lA4Dp9CF09__t3IeyT9JNMzxYVJRweEwDP3SApvzw3w=.fb2812a2-15e8-4ad5-9736-3bd904f609ce@github.com>
Message-ID: <dIzYlYqdEaNVYKnReGiQ9IT_4dsyITEd3ulm1VntzMU=.6751ad80-7c36-4029-a1ff-ceb6e430ba2c@github.com>

On Sat, 15 Jan 2022 00:23:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Yes. I would like the security team to validate this.
>
> I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. It's even not restricted to GSS-API. According to https://www.rfc-editor.org/rfc/rfc5056, "Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications".
> 
> If so, you might need to modify the types of exceptions thrown in the class, and move the 2 final strings to some other class inside `java.security.sasl`.

Seems like `com.sun.jndi.ldap.sasl.TlsChannelBinding` is not misplaced....

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

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

From duke at openjdk.java.net  Mon Jan 17 05:29:32 2022
From: duke at openjdk.java.net (prasad-bit)
Date: Mon, 17 Jan 2022 05:29:32 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
Message-ID: <Op9mVOQh_3oOx73vggl4wr24KWHbw82NNxVDMGfNNuA=.158a4ff7-cc23-4072-b99c-24ca7bebc8e2@github.com>

On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?
>
> This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate".
> 
> BTW, will you reuse this system property if we decide to support CBT in NTLM as well?

I vote for "jdk.https.tls.cbt"

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

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

From pkoppula at openjdk.java.net  Mon Jan 17 06:35:30 2022
From: pkoppula at openjdk.java.net (Prasadrao Koppula)
Date: Mon, 17 Jan 2022 06:35:30 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
Message-ID: <w13AX0V232LPz-20aJTWS-8LEmevaRZq_xAtGr1hl70=.8d72bbfc-61de-41ec-92e7-128d9fab46a2@github.com>

On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?
>
> This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate".
> 
> BTW, will you reuse this system property if we decide to support CBT in NTLM as well?

I vote for "jdk.https.tls.cbt"

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

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

From pkoppula at openjdk.java.net  Mon Jan 17 11:48:25 2022
From: pkoppula at openjdk.java.net (Prasadrao Koppula)
Date: Mon, 17 Jan 2022 11:48:25 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <RTKDjKki_7qeA0zwvHFwUy0ExjBMxC__05IatVS50bM=.d02504df-7d03-4037-87e3-3eba8ae769fd@github.com>

On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

Add Release note and Doc subtasks to the JBS

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

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

From dfuchs at openjdk.java.net  Mon Jan 17 13:47:26 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 17 Jan 2022 13:47:26 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <g40_YcOcxvCHoRfWT6PQ-rY7aJ8idcM1ohMAI2SkDAc=.00ecd1a9-2342-4490-a280-50bdcf5bc32c@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>
 <woMKEnWkpGqpDu-urOsiHUvXKD9OKL-T62fKunvYanI=.dd7f792e-a0a5-4281-9328-888081b968c4@github.com>
 <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com>
 <g40_YcOcxvCHoRfWT6PQ-rY7aJ8idcM1ohMAI2SkDAc=.00ecd1a9-2342-4490-a280-50bdcf5bc32c@github.com>
Message-ID: <iUmeGNqpJMFWVV4JvT_CdukmvaSQhU7-nTncblZIgyQ=.97f6d6e6-1b6d-4d0e-acf1-687d9f8793cd@github.com>

On Sat, 15 Jan 2022 00:49:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as 
>> 
>> ! (s.equals("always")) || ...
>
> Shall we log a message if the value is not one of the 3 forms?

Usually malformed values are just ignored - and the property takes its default value. But yes - s.n.w.h.HttpClient has a logger so it wouldn't be much effort to log it as a DEBUG trace for better diagnostic.

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

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

From dfuchs at openjdk.java.net  Mon Jan 17 13:52:26 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 17 Jan 2022 13:52:26 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <w13AX0V232LPz-20aJTWS-8LEmevaRZq_xAtGr1hl70=.8d72bbfc-61de-41ec-92e7-128d9fab46a2@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
 <w13AX0V232LPz-20aJTWS-8LEmevaRZq_xAtGr1hl70=.8d72bbfc-61de-41ec-92e7-128d9fab46a2@github.com>
Message-ID: <OX6GdSlwuHddPP-t_uHnloRmDdl-C_iT6MJGfS8wSuc=.72586809-9def-4811-b5d0-ebb7f2285d10@github.com>

On Mon, 17 Jan 2022 06:32:13 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate".
>> 
>> BTW, will you reuse this system property if we decide to support CBT in NTLM as well?
>
> I vote for "jdk.https.tls.cbt"

> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?

AFAICS this file documents properties used by the networking task - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property)

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

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

From myano at openjdk.java.net  Tue Jan 18 07:58:23 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 18 Jan 2022 07:58:23 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames
In-Reply-To: <af7C2TFYwcldrmahOFKvHuzVsmVmxJ1wAUJi9drMEMA=.cb6a9ccf-69fa-4748-9dea-dd1f8af2a9f1@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <af7C2TFYwcldrmahOFKvHuzVsmVmxJ1wAUJi9drMEMA=.cb6a9ccf-69fa-4748-9dea-dd1f8af2a9f1@github.com>
Message-ID: <gcJ8eVL7T8ZcGDnknCbTQddySMfDAg9vOSKo0cF2D_U=.e6837923-695a-48ed-98e8-8d3261b6e754@github.com>

On Thu, 6 Jan 2022 20:28:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Could you please review the JDK-8255739 bug fix?
>> 
>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>> 
>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>
> I understand the reasons for making the code more robust and detecting invalid DER encodings, but this may have a non-trivial compatibility risk. In general, I think detecting invalid encodings is generally the right thing to do, but compatibility needs to be considered. Sometimes other implementations have encoding bugs that we need to workaround, etc. This change affects not only certificates but other security components that use DER in the JDK. Certificates already treat non-critical extensions that are badly encoded as not a failure, so there is some compatibility built-in already. But I think it makes sense to look at other code that calls into the DerValue methods and evaluate the potential compatibility risk. At a minimum, a CSR must be filed. As a compromise, it may make sense to (at least initially) reduce the compatibility risk by allowing the caller (ex: `sun.security.x509.DNSName`) to decide if it wants a stricter parsing of the DER-encoded string.
> 
> I would like @wangweij or @valeriepeng to also review this. 
> 
> With respect to the test, it seems like overkill to launch a java process inside the test to run each test. Instead, I would just have separate methods for each test and run them in the same process as the main test.

@seanjmullan @wangweij I have commented on what you pointed out, so could you please reply?

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

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

From jjiang at openjdk.java.net  Tue Jan 18 11:19:42 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 18 Jan 2022 11:19:42 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output "named groups"
 rather than "versions"
Message-ID: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>

MessageFormat messageFormat = new MessageFormat(
    ""versions": '['{0}']'", Locale.ENGLISH);

In class SupportedGroupsExtension, the above "versions" should be "named groups".

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

Commit messages:
 - 8280122: SupportedGroupsExtension should output "named groups" rather than "versions"

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

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

From olivier.cailloux at dauphine.fr  Tue Jan 18 12:57:57 2022
From: olivier.cailloux at dauphine.fr (Olivier Cailloux)
Date: Tue, 18 Jan 2022 13:57:57 +0100
Subject: JEP 411: sandboxing use case
In-Reply-To: <ab92b4affba37ad8f0f0dc0677e4a0e6e3253c84.camel@dauphine.fr>
References: <ab92b4affba37ad8f0f0dc0677e4a0e6e3253c84.camel@dauphine.fr>
Message-ID: <54161eb093f165db22d4d6cfc860dc6cef90a67d.camel@dauphine.fr>

Thanks to Sean and Peter for your answers (sorry, I did not manage to
answer your messages because of issues with my e-mail provider so I
answer mine instead).

As Peter observes, putting student code in a restricted VM or container
(while the grading code would be more priviledged) does not seem like a
great solution. It is unclear how to make this setup reasonably secure,
and it complicates the code very much as I can then no more access the
student code as with running unit tests (using shared memory space and
querying their objects directly from the grading code), I?d need to
serialize and de-serialize everything.

It seems like I don?t have any other choice than waiting for finalizers
to be removed and call interception to be available. This is okay for
me: I just wanted to make sure that some solution is coming.

In the meantime, my application warns that I am using deprecated APIs.
I believe that it is a mistaken decision from JEP 411 that I can do
nothing to disable these warning. This could make my application look
unprofessional to at least those advanced users that will look at those
warnings, and thus, has a negative impact on me, whereas I can do
nothing against that (no replacement option has been made available
yet, and none is coming very soon) and it is not my fault.?

I know that this has been discussed here previously, and I have read
the rationale for this decision, but these reasons do not justify
harming Java developers? reputation.

Not that it is a very grave mistake, but I wanted to voice this concern
in hope of another decision next time if similar situations happen.


Le lundi 10 janvier 2022 ? 15:22 +0100, Olivier Cailloux a ?crit?:
> Dear list,
> 
> I would like to share my use case for currently using the security
> manager mechanism (SM) in my software. Now that JEP 411 is there, any
> advice about any currently existing solution for replacement would be
> welcome, if this is already possible; alternatively, I hope that a
> replacement for these needs will be available soon.
> 
> My software grades student work. It download their code from GitHub,
> compiles it, runs it, and observe the results (similar to running
> JUnit
> tests, but on pluggable code). Their code is then graded
> automatically
> depending on the expected versus actual results.
> 
> I currently use SM to prevent student code to alter the system on
> which
> the code runs or have external impact. I don?t want them to read
> files
> or send network requests (they usually do not need to do anything
> like
> this for the exercices assigned to them). I currently use a simple
> ?no
> priviledged calls at all? configuration, where everything that can be
> forbidden by SM is forbidden for their code, as they only need to be
> able to deal with their own objects and classes from the JDK that
> operate ?taint-free? (as Chapman Flak puts it), such as classical
> List
> or Set structures.
> 
> Though I do not currently need such more advanced feature, I
> considered
> as a good bonus that SM allowed me, if I wanted to, to give exercices
> that also deal with file writing (through telling SM that their code
> can access a restricted set of files). If any replacement solution
> could also allow this kind of flexibility, that would be nice.
> 
> I am aware that their code could implement a denial of service; I am
> okay to live with this risk as any resulting damage would be low
> (worst
> case, just restart the computer). But I?d like to reduce the risk
> that
> their code would read or modify files or other aspects of the system
> it
> is running on, for example, as the resulting damage could be much
> higher (such as: alter the way the system works so that the grading
> of
> other students, graded next, would be modified; read personal files
> from the account that is running the grading software and posting
> their
> content on the internet; inadvertently delete files on the host
> system?)
> 
> I implement code isolation so that one student code does not see or
> interact with the code of other students classical using class loader
> mechanisms, for which JEP 411 does not create problems. But I ignore
> how to prevent file writing, socket opening, or similar stuff, using
> other means than SM.
> 
> My needs resemble (but are not identical to) the ones exposed by
> Chapman Flack in ?JEP 411: Missing use-case: user functions in an
> RDBMS?,?https://marc.info/?m=162216583127042. I share the concern of
> this poster (https://marc.info/?m=162221303911911) that it currently
> seems that I?d have to come up with various, specialized mechanisms
> to
> prevent various kinds of operations (file system access, socket
> access,??), which seems inelegant and error-prone.
> 
> Even after reading the insightful article of Ron Pressler, Shallow
> Java
> Sandboxes
> (https://inside.java/2021/04/23/security-and-sandboxing-post-
> securitymanager/),
> it is unclear to me whether I can get rid of SecurityManager with
> existing Java 17 technology. Any advice would be welcome. If not
> possible, please consider this use case when thinking about further
> progress in replacing the security related APIs. (I am quite worried
> by
> the wording of JEP 411 Future Work not mentioning this kind of
> sandboxing need.)
> 
> Olivier
> 
> 



From weijun at openjdk.java.net  Tue Jan 18 14:10:29 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 Jan 2022 14:10:29 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
Message-ID: <qfKtdHwsGufD7GP7DdbY5HP41Ma8DHx4v9RPF-LMR9Y=.e4f7cd01-ae40-4058-9fd4-3361bab50830@github.com>

On Tue, 18 Jan 2022 11:11:49 GMT, John Jiang <jjiang at openjdk.org> wrote:

> MessageFormat messageFormat = new MessageFormat(
>     ""versions": '['{0}']'", Locale.ENGLISH);
> 
> In class SupportedGroupsExtension, the above "versions" should be "named groups".

Marked as reviewed by weijun (Reviewer).

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

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

From aturbanov at openjdk.java.net  Tue Jan 18 15:52:31 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 18 Jan 2022 15:52:31 GMT
Subject: Integrated: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <c-3BkaHdJ29HMIl0SPYfTIUWgo4A39B4LeoXMZ-HzBk=.17bf155a-85b4-4d6c-8f1f-079861febf26@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

This pull request has now been integrated.

Changeset: 9eb50a5e
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9eb50a5ee4a069fbb248748ebee09132e2450420
Stats:     30 lines in 8 files changed: 0 ins; 11 del; 19 mod

8280010: Remove double buffering of InputStream for Properties.load

Reviewed-by: amenkov, sspitsyn, serb

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

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

From xuelei at openjdk.java.net  Tue Jan 18 16:19:28 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 18 Jan 2022 16:19:28 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
Message-ID: <DdW_0GqMFScrfDP55y6L83rC8HHxRjuFixKa19JKwlc=.aa597e48-e29c-4bd6-979c-7f5660fedad2@github.com>

On Tue, 18 Jan 2022 11:11:49 GMT, John Jiang <jjiang at openjdk.org> wrote:

> MessageFormat messageFormat = new MessageFormat(
>     ""versions": '['{0}']'", Locale.ENGLISH);
> 
> In class SupportedGroupsExtension, the above "versions" should be "named groups".

Nice catching!

src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java line 115:

> 113:         public String toString() {
> 114:             MessageFormat messageFormat = new MessageFormat(
> 115:                 "\"named groups\": '['{0}']'", Locale.ENGLISH);

Per the TLS specification, it may be a more instinctive to use  "supported groups".  It is not a big concern, no additional approval is required to me if you want an update.

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

Marked as reviewed by xuelei (Reviewer).

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

From weijun at openjdk.java.net  Tue Jan 18 16:30:28 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 Jan 2022 16:30:28 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <DdW_0GqMFScrfDP55y6L83rC8HHxRjuFixKa19JKwlc=.aa597e48-e29c-4bd6-979c-7f5660fedad2@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
 <DdW_0GqMFScrfDP55y6L83rC8HHxRjuFixKa19JKwlc=.aa597e48-e29c-4bd6-979c-7f5660fedad2@github.com>
Message-ID: <JiceiBTJ7kyG8maRSpBItowNBQkjsbBS4aNaPexKaWw=.af80a776-5904-4e72-81cb-a8ff52d2cef7@github.com>

On Tue, 18 Jan 2022 16:13:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> MessageFormat messageFormat = new MessageFormat(
>>     ""versions": '['{0}']'", Locale.ENGLISH);
>> 
>> In class SupportedGroupsExtension, the above "versions" should be "named groups".
>
> src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java line 115:
> 
>> 113:         public String toString() {
>> 114:             MessageFormat messageFormat = new MessageFormat(
>> 115:                 "\"named groups\": '['{0}']'", Locale.ENGLISH);
> 
> Per the TLS specification, it may be a more instinctive to use  "supported groups".  It is not a big concern, no additional approval is required to me if you want an update.

If so, should the `SupportedVersionsExtension` get a more precise description as well?

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

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

From xuelei at openjdk.java.net  Tue Jan 18 19:36:27 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 18 Jan 2022 19:36:27 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <JiceiBTJ7kyG8maRSpBItowNBQkjsbBS4aNaPexKaWw=.af80a776-5904-4e72-81cb-a8ff52d2cef7@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
 <DdW_0GqMFScrfDP55y6L83rC8HHxRjuFixKa19JKwlc=.aa597e48-e29c-4bd6-979c-7f5660fedad2@github.com>
 <JiceiBTJ7kyG8maRSpBItowNBQkjsbBS4aNaPexKaWw=.af80a776-5904-4e72-81cb-a8ff52d2cef7@github.com>
Message-ID: <eNgKx5s-TXw45fc8WY3rA22RGo4NdydRdrQdU6sbGKE=.0630845a-0eb5-4cd7-bcf0-ea4cdaa3f730@github.com>

On Tue, 18 Jan 2022 16:27:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> If so, should the `SupportedVersionsExtension` get a more precise description as well?

I did not get the point.  Did you mean to update the comment on the SupportedVersionsExtension, by adding RFC 8446?

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

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

From weijun at openjdk.java.net  Tue Jan 18 19:55:30 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 Jan 2022 19:55:30 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <eNgKx5s-TXw45fc8WY3rA22RGo4NdydRdrQdU6sbGKE=.0630845a-0eb5-4cd7-bcf0-ea4cdaa3f730@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
 <DdW_0GqMFScrfDP55y6L83rC8HHxRjuFixKa19JKwlc=.aa597e48-e29c-4bd6-979c-7f5660fedad2@github.com>
 <JiceiBTJ7kyG8maRSpBItowNBQkjsbBS4aNaPexKaWw=.af80a776-5904-4e72-81cb-a8ff52d2cef7@github.com>
 <eNgKx5s-TXw45fc8WY3rA22RGo4NdydRdrQdU6sbGKE=.0630845a-0eb5-4cd7-bcf0-ea4cdaa3f730@github.com>
Message-ID: <C8ptPQcZAoyyLCvkJIZxXhLgDIEtabc8L0SPAPvnIZU=.9a414b8a-f0fc-4edf-8222-526a6c618c01@github.com>

On Tue, 18 Jan 2022 19:33:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> If so, should the `SupportedVersionsExtension` get a more precise description as well?
>
>> If so, should the `SupportedVersionsExtension` get a more precise description as well?
> 
> I did not get the point.  Did you mean to update the comment on the SupportedVersionsExtension, by adding RFC 8446?

No, I just meant updating `""versions": '['{0}']'"` to `""supported versions": '['{0}']'"` there.

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

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

From mullan at openjdk.java.net  Tue Jan 18 21:10:27 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 Jan 2022 21:10:27 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames
In-Reply-To: <af7C2TFYwcldrmahOFKvHuzVsmVmxJ1wAUJi9drMEMA=.cb6a9ccf-69fa-4748-9dea-dd1f8af2a9f1@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <af7C2TFYwcldrmahOFKvHuzVsmVmxJ1wAUJi9drMEMA=.cb6a9ccf-69fa-4748-9dea-dd1f8af2a9f1@github.com>
Message-ID: <9KbehHQkYt97fRvntUumETKjqIr97U-tp9FqEVuDMWs=.c40ceda1-3a60-48b5-a1af-814523e010f2@github.com>

On Thu, 6 Jan 2022 20:28:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Could you please review the JDK-8255739 bug fix?
>> 
>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>> 
>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>
> I understand the reasons for making the code more robust and detecting invalid DER encodings, but this may have a non-trivial compatibility risk. In general, I think detecting invalid encodings is generally the right thing to do, but compatibility needs to be considered. Sometimes other implementations have encoding bugs that we need to workaround, etc. This change affects not only certificates but other security components that use DER in the JDK. Certificates already treat non-critical extensions that are badly encoded as not a failure, so there is some compatibility built-in already. But I think it makes sense to look at other code that calls into the DerValue methods and evaluate the potential compatibility risk. At a minimum, a CSR must be filed. As a compromise, it may make sense to (at least initially) reduce the compatibility risk by allowing the caller (ex: `sun.security.x509.DNSName`) to decide if it wants a stricter parsing of the DER-encoded string.
> 
> I would like @wangweij or @valeriepeng to also review this. 
> 
> With respect to the test, it seems like overkill to launch a java process inside the test to run each test. Instead, I would just have separate methods for each test and run them in the same process as the main test.

> @seanjmullan @wangweij I have commented on what you pointed out, so could you please reply?

I need another couple of days to look at this issue again before I can reply.

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

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

From jjiang at openjdk.java.net  Tue Jan 18 22:33:38 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 18 Jan 2022 22:33:38 GMT
Subject: RFR: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <C8ptPQcZAoyyLCvkJIZxXhLgDIEtabc8L0SPAPvnIZU=.9a414b8a-f0fc-4edf-8222-526a6c618c01@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
 <DdW_0GqMFScrfDP55y6L83rC8HHxRjuFixKa19JKwlc=.aa597e48-e29c-4bd6-979c-7f5660fedad2@github.com>
 <JiceiBTJ7kyG8maRSpBItowNBQkjsbBS4aNaPexKaWw=.af80a776-5904-4e72-81cb-a8ff52d2cef7@github.com>
 <eNgKx5s-TXw45fc8WY3rA22RGo4NdydRdrQdU6sbGKE=.0630845a-0eb5-4cd7-bcf0-ea4cdaa3f730@github.com>
 <C8ptPQcZAoyyLCvkJIZxXhLgDIEtabc8L0SPAPvnIZU=.9a414b8a-f0fc-4edf-8222-526a6c618c01@github.com>
Message-ID: <B4UEhHEGQZ-XL7VsUehp3FOF5BKvGxepErIYyT5uNoE=.33f11ff5-af20-46e6-9061-e34115a0b25f@github.com>

On Tue, 18 Jan 2022 19:52:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> If so, should the `SupportedVersionsExtension` get a more precise description as well?
>> 
>> I did not get the point.  Did you mean to update the comment on the SupportedVersionsExtension, by adding RFC 8446?
>
> No, I just meant updating `""versions": '['{0}']'"` to `""supported versions": '['{0}']'"` there.

I looked through SupportedGroupsExtension.java and found many examples, like the followings,
> no supported named group specified
the supported named groups
contains no supported named groups
No default named groups
Ignore inactive or disabled named group
... ...

so I finally used "named groups".

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

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

From jjiang at openjdk.java.net  Tue Jan 18 22:43:35 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 18 Jan 2022 22:43:35 GMT
Subject: Integrated: 8280122: SupportedGroupsExtension should output
 "named groups" rather than "versions"
In-Reply-To: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
References: <UGLEcHCbp4YIE2vL64ibpmcS1DcurTwPFvHnPi44O7E=.b7c6a678-2800-4ea0-b77b-328c4dc16b86@github.com>
Message-ID: <_2wwbtm-GLq7JfTxPPeC2E1_ja-VgTOMlAexm46a6TQ=.3699209b-1ddc-4517-b29a-fbc89824d65d@github.com>

On Tue, 18 Jan 2022 11:11:49 GMT, John Jiang <jjiang at openjdk.org> wrote:

> MessageFormat messageFormat = new MessageFormat(
>     ""versions": '['{0}']'", Locale.ENGLISH);
> 
> In class SupportedGroupsExtension, the above "versions" should be "named groups".

This pull request has now been integrated.

Changeset: 3a421e4b
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3a421e4b78ae5e7116ac68128504b65fa00e1f7f
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8280122: SupportedGroupsExtension should output "named groups" rather than "versions"

Reviewed-by: weijun, xuelei

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

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

From aturbanov at openjdk.java.net  Wed Jan 19 11:03:34 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 19 Jan 2022 11:03:34 GMT
Subject: Integrated: 8274811: Remove superfluous use of boxing in java.base
In-Reply-To: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
References: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
Message-ID: <vkSwaAhoWuZvj1E7Oim_N8jMURBZ3HpPW6fY8h4Y9cI=.3c0795cd-49ae-48a8-8e70-a17d7833f0e3@github.com>

On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop
> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset

This pull request has now been integrated.

Changeset: 5af7f258
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5af7f258144d9f753ebe6ebfada42f33aaed108b
Stats:     11 lines in 4 files changed: 0 ins; 0 del; 11 mod

8274811: Remove superfluous use of boxing in java.base

Reviewed-by: lancea

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

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

From kevinw at openjdk.java.net  Wed Jan 19 12:54:23 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 19 Jan 2022 12:54:23 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
Message-ID: <vwIl4iUWBS0db92hVMLcmDcfN6abdUHQrNhPNYLSM_Q=.8485673e-94f0-4361-99cd-50b4aaa333eb@github.com>

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

CSR has been approved (https://bugs.openjdk.java.net/browse/JDK-8279891)

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

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

From michaelm at openjdk.java.net  Wed Jan 19 15:40:35 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 Jan 2022 15:40:35 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <OX6GdSlwuHddPP-t_uHnloRmDdl-C_iT6MJGfS8wSuc=.72586809-9def-4811-b5d0-ebb7f2285d10@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
 <w13AX0V232LPz-20aJTWS-8LEmevaRZq_xAtGr1hl70=.8d72bbfc-61de-41ec-92e7-128d9fab46a2@github.com>
 <OX6GdSlwuHddPP-t_uHnloRmDdl-C_iT6MJGfS8wSuc=.72586809-9def-4811-b5d0-ebb7f2285d10@github.com>
Message-ID: <zcX9AEY0fJWrhafcCtcfJGcPD141AU4nUROYyc962R4=.a308fa81-f431-4214-b1cc-2e35404c02a8@github.com>

On Mon, 17 Jan 2022 13:49:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I vote for "jdk.https.tls.cbt"
>
>> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?
> 
> AFAICS this file documents properties used by the networking task - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property)

Okay, good idea to document it in the properties file. Also, I think "jdk.https.tls.cbt" is a reasonable name for the property.

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

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

From michaelm at openjdk.java.net  Wed Jan 19 15:40:36 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 Jan 2022 15:40:36 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <iUmeGNqpJMFWVV4JvT_CdukmvaSQhU7-nTncblZIgyQ=.97f6d6e6-1b6d-4d0e-acf1-687d9f8793cd@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <tAPanuECsOmjEtMUbXFaABL0Y30Hrfx0QwbTvSSvI6U=.bdbbb911-d9ec-4076-a98d-425f067f0d78@github.com>
 <woMKEnWkpGqpDu-urOsiHUvXKD9OKL-T62fKunvYanI=.dd7f792e-a0a5-4281-9328-888081b968c4@github.com>
 <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com>
 <g40_YcOcxvCHoRfWT6PQ-rY7aJ8idcM1ohMAI2SkDAc=.00ecd1a9-2342-4490-a280-50bdcf5bc32c@github.com>
 <iUmeGNqpJMFWVV4JvT_CdukmvaSQhU7-nTncblZIgyQ=.97f6d6e6-1b6d-4d0e-acf1-687d9f8793cd@github.com>
Message-ID: <0_k-W6vPKT_r3U_Tgj9-S8Dn2RxBIiMFsZ8vZI4p23E=.15d85a8b-5ca5-4cc4-a413-9c8a87c138f4@github.com>

On Mon, 17 Jan 2022 13:44:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Shall we log a message if the value is not one of the 3 forms?
>
> Usually malformed values are just ignored - and the property takes its default value. But yes - s.n.w.h.HttpClient has a logger so it wouldn't be much effort to log it as a DEBUG trace for better diagnostic.

Yes, I will log it using the same debug/logging mechanism already in the same source file..

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

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

From michaelm at openjdk.java.net  Wed Jan 19 15:40:36 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 Jan 2022 15:40:36 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <dIzYlYqdEaNVYKnReGiQ9IT_4dsyITEd3ulm1VntzMU=.6751ad80-7c36-4029-a1ff-ceb6e430ba2c@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <lA4Dp9CF09__t3IeyT9JNMzxYVJRweEwDP3SApvzw3w=.fb2812a2-15e8-4ad5-9736-3bd904f609ce@github.com>
 <dIzYlYqdEaNVYKnReGiQ9IT_4dsyITEd3ulm1VntzMU=.6751ad80-7c36-4029-a1ff-ceb6e430ba2c@github.com>
Message-ID: <5zco_5V9sMUkWNWNVmjFyvHNVkR5iZicq_0DBQWtRp4=.55489b7e-8f53-4c83-acd8-66141b5021af@github.com>

On Sat, 15 Jan 2022 14:02:15 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. It's even not restricted to GSS-API. According to https://www.rfc-editor.org/rfc/rfc5056, "Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications".
>> 
>> If so, you might need to modify the types of exceptions thrown in the class, and move the 2 final strings to some other class inside `java.security.sasl`.
>
> Seems like `com.sun.jndi.ldap.sasl.TlsChannelBinding` is not misplaced....

Okay, I'll look at doing this refactoring.

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

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

From michaelm at openjdk.java.net  Wed Jan 19 16:12:34 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 Jan 2022 16:12:34 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <zcX9AEY0fJWrhafcCtcfJGcPD141AU4nUROYyc962R4=.a308fa81-f431-4214-b1cc-2e35404c02a8@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
 <RJkqZt_IRcubmo9MB3ckW_iaD42MqeXWe4NNfFPSVGQ=.9942cc80-3cc3-4857-b7b5-3a6c92b74419@github.com>
 <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com>
 <w13AX0V232LPz-20aJTWS-8LEmevaRZq_xAtGr1hl70=.8d72bbfc-61de-41ec-92e7-128d9fab46a2@github.com>
 <OX6GdSlwuHddPP-t_uHnloRmDdl-C_iT6MJGfS8wSuc=.72586809-9def-4811-b5d0-ebb7f2285d10@github.com>
 <zcX9AEY0fJWrhafcCtcfJGcPD141AU4nUROYyc962R4=.a308fa81-f431-4214-b1cc-2e35404c02a8@github.com>
Message-ID: <0ebQZroTY3tTQW9cy5g6Y9yTK_nv6CBRtr-ne3tEF6k=.c4f10a2c-2ff8-452a-8cfb-cffedc5f0249@github.com>

On Wed, 19 Jan 2022 15:36:16 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>>> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file?
>> 
>> AFAICS this file documents properties used by the networking stack - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property)
>
> Okay, good idea to document it in the properties file. Also, I think "jdk.https.tls.cbt" is a reasonable name for the property.

Sorry, on reflection, something like "jdk.https.negotiate.cbt" might be better. There's no need for tls and https in the name and "negotiate" or "spnego" should be in it, but "negotiate" is probably better

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

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

From michaelm at openjdk.java.net  Wed Jan 19 17:12:31 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 Jan 2022 17:12:31 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
In-Reply-To: <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <BVAvIQFTb6kMxSjg3qAA2vOWGYlDDBEPmVjW277wPlc=.e1a0ea09-f74a-4e28-a27e-d926c4b5bf8b@github.com>
Message-ID: <4Tld3QrBk91X9ZBtF4Ad7DCiIfGD203YePBmy7FIAHs=.9964426c-6244-4818-8479-18044a833db1@github.com>

On Fri, 14 Jan 2022 15:06:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Have you been able to test this on a specific setup? Would be good to hear from @msheppar too.

I have tested it with the server setup by Prajwal. Security SQE are looking into configuring a server with a similar setup which can be tested with an infra test.

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

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

From mchung at openjdk.java.net  Wed Jan 19 20:07:09 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 19 Jan 2022 20:07:09 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
Message-ID: <z3wNTuRqh6xqhSfmAo0AObJfhLRnZNim12jMNwHKbzw=.867a929d-b7b6-4f80-a291-d34f84cc4cad@github.com>

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

Are all the proxy interfaces public?    The package in which a proxy class is created may be different depending if whether any proxy interface is in a non-exported and non-open package.   `com.sun.proxy.jdk.proxy*` is the package for non-exported proxy classes.  The proxy classes may be public in an unconditionally exported package [1] and its package name is `jdk.proxy*`.

[1] https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/reflect/Proxy.html#membership

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

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

From michaelm at openjdk.java.net  Wed Jan 19 22:20:47 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 Jan 2022 22:20:47 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v2]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  changes after first review round

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/853ed4db..f2ee58ec

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

  Stats: 111 lines in 7 files changed: 88 ins; 5 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From weijun at openjdk.java.net  Wed Jan 19 22:25:18 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 22:25:18 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
Message-ID: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>

Two edits.

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

Commit messages:
 - Another year
 - year
 - Update DigestMD5Base.java
 - 8279796: Fix typo: Constucts -> Constructs

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

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

From weijun at openjdk.java.net  Wed Jan 19 22:29:53 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 22:29:53 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v2]
In-Reply-To: <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com>
Message-ID: <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com>

On Wed, 19 Jan 2022 22:20:47 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes after first review round

src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133:

> 131:                                 (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE));
> 132:                 } catch (ChannelBindingException e) {
> 133:                     throw new SaslException(e.getMessage());

How about setting `e` as cause of new exception? In `TlsChannelBinding.java` the when the original exception was thrown (the 2nd throws) there was a cause.

src/java.security.jgss/share/classes/module-info.java line 36:

> 34: module java.security.jgss {
> 35:     requires java.naming;
> 36:     requires java.security.sasl;

Can this be removed now?

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

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

From iris at openjdk.java.net  Wed Jan 19 22:33:56 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 19 Jan 2022 22:33:56 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <QZIPAP3z8kRNlDUG-aLlymTH2SXuWfOh4WE7_Bpg_Ek=.b63864d3-5d10-4e30-b46c-c67a71668551@github.com>

On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two edits.

Marked as reviewed by iris (Reviewer).

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

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

From serb at openjdk.java.net  Wed Jan 19 23:00:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 19 Jan 2022 23:00:49 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <acD5yK0kHLAFm96czNrmeE1H6DR6r6Q4cnJFmjIBwCQ=.de776db1-5530-41f9-96a6-5135824b7a13@github.com>

On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two edits.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 727:

> 725:         Handler handler;
> 726:         /**
> 727:          * Constructs a {@code DoubleClickListener}.

This change is under review here:
https://github.com/openjdk/jdk/pull/7030

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

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

From weijun at openjdk.java.net  Wed Jan 19 23:00:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 23:00:49 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <acD5yK0kHLAFm96czNrmeE1H6DR6r6Q4cnJFmjIBwCQ=.de776db1-5530-41f9-96a6-5135824b7a13@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
 <acD5yK0kHLAFm96czNrmeE1H6DR6r6Q4cnJFmjIBwCQ=.de776db1-5530-41f9-96a6-5135824b7a13@github.com>
Message-ID: <vHf8vjRiyT8TSNblMHqMywc-qrubvuHhrFqTj9sEtPs=.f5d68326-fbe5-4d33-84e0-2a7c5bdcb93f@github.com>

On Wed, 19 Jan 2022 22:57:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Two edits.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 727:
> 
>> 725:         Handler handler;
>> 726:         /**
>> 727:          * Constructs a {@code DoubleClickListener}.
> 
> This change is under review here:
> https://github.com/openjdk/jdk/pull/7030

Oops, I'll remove mine. Thanks.

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

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

From weijun at openjdk.java.net  Wed Jan 19 23:10:31 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 23:10:31 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs [v2]
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <HkT457w3Vo_nMABn3BNAbp0DXj6kxUl1D1IzR-is5DA=.0b6ee4ac-0fa8-4b07-852e-429df3a057e5@github.com>

> Two edits.

Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - year
 - Update DigestMD5Base.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7147/files
  - new: https://git.openjdk.java.net/jdk/pull/7147/files/faec0c1d..6df9ccf8

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

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

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

From weijun at openjdk.java.net  Wed Jan 19 23:10:32 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 23:10:32 GMT
Subject: Integrated: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <BQbdDocyZyIxxXqYcZg4ENoDFrY8qACxp9o---bjydk=.4dfa7574-96e5-4598-8f75-3b379ae442ed@github.com>

On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two edits.

This pull request has now been integrated.

Changeset: 98d96a77
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98d96a770756ffe3e7f5e4b82120e9fb484cad9a
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8279796: Fix typo: Constucts -> Constructs

Reviewed-by: iris

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

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

From jwilhelm at openjdk.java.net  Thu Jan 20 00:40:42 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 20 Jan 2022 00:40:42 GMT
Subject: RFR: Merge jdk18
Message-ID: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl
 - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling
 - 8272058: 25 Null pointer dereference defect groups in 4 files
 - 8280234: AArch64 "core" variant does not build after JDK-8270947
 - 8280155: [PPC64, s390] frame size checks are not yet correct
 - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS
 - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE
 - 8278417: Closed test fails after JDK-8276108 on aarch64
 - 8274096: Improve decoding of image files
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/7151/files
  Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151

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

From jwilhelm at openjdk.java.net  Thu Jan 20 01:21:56 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 20 Jan 2022 01:21:56 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>
References: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>
Message-ID: <y0iAccUwe8WmPHsAzm9zEpWgdTLEzKLHEmBgkiWWrzc=.4fca1b0a-3f93-4ee9-9fc6-6835ebd6d041@github.com>

On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 4616c13c
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5
Stats:     1732 lines in 67 files changed: 933 ins; 606 del; 193 mod

Merge

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

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

From xuelei at openjdk.java.net  Thu Jan 20 07:18:04 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 20 Jan 2022 07:18:04 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in SSLParameters
Message-ID: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>

In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method.

The update is a minor correction so that the specification is not rely on the "protocols" variable.

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

Commit messages:
 - 8280363: Minor correction of ALPN specification in SSLParameters

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

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

From kevinw at openjdk.java.net  Thu Jan 20 09:08:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 20 Jan 2022 09:08:49 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <z3wNTuRqh6xqhSfmAo0AObJfhLRnZNim12jMNwHKbzw=.867a929d-b7b6-4f80-a291-d34f84cc4cad@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
 <z3wNTuRqh6xqhSfmAo0AObJfhLRnZNim12jMNwHKbzw=.867a929d-b7b6-4f80-a291-d34f84cc4cad@github.com>
Message-ID: <5JNsvlqfJc_a_svPZW2GONF6w1PoZlxRlRd2obiA8Os=.4e2df09c-10c9-473b-992d-abc28f931405@github.com>

On Wed, 19 Jan 2022 19:56:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Are all the proxy interfaces public?

sun.jvmstat.monitor.remote.RemoteVm is "public interface RemoteVm extends Remote" and methods in there only return basic types.
This is in the jdk.jstatd module, where I see the module info contains "exports sun.jvmstat.monitor.remote to java.rmi;"

The only other names permitted are proxy/reflect/rmi related.

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

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

From michaelm at openjdk.java.net  Thu Jan 20 10:58:27 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 20 Jan 2022 10:58:27 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  removed sasl module dependency and added SaslException cause

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/f2ee58ec..fd56b5e3

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

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

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

From michaelm at openjdk.java.net  Thu Jan 20 10:58:32 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 20 Jan 2022 10:58:32 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v2]
In-Reply-To: <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com>
 <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com>
Message-ID: <P6ZRNKGhR_TxnSzRElkHO9RYGtU8zlCq2zSAWpNWeSM=.360360d2-e0a5-443c-a52a-118d72f8aa7d@github.com>

On Wed, 19 Jan 2022 22:25:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes after first review round
>
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133:
> 
>> 131:                                 (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE));
>> 132:                 } catch (ChannelBindingException e) {
>> 133:                     throw new SaslException(e.getMessage());
> 
> How about setting `e` as cause of new exception? In `TlsChannelBinding.java` the when the original exception was thrown (the 2nd throws) there was a cause.

Agreed.

> src/java.security.jgss/share/classes/module-info.java line 36:
> 
>> 34: module java.security.jgss {
>> 35:     requires java.naming;
>> 36:     requires java.security.sasl;
> 
> Can this be removed now?

Yes, well spotted!

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

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

From duke at openjdk.java.net  Thu Jan 20 11:17:49 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 20 Jan 2022 11:17:49 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
Message-ID: <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com>

On Thu, 20 Jan 2022 10:58:27 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed sasl module dependency and added SaslException cause

src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133:

> 131:                                 (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE));
> 132:                 } catch (ChannelBindingException e) {
> 133:                     throw new SaslException(e.getMessage(), e);

Why not ust pass the exception if the API allows? This looks like message duplication.

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

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

From dfuchs at openjdk.java.net  Thu Jan 20 11:21:52 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 20 Jan 2022 11:21:52 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
Message-ID: <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>

On Thu, 20 Jan 2022 10:58:27 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed sasl module dependency and added SaslException cause

src/java.base/share/classes/java/net/doc-files/net-properties.html line 220:

> 218: 	This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos 
> 219:         or the Negotiate authentication scheme using Kerberos are employed over HTTPS with 
> 220:         {@code HttpURLConnection}. There are three possible settings:</P>

Should it be `{@code HttpsURLConnection}`?
(BTW - can we use {@code } here ? Would be worth checking the generated doc)

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189:

> 187:         } else {
> 188:             logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property");
> 189:             return s;

Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here.

src/java.base/share/classes/sun/security/util/ChannelBindingException.java line 31:

> 29:  * Thrown by TlsChannelBinding if an error occurs
> 30:  */
> 31: public class ChannelBindingException extends Exception {

Should this extend `GeneralSecurityException` instead? Or should we just remove this class and throw plain `GeneralSecurityException` in `TlsChannelBinding` ?

src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 143:

> 141:                             tlsCB = TlsChannelBinding.create(cert);
> 142:                         } catch (ChannelBindingException e) {
> 143:                             throw new SaslException(e.getMessage());

Why is there a difference compared to line 133?

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

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

From dfuchs at openjdk.java.net  Thu Jan 20 12:12:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 20 Jan 2022 12:12:49 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters
In-Reply-To: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
Message-ID: <UTCj-oV0ocUHvZhMioKhkhsvH595dapJIzaFLPC3Jtk=.789fb2b3-0b87-441b-9a5f-6f15ac245507@github.com>

On Thu, 20 Jan 2022 07:12:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method.
> 
> The update is a minor correction so that the specification is not rely on the "protocols" variable.

Marked as reviewed by dfuchs (Reviewer).

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

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

From mullan at openjdk.java.net  Thu Jan 20 14:19:56 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 20 Jan 2022 14:19:56 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters
In-Reply-To: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
Message-ID: <C27FuQMOq-laAJtCkChiIuidkMEcIptCu7eRXOgNZCY=.f6285ddb-0463-489f-8711-97468c1add2e@github.com>

On Thu, 20 Jan 2022 07:12:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method.
> 
> The update is a minor correction so that the specification is not rely on the "protocols" variable.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 619:

> 617:      *
> 618:      * @return a non-null, possibly zero-length array of application protocol
> 619:      *         {@code String}s.  The array is placed in descending order of

The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred."

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

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

From xuelei at openjdk.java.net  Thu Jan 20 14:46:28 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 20 Jan 2022 14:46:28 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters [v2]
In-Reply-To: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
Message-ID: <m4QJ_pJL8mPclx-GQQMnOMvO6fJHcGHLovhTEYytqe0=.eb07b3ec-e060-4899-9416-c4cc780cccac@github.com>

> In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method.
> 
> The update is a minor correction so that the specification is not rely on the "protocols" variable.

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.java.net/jdk/pull/7152/files
  - new: https://git.openjdk.java.net/jdk/pull/7152/files/c16bf6c6..3992327e

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

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

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

From xuelei at openjdk.java.net  Thu Jan 20 14:46:30 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 20 Jan 2022 14:46:30 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters [v2]
In-Reply-To: <C27FuQMOq-laAJtCkChiIuidkMEcIptCu7eRXOgNZCY=.f6285ddb-0463-489f-8711-97468c1add2e@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
 <C27FuQMOq-laAJtCkChiIuidkMEcIptCu7eRXOgNZCY=.f6285ddb-0463-489f-8711-97468c1add2e@github.com>
Message-ID: <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com>

On Thu, 20 Jan 2022 14:16:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update per feedback
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 619:
> 
>> 617:      *
>> 618:      * @return a non-null, possibly zero-length array of application protocol
>> 619:      *         {@code String}s.  The array is placed in descending order of
> 
> The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred."

Hm, much better.  Thanks!

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

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

From mullan at openjdk.java.net  Thu Jan 20 15:04:48 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 20 Jan 2022 15:04:48 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters [v2]
In-Reply-To: <m4QJ_pJL8mPclx-GQQMnOMvO6fJHcGHLovhTEYytqe0=.eb07b3ec-e060-4899-9416-c4cc780cccac@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
 <m4QJ_pJL8mPclx-GQQMnOMvO6fJHcGHLovhTEYytqe0=.eb07b3ec-e060-4899-9416-c4cc780cccac@github.com>
Message-ID: <FJhsHbDFOnhTDsDgMeYaxb7ZLXS98OZKSPYklz7J00M=.9e3f4a83-2c3f-418e-8fa6-6a3323d858ce@github.com>

On Thu, 20 Jan 2022 14:46:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method.
>> 
>> The update is a minor correction so that the specification is not rely on the "protocols" variable.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update per feedback

Marked as reviewed by mullan (Reviewer).

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

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

From dfuchs at openjdk.java.net  Thu Jan 20 15:34:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 20 Jan 2022 15:34:49 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters [v2]
In-Reply-To: <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
 <C27FuQMOq-laAJtCkChiIuidkMEcIptCu7eRXOgNZCY=.f6285ddb-0463-489f-8711-97468c1add2e@github.com>
 <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com>
Message-ID: <QsOyMHW_i3Jk4QuGTvx6QMkfU9Z0eDTtarFyNB_5TF8=.950efc3e-c4b5-4247-9f85-47343d3308b5@github.com>

On Thu, 20 Jan 2022 14:42:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 619:
>> 
>>> 617:      *
>>> 618:      * @return a non-null, possibly zero-length array of application protocol
>>> 619:      *         {@code String}s.  The array is placed in descending order of
>> 
>> The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred."
>
> Hm, much better.  Thanks!

> The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred."

Thanks Sean - I had the same comment - but for some reason it seemed to have been lost when I clicked on Approve. Not sure what happened to it :-(

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

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

From xuelei at openjdk.java.net  Thu Jan 20 16:53:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 20 Jan 2022 16:53:56 GMT
Subject: Integrated: 8280363: Minor correction of ALPN specification in
 SSLParameters
In-Reply-To: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
Message-ID: <p6KSyx2zCd-zGhErwwzW4_hG7HY1hGrFuD3lCuE8rTo=.2592b7d4-a18f-476f-8b9b-668e6a8b9660@github.com>

On Thu, 20 Jan 2022 07:12:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the getApplicationProtocols() method in javax.net.ssl.SSLParameters, the return statement says that "The array is ordered based on protocol preference, with protocols[0] being the most preferred.". However, there is no "protocols" variable in this method.
> 
> The update is a minor correction so that the specification is not rely on the "protocols" variable.

This pull request has now been integrated.

Changeset: 0ea2b390
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ea2b39035f1b535a53770379c94ae43f0ddb8b6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8280363: Minor correction of ALPN specification in SSLParameters

Reviewed-by: dfuchs, mullan

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

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

From xuelei at openjdk.java.net  Thu Jan 20 16:53:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 20 Jan 2022 16:53:55 GMT
Subject: RFR: 8280363: Minor correction of ALPN specification in
 SSLParameters [v2]
In-Reply-To: <QsOyMHW_i3Jk4QuGTvx6QMkfU9Z0eDTtarFyNB_5TF8=.950efc3e-c4b5-4247-9f85-47343d3308b5@github.com>
References: <cY04lpD7sFflEyNY6Wy86e8CB46-TlNrjvTA-Fw_tak=.fb200609-2c3e-4857-8301-18049cfe6bc7@github.com>
 <C27FuQMOq-laAJtCkChiIuidkMEcIptCu7eRXOgNZCY=.f6285ddb-0463-489f-8711-97468c1add2e@github.com>
 <_hLkcz7xXhbTCncbvGNP27hqPXMLiIFiKHQTZkB71gI=.43616986-9482-481c-af22-daa80cfb2f5d@github.com>
 <QsOyMHW_i3Jk4QuGTvx6QMkfU9Z0eDTtarFyNB_5TF8=.950efc3e-c4b5-4247-9f85-47343d3308b5@github.com>
Message-ID: <ORGHvWVPLJ2yDS10gEQgR79V6PLQQTO6HvrvBMstn3s=.3a7a613f-fa1d-47ef-9b21-26e41ca1b0ae@github.com>

On Thu, 20 Jan 2022 15:31:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hm, much better.  Thanks!
>
>> The phrase "descending order" seems more appropriate for numerical values. I think the previous wording was more clear, with a small change: "The array is ordered based on protocol preference, with the first entry being the most preferred."
> 
> Thanks Sean - I had the same comment - but for some reason it seemed to have been lost when I clicked on Approve. Not sure what happened to it :-(

Thank you!

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

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

From mchung at openjdk.java.net  Thu Jan 20 16:57:57 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Jan 2022 16:57:57 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
Message-ID: <BDpQcwf5mRXHd4RnwTnEEO9li6HXe-jYHRlfVQtorYY=.a49a9fe1-55c4-4f2e-88b9-9cf025921a06@github.com>

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

If `sun.jvmstat.monitor.remote.RemoteVm` is the only proxy interface, `com.sun.proxy.jdk.proxy*` should adequately cover the proxy classes created for `RemoteVm`.

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

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

From weijun at openjdk.java.net  Thu Jan 20 18:26:13 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 Jan 2022 18:26:13 GMT
Subject: RFR: 8280401: [sspi] gss_accept_sec_context leaves output_token
 uninitialized
Message-ID: <FQRnzCKVydo081_wEQmZ2V3pWejyJJ-gN_sF79KJxPU=.fdb2d8e9-fa1f-40d6-9033-fa4c82d5ed70@github.com>

Set `output_token` to empty. It is always accessed (even for a `GSS_S_FAILURE`) at https://github.com/openjdk/jdk/blob/cfa3f7493149170f2b23a516bc95110dab43fd06/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c#L1160.

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

Commit messages:
 - 8280401: [sspi] gss_accept_sec_context leaves output_token uninitialized

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

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

From weijun at openjdk.java.net  Thu Jan 20 19:51:19 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 Jan 2022 19:51:19 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate#getSubjectAlternativeNames() in otherName
Message-ID: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>

The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.

It also fix several errors:
1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

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

Commit messages:
 - 8277976: Break up SEQUENCE in X509Certiticate#getSubjectAlternativeNames() in otherName

Changes: https://git.openjdk.java.net/jdk/pull/7167/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277976
  Stats: 136 lines in 4 files changed: 117 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

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

From mstjohns at comcast.net  Thu Jan 20 19:56:37 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 20 Jan 2022 14:56:37 -0500
Subject: =?UTF-8?Q?Re=3a_RFR=3a_8255739=3a_x509Certificate_returns_=ef=bf=bd?=
 =?UTF-8?Q?_for_invalid_subjectAlternativeNames?=
In-Reply-To: <9KbehHQkYt97fRvntUumETKjqIr97U-tp9FqEVuDMWs=.c40ceda1-3a60-48b5-a1af-814523e010f2@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <af7C2TFYwcldrmahOFKvHuzVsmVmxJ1wAUJi9drMEMA=.cb6a9ccf-69fa-4748-9dea-dd1f8af2a9f1@github.com>
 <9KbehHQkYt97fRvntUumETKjqIr97U-tp9FqEVuDMWs=.c40ceda1-3a60-48b5-a1af-814523e010f2@github.com>
Message-ID: <c977ca51-4c09-7bc6-5086-e1ee7086d481@comcast.net>

On 1/18/2022 4:10 PM, Sean Mullan wrote:
> On Thu, 6 Jan 2022 20:28:22 GMT, Sean Mullan<mullan at openjdk.org>  wrote:
>
>>> Could you please review the JDK-8255739 bug fix?
>>>
>>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>>>
>>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>> I understand the reasons for making the code more robust and detecting invalid DER encodings, but this may have a non-trivial compatibility risk. In general, I think detecting invalid encodings is generally the right thing to do, but compatibility needs to be considered. Sometimes other implementations have encoding bugs that we need to workaround, etc. This change affects not only certificates but other security components that use DER in the JDK. Certificates already treat non-critical extensions that are badly encoded as not a failure, so there is some compatibility built-in already. But I think it makes sense to look at other code that calls into the DerValue methods and evaluate the potential compatibility risk. At a minimum, a CSR must be filed. As a compromise, it may make sense to (at least initially) reduce the compatibility risk by allowing the caller (ex: `sun.security.x509.DNSName`) to decide if it wants a stricter parsing of the DER-encoded string.
>>
>> I would like @wangweij or @valeriepeng to also review this.
>>
>> With respect to the test, it seems like overkill to launch a java process inside the test to run each test. Instead, I would just have separate methods for each test and run them in the same process as the main test.
>> @seanjmullan @wangweij I have commented on what you pointed out, so could you please reply?
> I need another couple of days to look at this issue again before I can reply.
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/6928

Hi -

Bouncycastle started enforcing properly encoded? INTEGERs a while back 
and that caused one of my programs to start failing due to a TPM X509 
endorsement certificate just having the TPM serial number stuffed into 
the certificate serial number without normalizing it to the appropriate 
INTEGER encoding.? BC provided a work around (setting 
"org.bouncycastle.asn1.allow_unsafe_integer") which gave me time to 
re-code around the problem.? If you're going to break things, it may be 
useful to provide a work around similar to what they did.

In any event, DerValue.java uses "new String(byteArrayValue, 
charsetType)" to produce the various String values including in 
getIA5String().? I.e.,

> public?String(byte[]?bytes,
>                Charset ?charset)
> Constructs a new |String| by decoding the specified array of bytes 
> using the specified charset. The length of the new |String| is a 
> function of the charset, and hence may not be equal to the length of 
> the byte array.
>
> _*This method always replaces malformed-input and unmappable-character 
> sequences with this charset's default replacement string.*_ The 
> |CharsetDecoder| class should be used when more control over the 
> decoding process is required.
>
Perhaps it might make sense to update the various places where this is 
used in DerValue to CharsetDecoder and to use 
charsetDecoder.onMalformedInput() and 
charsetDecoder.onUnmappableCharacter() to set the appropriate action 
related to parsing the byte array into a String of a given charset?? 
That action could be set based on the presence of the bypass property.

I don't think the change as proposed is backward-compatible safe enough, 
nor does it really address the general issue of poorly encoded DER 
String values in a certificate.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220120/6d31869b/attachment.htm>

From kevinw at openjdk.java.net  Thu Jan 20 20:37:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 20 Jan 2022 20:37:55 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <BDpQcwf5mRXHd4RnwTnEEO9li6HXe-jYHRlfVQtorYY=.a49a9fe1-55c4-4f2e-88b9-9cf025921a06@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
 <BDpQcwf5mRXHd4RnwTnEEO9li6HXe-jYHRlfVQtorYY=.a49a9fe1-55c4-4f2e-88b9-9cf025921a06@github.com>
Message-ID: <zbUWHoAkBqewOKCUFusXibbOb0Si-T2aETzzBluc5ts=.a5f3d744-ad23-4e2d-9d96-6e258f6e75f1@github.com>

On Thu, 20 Jan 2022 16:54:21 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> If `sun.jvmstat.monitor.remote.RemoteVm` is the only proxy interface, `com.sun.proxy.jdk.proxy*` should adequately cover the proxy classes created for `RemoteVm`.

Thanks.  With that endorsement I think there are no unresolved issues with this change.

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

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

From valeriep at openjdk.java.net  Fri Jan 21 01:25:44 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 21 Jan 2022 01:25:44 GMT
Subject: RFR: 8280401: [sspi] gss_accept_sec_context leaves output_token
 uninitialized
In-Reply-To: <FQRnzCKVydo081_wEQmZ2V3pWejyJJ-gN_sF79KJxPU=.fdb2d8e9-fa1f-40d6-9033-fa4c82d5ed70@github.com>
References: <FQRnzCKVydo081_wEQmZ2V3pWejyJJ-gN_sF79KJxPU=.fdb2d8e9-fa1f-40d6-9033-fa4c82d5ed70@github.com>
Message-ID: <Tpc62fPjnvnD5MfGjsotMBXwqaz6wRAuLOd9n6un8H4=.15665e95-355c-4c0c-ac82-2d6fa3d560db@github.com>

On Thu, 20 Jan 2022 18:19:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Set `output_token` to empty. It is always accessed (even for a `GSS_S_FAILURE`) at https://github.com/openjdk/jdk/blob/cfa3f7493149170f2b23a516bc95110dab43fd06/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c#L1160.

Changes look good. Remember to add the noreg-xxx label. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

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

From weijun at openjdk.java.net  Fri Jan 21 03:19:50 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 Jan 2022 03:19:50 GMT
Subject: Integrated: 8280401: [sspi] gss_accept_sec_context leaves output_token
 uninitialized
In-Reply-To: <FQRnzCKVydo081_wEQmZ2V3pWejyJJ-gN_sF79KJxPU=.fdb2d8e9-fa1f-40d6-9033-fa4c82d5ed70@github.com>
References: <FQRnzCKVydo081_wEQmZ2V3pWejyJJ-gN_sF79KJxPU=.fdb2d8e9-fa1f-40d6-9033-fa4c82d5ed70@github.com>
Message-ID: <UJn-yHQRlKAIsqWUnGc_XkNy5OTJoYvPisDTyw99sFU=.32e4028c-f191-455b-9c69-9f0f4d0d8904@github.com>

On Thu, 20 Jan 2022 18:19:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Set `output_token` to empty. It is always accessed (even for a `GSS_S_FAILURE`) at https://github.com/openjdk/jdk/blob/cfa3f7493149170f2b23a516bc95110dab43fd06/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c#L1160.

This pull request has now been integrated.

Changeset: 6352c020
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6352c020c25f2701afb4fabee0cc7fcef2d407fb
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8280401: [sspi] gss_accept_sec_context leaves output_token uninitialized

Reviewed-by: valeriep

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

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

From hchao at openjdk.java.net  Fri Jan 21 03:34:24 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 21 Jan 2022 03:34:24 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v2]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <iT5xQXLzvR8p2zSMomw2JNYzJAtP_IYKxS7NEdcwVc8=.231c7264-6a4d-4c93-95ac-7712f2358980@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Update with review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/10e73e50..a05728a7

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

  Stats: 60 lines in 3 files changed: 20 ins; 11 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7039/head:pull/7039

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

From hchao at openjdk.java.net  Fri Jan 21 03:34:31 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 21 Jan 2022 03:34:31 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v2]
In-Reply-To: <LmrGR5tsT3fv0Ftg8aS6hYGbQJPCgX4UX9LPhFXkeB0=.0ed97028-2956-48ed-876e-7a39abeb12eb@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <LmrGR5tsT3fv0Ftg8aS6hYGbQJPCgX4UX9LPhFXkeB0=.0ed97028-2956-48ed-876e-7a39abeb12eb@github.com>
Message-ID: <-SGqQxfBady_OL-XCjP9_rUe3HlF2gjXKjm4DQDDc08=.23163daf-34ee-4cd1-a373-0ca71736c50f@github.com>

On Thu, 13 Jan 2022 16:31:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with review comments
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 187:
> 
>> 185:     private List<String> weakWarnings = new ArrayList<>();
>> 186: 
>> 187:     Set<X509Certificate> trustedCerts = new HashSet<>();
> 
> Make private.

Fixed.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1129:
> 
>> 1127:         }
>> 1128: 
>> 1129:         buildTrustedCerts();
> 
> Can we reuse the keystore loaded by `buildTrustedCerts()` instead of reloading it again on line 1138?

No change. This is because `caks` global variable can only be initialized with cacerts keystore  when the `trustcacerts` option is specified; otherwise if has to be kept null. `buildTrustedCerts`() is always executed.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1558:
> 
>> 1556:         checkWeakConstraint(rb.getString("the.issuer"),
>> 1557:                 keyStore.getCertificateChain(alias));
>> 1558:         cpcp = new CertPathConstraintsParameters(cert, null, null, null);
> 
> You could also specify the variant parameter if the certificate contains an EKU extension. The mapping from EKU to variant would be:
> 
> - anyExtendedKeyUsage -> VAR_GENERIC
> - serverAuth -> VAR_TLS_SERVER
> - clientAuth -> VAR_TLS_CLIENT
> - codeSigning -> VAR_CODE_SIGNING
> - emailProtection -> none defined, so just use null or VAR_GENERIC
> - timeStamping -> VAR_TSA_SERVER
> - OCSPSigning -> none defined, so just use null or VAR_GENERIC

Fixed.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1706:
> 
>> 1704:         }
>> 1705:         dumpCert(cert, out);
>> 1706:         CertPathConstraintsParameters cpcp =
> 
> Here you could also specify the variant if the cert contains an EKU extension. Same comment applies to other places where you are checking the algorithm constraints of a certificate.

Fixed.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2198:
> 
>> 2196:                         ("Certificate.chain.length.") + chain.length);
>> 2197: 
>> 2198:                     X509Certificate[] xcerts = convertCerts(chain);
> 
> I think you can just cast to an `X509Certificate[]` instead of reparsing all the certificates, i.e.:
> 
> `X509Certificate[] xcerts = (X509Certificate[]) chain;`

I got `java.lang.ClassCastException` when casting `Certificate[]` array form here. However, I should cast Certificate object directly instead of reparsing the certificate, and made the change to do so.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2259:
> 
>> 2257:             }
>> 2258:             cpcp = new CertPathConstraintsParameters((X509Certificate)cert,
>> 2259:                     null,null, null);
> 
> Nit - add space between `null,null`.

Fixed.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5039:
> 
>> 5037:                         trustedCerts.add((X509Certificate)caks.getCertificate(a));
>> 5038:                     } catch (Exception e2) {
>> 5039:                         // ignore, when a SecretkeyEntry does not include a cert
> 
> Not sure I understand this comment, as these should not be SecretKeyEntries. You should still ignore it but this should not throw an Exception unless the KeyStore was not loaded/initialized properly (which normally won't occur).

Updated with the suggested comments.

> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5048:
> 
>> 5046:     }
>> 5047: 
>> 5048:     private TrustAnchor findTrustAnchor(List<X509Certificate> chain) {
> 
> I would consider having an initial check that returns `null` if `chain.isEmpty()`. Not sure if that is a valid scenario, but it would avoid an `IndexOOBException` just in case.

Added the initial check.

> src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 486:
> 
>> 484:         {"verified.by.s.in.s.weak", "Verified by %1$s in %2$s with a %3$s"},
>> 485:         {"whose.sigalg.disabled", "%1$s uses the %2$s signature algorithm which is considered a security risk and is disabled."},
>> 486:         {"whose.sigalg.usagesignedjar", "%1$s uses the %2$s signature algorithm which is considered a security risk and cannot be used to sign JARs after 2019-01-01."},
> 
> Instead of hard-coding "2019-01-01", we should extract this date from the `denyAfter` attribute of the `jdk.certpath.disabledAlgorithms` security property and pass it in as a parameter.

Fixed.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 13:41:54 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 13:41:54 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>
Message-ID: <joA0GLey_SFQeUinpgYprGKus4D0MPP_lgBMq-01F8I=.a2fc4e82-6140-4b0c-a786-e77267cfca23@github.com>

On Thu, 20 Jan 2022 11:04:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed sasl module dependency and added SaslException cause
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 220:
> 
>> 218: 	This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos 
>> 219:         or the Negotiate authentication scheme using Kerberos are employed over HTTPS with 
>> 220:         {@code HttpURLConnection}. There are three possible settings:</P>
> 
> Should it be `{@code HttpsURLConnection}`?
> (BTW - can we use {@code } here ? Would be worth checking the generated doc)

Right HttpsURLConnection is better. {@code} works here.

> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189:
> 
>> 187:         } else {
>> 188:             logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property");
>> 189:             return s;
> 
> Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here.

It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 13:41:55 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 13:41:55 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com>
Message-ID: <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com>

On Thu, 20 Jan 2022 11:14:40 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed sasl module dependency and added SaslException cause
>
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133:
> 
>> 131:                                 (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE));
>> 132:                 } catch (ChannelBindingException e) {
>> 133:                     throw new SaslException(e.getMessage(), e);
> 
> Why not ust pass the exception if the API allows? This looks like message duplication.

Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 14:14:33 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 14:14:33 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>
Message-ID: <q7oEmk2H4MWhRcFGZ9QMOjhADBXiXL6hTOtHfYK01oM=.7c0a74c4-d165-40ef-b93a-954dd53ea6cd@github.com>

On Thu, 20 Jan 2022 11:16:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed sasl module dependency and added SaslException cause
>
> src/java.base/share/classes/sun/security/util/ChannelBindingException.java line 31:
> 
>> 29:  * Thrown by TlsChannelBinding if an error occurs
>> 30:  */
>> 31: public class ChannelBindingException extends Exception {
> 
> Should this extend `GeneralSecurityException` instead? Or should we just remove this class and throw plain `GeneralSecurityException` in `TlsChannelBinding` ?

I think a distinct exception is necessary. I don't have a strong opinion on whether it should extend GeneralSecurityException.

> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 143:
> 
>> 141:                             tlsCB = TlsChannelBinding.create(cert);
>> 142:                         } catch (ChannelBindingException e) {
>> 143:                             throw new SaslException(e.getMessage());
> 
> Why is there a difference compared to line 133?

Right, that was a mistake.

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

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

From duke at openjdk.java.net  Fri Jan 21 14:14:45 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Fri, 21 Jan 2022 14:14:45 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com>
 <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com>
Message-ID: <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com>

On Fri, 21 Jan 2022 13:35:53 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133:
>> 
>>> 131:                                 (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE));
>>> 132:                 } catch (ChannelBindingException e) {
>>> 133:                     throw new SaslException(e.getMessage(), e);
>> 
>> Why not ust pass the exception if the API allows? This looks like message duplication.
>
> Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception.

`NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 15:11:42 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 15:11:42 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <joA0GLey_SFQeUinpgYprGKus4D0MPP_lgBMq-01F8I=.a2fc4e82-6140-4b0c-a786-e77267cfca23@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>
 <joA0GLey_SFQeUinpgYprGKus4D0MPP_lgBMq-01F8I=.a2fc4e82-6140-4b0c-a786-e77267cfca23@github.com>
Message-ID: <bTeAlzr6DoYXdaSW7Zl8h9NF0xQ1VuubuocU-ZGIWJk=.d7d6511e-cb2a-4fe6-be2e-fb561d178b92@github.com>

On Fri, 21 Jan 2022 13:38:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189:
>> 
>>> 187:         } else {
>>> 188:             logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property");
>>> 189:             return s;
>> 
>> Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here.
>
> It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here.

Sorry, I should have checked back to the source rather than the snippet quoted. The problem is that the logError call is in the wrong place. It should be before line 186.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 15:26:33 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 15:26:33 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v4]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <pPi2071GA2RfXbIIWVg1j-HBMeznqsxXkh8dsc-UXA0=.e0bfd98a-4c22-4fe7-8f27-7d55b97ed7f4@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  more tidy-up

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/fd56b5e3..c9975fd1

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

  Stats: 12 lines in 4 files changed: 5 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From dfuchs at openjdk.java.net  Fri Jan 21 15:35:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 Jan 2022 15:35:43 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <bTeAlzr6DoYXdaSW7Zl8h9NF0xQ1VuubuocU-ZGIWJk=.d7d6511e-cb2a-4fe6-be2e-fb561d178b92@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <EbjdtLIAQ6karFG3S0qS48aa1D22QUEo6OtLNksG2Tc=.cfe2da51-4780-4dd3-b77f-9fad8aada2e0@github.com>
 <joA0GLey_SFQeUinpgYprGKus4D0MPP_lgBMq-01F8I=.a2fc4e82-6140-4b0c-a786-e77267cfca23@github.com>
 <bTeAlzr6DoYXdaSW7Zl8h9NF0xQ1VuubuocU-ZGIWJk=.d7d6511e-cb2a-4fe6-be2e-fb561d178b92@github.com>
Message-ID: <dXKGM82g_lj8dGyyGKTguX_6WKw-eQ9emSy_6rCTlo4=.c1b4f22c-b373-4530-ab41-0563e50122ab@github.com>

On Fri, 21 Jan 2022 15:08:58 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here.
>
> Sorry, I should have checked back to the source rather than the snippet quoted. The problem is that the logError call is in the wrong place. It should be before line 186. Though some other adjustments are also required

Ah! Yes - I was also bitten again by the negation in the `if` too.
The presence of `logError` in the body of the `if` will make it clearer :-)

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

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

From dfuchs at openjdk.java.net  Fri Jan 21 15:35:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 Jan 2022 15:35:44 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v4]
In-Reply-To: <pPi2071GA2RfXbIIWVg1j-HBMeznqsxXkh8dsc-UXA0=.e0bfd98a-4c22-4fe7-8f27-7d55b97ed7f4@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pPi2071GA2RfXbIIWVg1j-HBMeznqsxXkh8dsc-UXA0=.e0bfd98a-4c22-4fe7-8f27-7d55b97ed7f4@github.com>
Message-ID: <7Zv8iD7zLtr7WSXkcyMCSnG6aHOLuEH7GOWsrmNTvTs=.f88978ea-ddb9-4c78-8634-f762071e4ec9@github.com>

On Fri, 21 Jan 2022 15:26:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more tidy-up

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 191:

> 189:         } else {
> 190:             logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property");
> 191:             return "never";

Much easier to review now :-)

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

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

From dfuchs at openjdk.java.net  Fri Jan 21 15:43:47 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 Jan 2022 15:43:47 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v4]
In-Reply-To: <pPi2071GA2RfXbIIWVg1j-HBMeznqsxXkh8dsc-UXA0=.e0bfd98a-4c22-4fe7-8f27-7d55b97ed7f4@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pPi2071GA2RfXbIIWVg1j-HBMeznqsxXkh8dsc-UXA0=.e0bfd98a-4c22-4fe7-8f27-7d55b97ed7f4@github.com>
Message-ID: <cnDXcxorLTg6piimkQJO4CxXotTVhsZOevNNjdfbwUI=.f427c695-6989-41d1-ab18-aefce338fb00@github.com>

On Fri, 21 Jan 2022 15:26:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more tidy-up

Marked as reviewed by dfuchs (Reviewer).

src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144:

> 142:                         } catch (ChannelBindingException e) {
> 143:                             throw new NamingException(e.getMessage());
> 144:                         }

Should we call initCause here and above? I see that we do call initCause in NegotiatorImpl.java.
On the one hand it's better for diagnostic. On the other hand it exposes a module-internal exception class which is not great. Or maybe we should set the cause of the CBE as the cause of NamingException.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 15:54:59 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 15:54:59 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com>
 <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com>
 <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com>
Message-ID: <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com>

On Fri, 21 Jan 2022 13:39:06 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception.
>
> `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained.

Yes, I can do that. Though it will cause the existing LDAP channel binding test to fail which is checking for an empty root cause. That is checking unspecified behavior and I can change it to check for a `ChannelBindingException` as root cause. So long as we are okay having a non public exception type as the root cause, it's probably helpful to have the full stack there.

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

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

From michaelm at openjdk.java.net  Fri Jan 21 16:02:29 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 21 Jan 2022 16:02:29 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v5]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  added root cause to NamingException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/c9975fd1..058c3830

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

  Stats: 16 lines in 2 files changed: 8 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From duke at openjdk.java.net  Fri Jan 21 16:02:31 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Fri, 21 Jan 2022 16:02:31 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v3]
In-Reply-To: <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <GCe0rIoYQTcKyPdnlgH-3L8VdKBTZIDKXC-krQQkA58=.0242ce06-1750-407d-8ff0-61670ce6dab9@github.com>
 <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com>
 <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com>
 <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com>
 <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com>
Message-ID: <HxBrh-0MosMR9KKVCGFqU7pVyBOn_wH1jv7zYMmHzTA=.48f98e0b-8ff2-4f10-a932-3b7d94038e60@github.com>

On Fri, 21 Jan 2022 15:51:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained.
>
> Yes, I can do that. Though it will cause the existing LDAP channel binding test to fail which is checking for an empty root cause. That is checking unspecified behavior and I can change it to check for a `ChannelBindingException` as root cause. So long as we are okay having a non public exception type as the root cause, it's probably helpful to have the full stack there.

Yes please retain as much information as possible.

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

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

From mullan at openjdk.java.net  Fri Jan 21 16:33:43 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 21 Jan 2022 16:33:43 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames [v2]
In-Reply-To: <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
Message-ID: <X4-zHSGywbQLQTZHZ443XVnoJI15S5hlYT840pNQDHM=.9924f8f5-c253-448f-97a5-d5fc2700e72c@github.com>

On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the JDK-8255739 bug fix?
>> 
>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>> 
>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255739: x509Certificate returns ? for invalid subjectAlternativeNames

> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
> 
> On 1/18/2022 4:10 PM, Sean Mullan wrote:
> 
> Hi -
> 
> Bouncycastle started enforcing properly encoded? INTEGERs a while back and that caused one of my programs to start failing due to a TPM X509 endorsement certificate just having the TPM serial number stuffed into the certificate serial number without normalizing it to the appropriate INTEGER encoding.? BC provided a work around (setting "org.bouncycastle.asn1.allow_unsafe_integer") which gave me time to re-code around the problem.? If you're going to break things, it may be useful to provide a work around similar to what they did.

Do you know the behavior of the JDK X.509 CertificateFactory implementation? Did it accept or reject this serial number?

> In any event, DerValue.java uses "new String(byteArrayValue, charsetType)" to produce the various String values including in getIA5String().? I.e.,
> 
> > public?String(byte[]?bytes,
> > Charset ?charset)
> > Constructs a new |String| by decoding the specified array of bytes
> > using the specified charset. The length of the new |String| is a
> > function of the charset, and hence may not be equal to the length of
> > the byte array.
> > _*This method always replaces malformed-input and unmappable-character
> > sequences with this charset's default replacement string.*_ The
> > |CharsetDecoder| class should be used when more control over the
> > decoding process is required.
> 
> Perhaps it might make sense to update the various places where this is used in DerValue to CharsetDecoder and to use charsetDecoder.onMalformedInput() and charsetDecoder.onUnmappableCharacter() to set the appropriate action related to parsing the byte array into a String of a given charset?? That action could be set based on the presence of the bypass property.

I believe that was originally suggested by the submitter as a potential solution. But it doesn't seem like it is that useful or there would be much demand for this.

> I don't think the change as proposed is backward-compatible safe enough, nor does it really address the general issue of poorly encoded DER String values in a certificate.

Yes, I have come to the conclusion that this is probably too risky to fix. An application that is depending on a DNSName should be doing additional matching checks to verify that the structure of the name is correct, and it doesn't violate other types of rules, such as wildcards involving public suffixes, etc. (The JDK code does these additional checks when verifying TLS server certificates).

See also https://groups.google.com/g/mozilla.dev.security.policy/c/Av6oZxbjvB4/m/NW6lGkgYBwAJ and the linked report of various anomalies in commonNames and Subject Alternative Names in server auth certificates issued by public CAs.

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

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

From dfuchs at openjdk.java.net  Fri Jan 21 17:53:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 Jan 2022 17:53:44 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v5]
In-Reply-To: <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
Message-ID: <lgSw6thPgaQEfgwxWx4nCsoxGoI7_Jmu3QiaJl57few=.79e357a8-d2da-400d-81c4-82a04997b4b9@github.com>

On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added root cause to NamingException

Marked as reviewed by dfuchs (Reviewer).

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

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

From weijun at openjdk.java.net  Fri Jan 21 19:51:12 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 Jan 2022 19:51:12 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v5]
In-Reply-To: <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
Message-ID: <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com>

On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added root cause to NamingException

src/java.base/share/classes/java/net/doc-files/net-properties.html line 220:

> 218: 	This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos 
> 219:         or the Negotiate authentication scheme using Kerberos are employed over HTTPS with 
> 220:         {@code HttpsURLConnection}. There are three possible settings:</P>

You can probably mention here that the 'tls-server-end-point' Channel Binding Type defined in RFC 5929 is used.

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

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

From weijun at openjdk.java.net  Fri Jan 21 19:59:25 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 Jan 2022 19:59:25 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v5]
In-Reply-To: <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
Message-ID: <7hhc0sEj6x1SvXw2uNKpTvyM4Ye65jpUdYTF1IV8dz8=.65223e7a-defb-4737-be99-f3d14bf153af@github.com>

On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added root cause to NamingException

Please move

    // TLS channel binding type property
    public static final String CHANNEL_BINDING_TYPE =
            "com.sun.jndi.ldap.tls.cbtype";
    // internal TLS channel binding property
    public static final String CHANNEL_BINDING =
            "jdk.internal.sasl.tlschannelbinding";

outside of the `TlsChannelBinding` class.

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

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

From aturbanov at openjdk.java.net  Sat Jan 22 14:00:11 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 22 Jan 2022 14:00:11 GMT
Subject: Integrated: 8275918: Remove unused local variables in java.base
 security code
In-Reply-To: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
References: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
Message-ID: <uG_sQzIdnzZ8-179KzmuizveYAjzRpxXboc3HagRWvE=.bae807d0-3b83-4ff9-8178-16bf8ef8bd1a@github.com>

On Sat, 23 Oct 2021 14:04:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Cleanup unused local variables. Looks like they are leftovers after refactoring.

This pull request has now been integrated.

Changeset: 54c9de26
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/54c9de26aba24ff5496f97dd6cb95075ab6b9777
Stats:     31 lines in 13 files changed: 0 ins; 17 del; 14 mod

8275918: Remove unused local variables in java.base security code

Reviewed-by: weijun

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

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

From mstjohns at comcast.net  Sat Jan 22 22:46:18 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Sat, 22 Jan 2022 17:46:18 -0500
Subject: =?UTF-8?Q?Re=3a_RFR=3a_8255739=3a_x509Certificate_returns_=ef=bf=bd?=
 =?UTF-8?Q?_for_invalid_subjectAlternativeNames_=5bv2=5d?=
In-Reply-To: <X4-zHSGywbQLQTZHZ443XVnoJI15S5hlYT840pNQDHM=.9924f8f5-c253-448f-97a5-d5fc2700e72c@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
 <X4-zHSGywbQLQTZHZ443XVnoJI15S5hlYT840pNQDHM=.9924f8f5-c253-448f-97a5-d5fc2700e72c@github.com>
Message-ID: <8bccffe3-e9b5-559a-fdf8-7d0a5f936b64@comcast.net>

Hi Sean -

Inline.

On 1/21/2022 11:33 AM, Sean Mullan wrote:
> On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano<myano at openjdk.org>  wrote:
>
>>> Could you please review the JDK-8255739 bug fix?
>>>
>>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>>>
>>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    8255739: x509Certificate returns ? for invalid subjectAlternativeNames
>> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
>>
>> On 1/18/2022 4:10 PM, Sean Mullan wrote:
>>
>> Hi -
>>
>> Bouncycastle started enforcing properly encoded? INTEGERs a while back and that caused one of my programs to start failing due to a TPM X509 endorsement certificate just having the TPM serial number stuffed into the certificate serial number without normalizing it to the appropriate INTEGER encoding.? BC provided a work around (setting "org.bouncycastle.asn1.allow_unsafe_integer") which gave me time to re-code around the problem.? If you're going to break things, it may be useful to provide a work around similar to what they did.
> Do you know the behavior of the JDK X.509 CertificateFactory implementation? Did it accept or reject this serial number?

It accepted the serial number:

> [
> [
> ? Version: V3
> ? Subject:
> ? Signature Algorithm: SHA256withECDSA, OID = 1.2.840.10045.4.3.2
>
> ? Key:? Sun RSA public key, 2048 bits
> ? modulus: 
> 244030580540745092613654475993648434932553330564847517407727188658248
> 32223177660143311229959664585582409529625785574450992069681603560492386013716136
> 32364832338166792867574600908839414339721021812629840173006767022634407898831293
> 85934831807840338360685996173024268943864659869938519459993447390570376982441341
> 45952422087437605410761245329340711833296479315725697546185458730724484238852701
> 80315770789789435860018869046480700786553465339467127182438028195537091676054789
> 84722755281453369500125757853796162260084162669462853871135753998130894343437638
> 04195331153338279046418652746376364246586098919744901616926689536893
> ? public exponent: 65537
> ? Validity: [From: Sun Nov 26 20:52:10 EST 2017,
> ?????????????? To: Thu Dec 30 19:00:00 EST 2049]
> ? Issuer: CN=www.intel.com, OU=TPM EK intermediate for 
> SPTH_EPID_PROD_RK_0, O=In
> tel Corporation, L=Santa Clara, ST=CA, C=US
> _*SerialNumber: [??? 048fe61d 2882d3cd 488ab130 b94fbc89 284b32]*_
>
> Certificate Extensions: 9
> [1]: ObjectId: 2.5.29.9 Criticality=false
> Extension unknown: DER encoded OCTET string =
> 0000: 04 1A 30 18 30 16 06 05?? 67 81 05 02 10 31 0D 30 ..0.0...g....1.0
> 0010: 0B 0C 03 32 2E 30 02 01?? 00 02 01 5D ...2.0.....]
>
>
> [2]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
> AuthorityInfoAccess [
> ? [
> ?? accessMethod: caIssuers
> ?? accessLocation: URIName: 
> http://upgrades.intel.com/content/CRL/ekcert/SPTH_EP
> ID_PROD_RK_0.cer
> ]
> ]
>
> [3]: ObjectId: 2.5.29.35 Criticality=false
> AuthorityKeyIdentifier [
> KeyIdentifier [
> 0000: 6C A9 DF 62 A1 AA E2 3E?? 0F EB 7C 3F 5E B8 E6 1E l..b...>...?^...
> 0010: CA C1 7C B7??????????????????????????????????????? ....
> ]
> ]
>
> [4]: ObjectId: 2.5.29.19 Criticality=true
> BasicConstraints:[
> ? CA:false
> ? PathLen: undefined
> ]
>
> [5]: ObjectId: 2.5.29.31 Criticality=false
> CRLDistributionPoints [
> ? [DistributionPoint:
> ???? [URIName: 
> http://upgrades.intel.com/content/CRL/ekcert/SPTH_EPID_PROD_RK_0.
> crl]
> ]]
>
> [6]: ObjectId: 2.5.29.32 Criticality=false
> CertificatePolicies [
> ? [CertificatePolicyId: [1.2.840.113741.1.5.2.1]
> [PolicyQualifierInfo: [
> ? qualifierID: 1.3.6.1.5.5.7.2.1
> ? qualifier: 0000: 16 46 68 74 74 70 3A 2F?? 2F 75 70 67 72 61 64 65? 
> .Fhttp://u
> pgrade
> 0010: 73 2E 69 6E 74 65 6C 2E?? 63 6F 6D 2F 63 6F 6E 74 s.intel.com/cont
> 0020: 65 6E 74 2F 43 52 4C 2F?? 65 6B 63 65 72 74 2F 45 ent/CRL/ekcert/E
> 0030: 4B 63 65 72 74 50 6F 6C?? 69 63 79 53 74 61 74 65 KcertPolicyState
> 0040: 6D 65 6E 74 2E 70 64 66 ment.pdf
>
> ], PolicyQualifierInfo: [
> ? qualifierID: 1.3.6.1.5.5.7.2.2
> ? qualifier: 0000: 30 2A 0C 28 54 43 50 41?? 20 54 72 75 73 74 65 64? 
> 0*.(TCPA T
> rusted
> 0010: 20 50 6C 61 74 66 6F 72?? 6D 20 4D 6F 64 75 6C 65 Platform Module
> 0020: 20 45 6E 64 6F 72 73 65?? 6D 65 6E 74 Endorsement
>
> ]]? ]
> ]
>
> [7]: ObjectId: 2.5.29.37 Criticality=false
> ExtendedKeyUsages [
> ? 2.23.133.8.1
> ]
>
> [8]: ObjectId: 2.5.29.15 Criticality=true
> KeyUsage [
> ? Key_Encipherment
> ]
>
> [9]: ObjectId: 2.5.29.17 Criticality=true
> SubjectAlternativeName [
> ? OID.2.23.133.2.3=id:00020000, OID.2.23.133.2.2=SPT, 
> OID.2.23.133.2.1=id:494E54
> 43
> ]
>
> ]
> ? Algorithm: [SHA256withECDSA]
> ? Signature:
> 0000: 30 45 02 20 6C 91 72 DF?? DC 9E 59 AB 57 81 E2 FC? 0E. l.r...Y.W...
> 0010: 00 EA 0A 0D A7 4D 94 0F?? 0E FA BA E1 30 08 19 E5 .....M......0...
> 0020: CF 25 33 27 02 21 00 E6?? F0 C0 75 EF 8E C6 C3 84 .%3'.!....u.....
> 0030: 54 9F 7A DD D5 A6 5F E0?? 7C 42 D7 5A B0 8A 1A 1C T.z..._..B.Z....
> 0040: B3 6E D6 56 8F A2 44 .n.V..D
>
> ]

Here's the ASN1 for the serial number:

> ?02 14
> 00 04 8f e6 1d? 28 82 d3 cd? 48 8a b1 30? b9 4f bc 89 28 4b 32 
In this case, the encoding should not have included the leading '00' 
byte.? That 20 byte value is what I get if I query the TPM directly for 
its serial number.

Here's what org.bouncycastle.asn1.ASN1Integer does:

> ?????? switch (bytes.length)
> ??????? {
> ??????? case 0:
> ??????????? return true;
> ??????? case 1:
> ??????????? return false;
> ??????? default:
> ??????????? return bytes[0] == (bytes[1] >> 7)
> ??????????????? // Apply loose validation, see note in public 
> constructor ASN1Integer(byte[])
> ??????????????? && 
> !Properties.isOverrideSet("org.bouncycastle.asn1.allow_unsafe_integer");
> ??????? }

Basically returns "true" to the question "isMalformatted" if there is a 
leading zero byte and the high bit of the second byte isn't set or if 
the first is 0xff and the high bit of the second byte is set.

E.g. according to 8.3.2 of X.690:

> If the contents octets of an integer value encoding consist of more 
> than one octet, then the bits of the first octet
> and bit 8 of the second octet
> a)shall not all be ones; and
> b)shall not all be zero.
> NOTE ? These rules ensure that an integer value is always encoded in 
> the smallest possible number of octets

So the JDK implementation violates the standard.

>
>> In any event, DerValue.java uses "new String(byteArrayValue, charsetType)" to produce the various String values including in getIA5String().? I.e.,
>>
>>> public?String(byte[]?bytes,
>>> Charset ?charset)
>>> Constructs a new |String| by decoding the specified array of bytes
>>> using the specified charset. The length of the new |String| is a
>>> function of the charset, and hence may not be equal to the length of
>>> the byte array.
>>> _*This method always replaces malformed-input and unmappable-character
>>> sequences with this charset's default replacement string.*_ The
>>> |CharsetDecoder| class should be used when more control over the
>>> decoding process is required.
>> Perhaps it might make sense to update the various places where this is used in DerValue to CharsetDecoder and to use charsetDecoder.onMalformedInput() and charsetDecoder.onUnmappableCharacter() to set the appropriate action related to parsing the byte array into a String of a given charset?? That action could be set based on the presence of the bypass property.
> I believe that was originally suggested by the submitter as a potential solution. But it doesn't seem like it is that useful or there would be much demand for this.

I wish CertificateFactorylgetInstance() could accept a parameter object 
describing how strict or loose an encoding would be accepted by the 
parsing engine.

On the more general note of whether there's demand - it would be useful 
if there were a way to avoid accepting certificates that are 
malformatted.? I originally started using the BC certificate factory 
because the SUN factory didn't understand RSA-OAEP as a key type in 
SubjectKeyInfo and I was getting a few of those from a group of TPMs.?? 
But I do understand the limitations of resources.

>
>> I don't think the change as proposed is backward-compatible safe enough, nor does it really address the general issue of poorly encoded DER String values in a certificate.
> Yes, I have come to the conclusion that this is probably too risky to fix. An application that is depending on a DNSName should be doing additional matching checks to verify that the structure of the name is correct, and it doesn't violate other types of rules, such as wildcards involving public suffixes, etc. (The JDK code does these additional checks when verifying TLS server certificates).

Yes.

Thanks - Mike


>
> See alsohttps://groups.google.com/g/mozilla.dev.security.policy/c/Av6oZxbjvB4/m/NW6lGkgYBwAJ  and the linked report of various anomalies in commonNames and Subject Alternative Names in server auth certificates issued by public CAs.
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/6928

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220122/6cfcc77f/attachment-0001.htm>

From michaelm at openjdk.java.net  Mon Jan 24 13:36:47 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 24 Jan 2022 13:36:47 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v6]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

 - fixed failing test issue and update for latest comments
 - Merge branch 'master' into spnego
 - added root cause to NamingException
 - more tidy-up
 - removed sasl module dependency and added SaslException cause
 - changes after first review round
 - cleanup but still no test. Will be added in closed repo
 - First version of fix. No test and feature enabled always.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/058c3830..ad80dfa2

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

  Stats: 17855 lines in 614 files changed: 12290 ins; 2870 del; 2695 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From michaelm at openjdk.java.net  Mon Jan 24 13:36:50 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 24 Jan 2022 13:36:50 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v5]
In-Reply-To: <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <scsTmUfXUcVHu9NkQRJG1Zu6-AtcmyzvcWrPzE84ZyE=.37fad522-2452-4682-83a0-1fff06f52c3f@github.com>
 <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com>
Message-ID: <N7G5eY7t7dgWcgtF8niwfD-mW4fxKMTm5wsO8wf7Go4=.247d548b-ae01-4989-ba8f-5ed4394315e5@github.com>

On Fri, 21 Jan 2022 19:48:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added root cause to NamingException
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 220:
> 
>> 218: 	This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos 
>> 219:         or the Negotiate authentication scheme using Kerberos are employed over HTTPS with 
>> 220:         {@code HttpsURLConnection}. There are three possible settings:</P>
> 
> You can probably mention here that the 'tls-server-end-point' Channel Binding Type defined in RFC 5929 is used.

I've updated this and moved the two properties to LdapSasl where they are used. Also, the test that was failing before needed some further updates.

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

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

From dfuchs at openjdk.java.net  Mon Jan 24 13:57:10 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 Jan 2022 13:57:10 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v6]
In-Reply-To: <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
Message-ID: <DpkRq_HvOcBKCQl9goJmpjFmsexqN4dJEv6CsnKgtvs=.2aecff44-c325-4be2-9cb6-6c1a63b1d91a@github.com>

On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - fixed failing test issue and update for latest comments
>  - Merge branch 'master' into spnego
>  - added root cause to NamingException
>  - more tidy-up
>  - removed sasl module dependency and added SaslException cause
>  - changes after first review round
>  - cleanup but still no test. Will be added in closed repo
>  - First version of fix. No test and feature enabled always.

src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 260:

> 258:      * @throws ChannelBindingException
> 259:      */
> 260:     private static TlsChannelBindingType parseType(String cbType) throws ChannelBindingException {

Maybe this method could throw NamingException directly now? That would avoid wrapping CBE into NamingException?

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

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

From mullan at openjdk.java.net  Mon Jan 24 14:51:06 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 24 Jan 2022 14:51:06 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames
In-Reply-To: <8bccffe3-e9b5-559a-fdf8-7d0a5f936b64@comcast.net>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <8bccffe3-e9b5-559a-fdf8-7d0a5f936b64@comcast.net>
Message-ID: <hPICYHbIK5VZRB_m-QEWgphPXKfJTgl9D6YlYtQk94s=.534d38bf-ad03-469d-ad29-dd543d549867@github.com>

On Sat, 22 Jan 2022 22:48:29 GMT, Michael StJohns <mstjohns at comcast.net> wrote:

> I originally started using the BC certificate factory
> because the SUN factory didn't understand RSA-OAEP as a key type in
> SubjectKeyInfo and I was getting a few of those from a group of TPMs.??

Is that still an issue? I would have expected this to be fixed since JDK 11 when we added support for RSASSA-PSS.

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

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

From weijun at openjdk.java.net  Mon Jan 24 15:32:22 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 Jan 2022 15:32:22 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v6]
In-Reply-To: <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
Message-ID: <ysfntsfbpb9TM12ioGvFqaQdWJaPf4Gk9QYRM_dmDhA=.921ab7d8-e637-4f17-bc42-e5700eb1ce72@github.com>

On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - fixed failing test issue and update for latest comments
>  - Merge branch 'master' into spnego
>  - added root cause to NamingException
>  - more tidy-up
>  - removed sasl module dependency and added SaslException cause
>  - changes after first review round
>  - cleanup but still no test. Will be added in closed repo
>  - First version of fix. No test and feature enabled always.

src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100:

> (failed to retrieve contents of file, check the PR for context)
I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP.

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

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

From weijun at openjdk.java.net  Mon Jan 24 15:32:22 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 Jan 2022 15:32:22 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v4]
In-Reply-To: <cnDXcxorLTg6piimkQJO4CxXotTVhsZOevNNjdfbwUI=.f427c695-6989-41d1-ab18-aefce338fb00@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pPi2071GA2RfXbIIWVg1j-HBMeznqsxXkh8dsc-UXA0=.e0bfd98a-4c22-4fe7-8f27-7d55b97ed7f4@github.com>
 <cnDXcxorLTg6piimkQJO4CxXotTVhsZOevNNjdfbwUI=.f427c695-6989-41d1-ab18-aefce338fb00@github.com>
Message-ID: <LPbmu62fwhFK2Z54jQA9KeuKsbYmskRq5Qd1pLinl64=.a140c40b-7fb5-401b-a8ca-4a3dc30c4793@github.com>

On Fri, 21 Jan 2022 15:40:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more tidy-up
>
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144:
> 
>> 142:                         } catch (ChannelBindingException e) {
>> 143:                             throw new NamingException(e.getMessage());
>> 144:                         }
> 
> Should we call initCause here and above? I see that we do call initCause in NegotiatorImpl.java.
> On the one hand it's better for diagnostic. On the other hand it exposes a module-internal exception class which is not great. Or maybe we should set the cause of the CBE as the cause of NamingException.

As long as the spec has not dictated what the cause should be, I don't care if the exception type is internal or not.

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

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

From weijun at openjdk.java.net  Mon Jan 24 15:32:23 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 Jan 2022 15:32:23 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v6]
In-Reply-To: <DpkRq_HvOcBKCQl9goJmpjFmsexqN4dJEv6CsnKgtvs=.2aecff44-c325-4be2-9cb6-6c1a63b1d91a@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
 <DpkRq_HvOcBKCQl9goJmpjFmsexqN4dJEv6CsnKgtvs=.2aecff44-c325-4be2-9cb6-6c1a63b1d91a@github.com>
Message-ID: <3iOOsm_palWB0x2iybPZZ4rtiUY6ObLy33Cpd1nPgxs=.3e5ac581-d1c3-433f-82a8-0144e0867547@github.com>

On Mon, 24 Jan 2022 13:54:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - fixed failing test issue and update for latest comments
>>  - Merge branch 'master' into spnego
>>  - added root cause to NamingException
>>  - more tidy-up
>>  - removed sasl module dependency and added SaslException cause
>>  - changes after first review round
>>  - cleanup but still no test. Will be added in closed repo
>>  - First version of fix. No test and feature enabled always.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 260:
> 
>> 258:      * @throws ChannelBindingException
>> 259:      */
>> 260:     private static TlsChannelBindingType parseType(String cbType) throws ChannelBindingException {
> 
> Maybe this method could throw NamingException directly now? That would avoid wrapping CBE into NamingException?

My opinion is this method should be put back.

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

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

From michaelm at openjdk.java.net  Mon Jan 24 15:57:15 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 24 Jan 2022 15:57:15 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v6]
In-Reply-To: <ysfntsfbpb9TM12ioGvFqaQdWJaPf4Gk9QYRM_dmDhA=.921ab7d8-e637-4f17-bc42-e5700eb1ce72@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
 <ysfntsfbpb9TM12ioGvFqaQdWJaPf4Gk9QYRM_dmDhA=.921ab7d8-e637-4f17-bc42-e5700eb1ce72@github.com>
Message-ID: <UuYWtjJ9pnhcoq8kSuGEidiQ8qRGWhWD30Ps6OdF7yE=.27e99080-ccf3-4269-967a-4afe568060a6@github.com>

On Mon, 24 Jan 2022 15:23:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - fixed failing test issue and update for latest comments
>>  - Merge branch 'master' into spnego
>>  - added root cause to NamingException
>>  - more tidy-up
>>  - removed sasl module dependency and added SaslException cause
>>  - changes after first review round
>>  - cleanup but still no test. Will be added in closed repo
>>  - First version of fix. No test and feature enabled always.
>
> src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100:
> 
>> (failed to retrieve contents of file, check the PR for context)
> I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP.

So, where should the two constant Strings go? It doesn't feel like they belong in java.base since they are JNDI/SASL related, and we can't have a method in `java.base` depending on code in other modules?

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

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

From mullan at openjdk.java.net  Mon Jan 24 16:03:13 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 24 Jan 2022 16:03:13 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v2]
In-Reply-To: <-SGqQxfBady_OL-XCjP9_rUe3HlF2gjXKjm4DQDDc08=.23163daf-34ee-4cd1-a373-0ca71736c50f@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <LmrGR5tsT3fv0Ftg8aS6hYGbQJPCgX4UX9LPhFXkeB0=.0ed97028-2956-48ed-876e-7a39abeb12eb@github.com>
 <-SGqQxfBady_OL-XCjP9_rUe3HlF2gjXKjm4DQDDc08=.23163daf-34ee-4cd1-a373-0ca71736c50f@github.com>
Message-ID: <JMHmrVA5gPGcvy7gJeTRpQzNeF6x9TjWgFDlYVOAQ0M=.f0beffb2-9505-4226-a4b9-b61c672ceb77@github.com>

On Fri, 21 Jan 2022 03:27:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1129:
>> 
>>> 1127:         }
>>> 1128: 
>>> 1129:         buildTrustedCerts();
>> 
>> Can we reuse the keystore loaded by `buildTrustedCerts()` instead of reloading it again on line 1138?
>
> No change. This is because `caks` global variable can only be initialized with cacerts keystore  when the `trustcacerts` option is specified; otherwise if has to be kept null. `buildTrustedCerts`() is always executed.

I was thinking `buildTrustedCerts` could return the cacerts `KeyStore`, and you could assign that instead to `caks` if `trustcacerts` is true.

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

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

From mullan at openjdk.java.net  Mon Jan 24 16:15:17 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 24 Jan 2022 16:15:17 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v2]
In-Reply-To: <iT5xQXLzvR8p2zSMomw2JNYzJAtP_IYKxS7NEdcwVc8=.231c7264-6a4d-4c93-95ac-7712f2358980@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <iT5xQXLzvR8p2zSMomw2JNYzJAtP_IYKxS7NEdcwVc8=.231c7264-6a4d-4c93-95ac-7712f2358980@github.com>
Message-ID: <UZ98Xtun2-DnJ_R8gLCt36i1HZ3hgFAQy9-OR1LB51I=.eb4cee0b-7635-4732-8f7f-da9a06c0d191@github.com>

On Fri, 21 Jan 2022 03:34:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with review comments

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

> 4906:                 if (eMessage.contains("denyAfter constraint check failed") &&
> 4907:                         e.getReason() == BasicReason.ALGORITHM_CONSTRAINED) {
> 4908:                     String separator = "java.security: ";

Did you consider extracting the date from the security property? Ex: `Security.getProperty("jdk.certpath.disabledAlgorithms")`? I think that would be a better solution instead of parsing the exception message, which might change in the future.

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

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

From weijun at openjdk.java.net  Mon Jan 24 19:13:11 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 Jan 2022 19:13:11 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v6]
In-Reply-To: <UuYWtjJ9pnhcoq8kSuGEidiQ8qRGWhWD30Ps6OdF7yE=.27e99080-ccf3-4269-967a-4afe568060a6@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <uBLJ7NPf7r_Rk7yc-PidUI7MZlmWs2j8VStbC5hKWV0=.4aefa37c-495e-4277-98f6-0388efa6e2c1@github.com>
 <ysfntsfbpb9TM12ioGvFqaQdWJaPf4Gk9QYRM_dmDhA=.921ab7d8-e637-4f17-bc42-e5700eb1ce72@github.com>
 <UuYWtjJ9pnhcoq8kSuGEidiQ8qRGWhWD30Ps6OdF7yE=.27e99080-ccf3-4269-967a-4afe568060a6@github.com>
Message-ID: <yQ8Gc1oULDv3BD32VBv2wCw5jjm3nY7XNXoTHfBcTfc=.c3efec77-1bae-4228-9890-a3a69b44b393@github.com>

On Mon, 24 Jan 2022 15:54:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP.
>
> So, where should the two constant Strings go? It doesn't feel like they belong in java.base since they are JNDI/SASL related, and we can't have a method in `java.base` depending on code in other modules?

The 2 strings should be on the LDAP side. This method does not really depend on the strings except for mentioning one in the exception message. We can just rewrite it into `"Illegal channel binding type: " + cbType`.

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

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

From weijun at openjdk.java.net  Mon Jan 24 19:23:17 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 Jan 2022 19:23:17 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames [v2]
In-Reply-To: <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
Message-ID: <uDWYfE6WUADTahXxx0t8keyP63KcDubfDjOMabw2LkQ=.1efb985c-e5d7-4e21-b2ec-4d5f724b62c5@github.com>

On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the JDK-8255739 bug fix?
>> 
>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>> 
>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255739: x509Certificate returns ? for invalid subjectAlternativeNames

Hi Mike, we don't support an OAEP key (i.e. RSA keys with OAEP parameters). If you want OAEP encryption, just use a plain RSA key and pass an OAEPParameterSpec to the RSA Cipher's init method.

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

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

From mstjohns at comcast.net  Mon Jan 24 19:41:28 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 24 Jan 2022 14:41:28 -0500
Subject: =?UTF-8?Q?Re=3a_RFR=3a_8255739=3a_x509Certificate_returns_=ef=bf=bd?=
 =?UTF-8?Q?_for_invalid_subjectAlternativeNames?=
In-Reply-To: <hPICYHbIK5VZRB_m-QEWgphPXKfJTgl9D6YlYtQk94s=.534d38bf-ad03-469d-ad29-dd543d549867@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <8bccffe3-e9b5-559a-fdf8-7d0a5f936b64@comcast.net>
 <hPICYHbIK5VZRB_m-QEWgphPXKfJTgl9D6YlYtQk94s=.534d38bf-ad03-469d-ad29-dd543d549867@github.com>
Message-ID: <d2dd4803-4b68-1f53-11ae-1793461121e9@comcast.net>

On 1/24/2022 9:51 AM, Sean Mullan wrote:
> On Sat, 22 Jan 2022 22:48:29 GMT, Michael StJohns <mstjohns at comcast.net> wrote:
>
>> I originally started using the BC certificate factory
>> because the SUN factory didn't understand RSA-OAEP as a key type in
>> SubjectKeyInfo and I was getting a few of those from a group of TPMs.??
> Is that still an issue? I would have expected this to be fixed since JDK 11 when we added support for RSASSA-PSS.
*sigh* doing archeology on my code, that may not have been the reason I 
started using the BC factory.? I *think* I ran into another rogue 
certificate that the SUN library couldn't parse, but the BC library 
code.? However, the RSA-OAEP thing does exist.? See below
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/6928

Looks like it probably wasn't fixed. ?? This was actually an OID in the 
SubjectKeyInfo meant to indicate that the RSA key was solely to be used 
for OAEP.? I.e. 1.2.840.113549.1.1.7.? The place this gets rejected is 
in (looking at the current github) - sun/crypto/provider/RSACipher.java 
@line 261: RSAKey rsaKey = RSAKeyFactory.toRSAKey(key);

That calls sun/security/rsa/RSAKeyFactory.java::toRSAKey(Key key), which 
in turn calls 
sun/security/rsa/RSAUtil.KeyType::lookup(key.getAlgorithm()) @line 128.? 
That fails because the key is neither the rsaEncryption OID 
(1.2.840.113549.1.1.1) nor RSASSA_PSS_oid (.... .10).


Here's the function I use to fix the encoding. Basically, it changes the 
last octet of the key's algorithmID from a '7' to a '1' and regenerates 
the key.

> ? public static PublicKey fixPubKey (PublicKey k)
> ??? throws PrivacyCAException{
> ??? if (!k.getAlgorithm().equals("1.2.840.113549.1.1.7"))
> ????? return k;? // its not a problem
> ??? byte[] encodedKey = k.getEncoded();
> ??? encodedKey[16] = (byte)1;
> ??? X509EncodedKeySpec kspec = new X509EncodedKeySpec(encodedKey);
>
> ??? try {
> ????? KeyFactory kf = KeyFactory.getInstance("RSA");
> ????? return kf.generatePublic(kspec);
> ??? } catch (GeneralSecurityException ex) {
> ????? throw new PrivacyCAException ("Unable to convert an OAEP RSA 
> Public Key to a normal RSA public key", ex);
> ??? }
> ? }

The fixed public key is fed to this code code which worked even in JDK8:

> Cipher rsaoaep = Cipher.getInstance 
> ("RSA/ECB/oaepwithsha1andmgf1padding", "SunJCE");
> ??? String hashName = "SHA-256"; // name alg hash for EK?
> ??? String hmacName = "HmacSHA256";
> ??? int hashLen = 256;
> ??? byte[] identityLabel = 
> Charset.forName("UTF-8").encode("IDENTITY").array();
>
> ??? // zero terminate
> ??? identityLabel = Arrays.copyOf(identityLabel, identityLabel.length 
> + 1);
> ??? logBuffer("Identity label", identityLabel);
> ??? OAEPParameterSpec oaepspec =
> ????? new OAEPParameterSpec (hashName, "MGF1", new MGF1ParameterSpec 
> (hashName),
> ?? ??? ??? ????? new PSource.PSpecified(identityLabel));
> ??? rsaoaep.init (Cipher.ENCRYPT_MODE, ekPubKey, oaepspec);
> ??? byte[] encryptedSeed = rsaoaep.doFinal(seed);

If I get a chance, I'll try and take a properly formatted RSA (.1) key 
and turn it into an RSAOAEP? (.7) key and see what happens with the 
above code.? It may take a few days.

AFAIK, this convention was only used by the TPM1.2 space, and only 
briefly as it was realized it was a backwards compatibility nightmare.? 
It was actually in an early version of the TPM spec and then removed.? I 
haven't seen any of these keys in any of the TPM2.0s I've played with.

Strangely, I haven't seen any PSS (.10) (vs OAEP) encoded keys.

Mike




From hchao at openjdk.java.net  Mon Jan 24 21:16:43 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 24 Jan 2022 21:16:43 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v3]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <8v9DWZEMtBu3zAPU-JPN02BV-Fd7XRFjWwP4GDNa_E8=.ad4b5288-848d-4ef7-a8e0-43a96a2e87c5@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Revert changes to DisabledAlgorithmConstraints.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/a05728a7..dffb512d

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

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

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

From hchao at openjdk.java.net  Mon Jan 24 21:21:58 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 24 Jan 2022 21:21:58 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v4]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <9642mqqWH07Nx0yngwy1LzeAtfnnK2drQSfVWTno66g=.4c6e5304-3d04-4e06-bd99-214d851c6691@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Update to get denyAfter and init caks

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/dffb512d..e91bb05f

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

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

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

From hchao at openjdk.java.net  Mon Jan 24 21:21:58 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 24 Jan 2022 21:21:58 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v4]
In-Reply-To: <JMHmrVA5gPGcvy7gJeTRpQzNeF6x9TjWgFDlYVOAQ0M=.f0beffb2-9505-4226-a4b9-b61c672ceb77@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <LmrGR5tsT3fv0Ftg8aS6hYGbQJPCgX4UX9LPhFXkeB0=.0ed97028-2956-48ed-876e-7a39abeb12eb@github.com>
 <-SGqQxfBady_OL-XCjP9_rUe3HlF2gjXKjm4DQDDc08=.23163daf-34ee-4cd1-a373-0ca71736c50f@github.com>
 <JMHmrVA5gPGcvy7gJeTRpQzNeF6x9TjWgFDlYVOAQ0M=.f0beffb2-9505-4226-a4b9-b61c672ceb77@github.com>
Message-ID: <ih4cTXNNS99lrQDtbVHoLi2_oQRfxbaOQtIb2dB_Fak=.8bfd0f7a-1bc7-46c8-bb0c-e44674912e0e@github.com>

On Mon, 24 Jan 2022 16:00:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> No change. This is because `caks` global variable can only be initialized with cacerts keystore  when the `trustcacerts` option is specified; otherwise if has to be kept null. `buildTrustedCerts`() is always executed.
>
> I was thinking `buildTrustedCerts` could return the cacerts `KeyStore`, and you could assign that instead to `caks` if `trustcacerts` is true.

Done as suggested.

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

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

From hchao at openjdk.java.net  Mon Jan 24 21:21:59 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 24 Jan 2022 21:21:59 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v2]
In-Reply-To: <UZ98Xtun2-DnJ_R8gLCt36i1HZ3hgFAQy9-OR1LB51I=.eb4cee0b-7635-4732-8f7f-da9a06c0d191@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <iT5xQXLzvR8p2zSMomw2JNYzJAtP_IYKxS7NEdcwVc8=.231c7264-6a4d-4c93-95ac-7712f2358980@github.com>
 <UZ98Xtun2-DnJ_R8gLCt36i1HZ3hgFAQy9-OR1LB51I=.eb4cee0b-7635-4732-8f7f-da9a06c0d191@github.com>
Message-ID: <juGCMz4uonp1w_cabedfp7NCH3nymD2uharPfw4DN4s=.ec8f6be2-e3f6-45b9-a79c-4fdee4cfabfe@github.com>

On Mon, 24 Jan 2022 16:12:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with review comments
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4908:
> 
>> 4906:                 if (eMessage.contains("denyAfter constraint check failed") &&
>> 4907:                         e.getReason() == BasicReason.ALGORITHM_CONSTRAINED) {
>> 4908:                     String separator = "java.security: ";
> 
> Did you consider extracting the date from the security property? Ex: `Security.getProperty("jdk.certpath.disabledAlgorithms")`? I think that would be a better solution instead of parsing the exception message, which might change in the future.

Fixed.

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

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

From mstjohns at comcast.net  Mon Jan 24 21:45:39 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 24 Jan 2022 16:45:39 -0500
Subject: =?UTF-8?Q?Re=3a_RFR=3a_8255739=3a_x509Certificate_returns_=ef=bf=bd?=
 =?UTF-8?Q?_for_invalid_subjectAlternativeNames_=5bv2=5d?=
In-Reply-To: <uDWYfE6WUADTahXxx0t8keyP63KcDubfDjOMabw2LkQ=.1efb985c-e5d7-4e21-b2ec-4d5f724b62c5@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
 <uDWYfE6WUADTahXxx0t8keyP63KcDubfDjOMabw2LkQ=.1efb985c-e5d7-4e21-b2ec-4d5f724b62c5@github.com>
Message-ID: <10004e27-8011-72d1-b111-eb5af669fbba@comcast.net>

On 1/24/2022 2:23 PM, Weijun Wang wrote:
> On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano <myano at openjdk.org> wrote:
>
>>> Could you please review the JDK-8255739 bug fix?
>>>
>>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>>>
>>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    8255739: x509Certificate returns ? for invalid subjectAlternativeNames
> Hi Mike, we don't support an OAEP key (i.e. RSA keys with OAEP parameters). If you want OAEP encryption, just use a plain RSA key and pass an OAEPParameterSpec to the RSA Cipher's init method.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/6928

Hi -

The RSA key just used a different AlgorithmIdentifier from the normal 
parameterless rsaEncryption AlgorithmIdentifier. ? This issue basically: 
https://github.com/openssl/openssl/issues/7907. The TCG originally 
specified that the EK certificate contained the TPM's endorsement public 
key would be identified by the? that any endorsement key public key 
would be identified with the RSAES-OAEP? { pkcs-1 7 } object identifier 
instead of the rsaEncryption? {pkcs-1 1 } OID since the key was only 
supposed to be used for decrypting a credential encrypted under OAEP.? 
e.g. the cert contained this sequence for the SubjectPublicKeyInfo:

> ? SEQUENCE {
> ?175?? 34:?????? SEQUENCE {
> ?177??? 9:???????? OBJECT IDENTIFIER rsaOAEP (1 2 840 113549 1 1 7)
> ?188?? 21:???????? SEQUENCE {
> ?190?? 19:?????????? [2] {
> ?192?? 17:???????????? SEQUENCE {
> ?194??? 9:?????????????? OBJECT IDENTIFIER
> ???????? :???????????????? rsaOAEP-pSpecified (1 2 840 113549 1 1 9)
> ?205??? 4:?????????????? OCTET STRING 'TCPA'
> ???????? :?????????????? }
> ???????? :???????????? }
> ???????? :?????????? }
> ???????? :???????? }
> ?211? 271:?????? BIT STRING, encapsulates {
> ?216? 266:???????? SEQUENCE {
> ?220? 257:?????????? INTEGER
> ???????? :???????????? 00 8A 80 D6 D1 A9 AD 54 92 A4 D2 AA F1 8A C8 D3
> ???????? :???????????? 48 12 2E 17 E4 2C FC 75 CF 57 A3 E4 33 EC C8 FD
> ???????? :???????????? 7D 2D 5E B4 13 F9 5D A9 45 51 E1 F1 22 F9 3C DA
> ???????? :???????????? 39 69 AB 8D 85 72 74 D9 97 9C A2 6E D1 BE 9B 93
> ???????? :???????????? 0A 83 1A 9D 2F 30 AA B1 F8 B8 89 04 34 1B 2C 72
> ???????? :???????????? 31 BF 1F 67 44 79 B9 9E 35 A8 99 06 56 7B 92 28
> ???????? :???????????? C4 21 B9 90 7E C8 41 09 F5 88 C2 23 28 DE 25 CA
> ???????? :???????????? AF C2 2B 2E 61 DB 8B 17 83 BB 74 9A 4F A8 D4 A3
> ???????? :???????????????????? [ Another 129 bytes skipped ]
> ?481??? 3:?????????? INTEGER 65537
> ???????? :?????????? }
> ???????? :???????? }
> ???????? :?????? }

Except for the weird AlgorithmIdentifier this is a bog standard RSA 
public key.

I don't know that its worth the time to fix this - it's already been 
deprecated by the TCG and I haven't seen an endorsement certificate with 
this particular encoding in a long while.? The certificate this key is 
from was issued 26 April 2012 and - for some strange reason - expires 
the same date this year.

Later, Mike



From michaelm at openjdk.java.net  Mon Jan 24 22:11:51 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 24 Jan 2022 22:11:51 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v7]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  more updates

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/ad80dfa2..0d529f9d

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

  Stats: 38 lines in 2 files changed: 18 ins; 19 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From xuelei at openjdk.java.net  Tue Jan 25 00:20:02 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 25 Jan 2022 00:20:02 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to fail
 with SNI disabled
Message-ID: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>

A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.

The update should be verified with jshell.  No new regression test added as there is a need of Fully-Qualified Domain Name.
$ $JDK_HOME/bin/jshell
jshell> URL url = new URL("https://www.google.com./");
jshell> URLConnection conn = url.openConnection();
jshell> conn.connect();

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

Commit messages:
 - 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled

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

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

From weijun at openjdk.java.net  Tue Jan 25 00:44:44 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 Jan 2022 00:44:44 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v7]
In-Reply-To: <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com>
Message-ID: <enMjD3e96qIsSToYvQHzN5m4UG5XX-B3rCymo-FKAZ0=.8db65708-9529-441c-a302-32e794fb0c49@github.com>

On Mon, 24 Jan 2022 22:11:51 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more updates

Looks good to me. Only several wording and style suggestions.

I know you are asking SQE to create a security infra test, but I'll see if I can contribute a regression test. Don't wait for me.

src/java.base/share/classes/java/net/doc-files/net-properties.html line 223:

> 221:         <OL>
> 222:           <LI><P>"never". This is also the default value if the property is not set. In this case,
> 223:               CBT's are never sent.</P>

Typo, "CBTs"?

src/java.base/share/classes/java/net/doc-files/net-properties.html line 224:

> 222:           <LI><P>"never". This is also the default value if the property is not set. In this case,
> 223:               CBT's are never sent.</P>
> 224:           <LI><P>"always". CBTs are sent for all Kerberos authentication attempts over HTTPS.</P>

Shall we remove "Kerberos"? Or we can use "Kerberos or Negotiate".

src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 1:

> 1: /**

This is not a doc comment.

src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 124:

> 122:         try {
> 123:             init(hci);
> 124:         } catch (GSSException | ChannelBindingException  e) {

Two spaces before "e".

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

Marked as reviewed by weijun (Reviewer).

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

From cushon at openjdk.java.net  Tue Jan 25 03:45:50 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 25 Jan 2022 03:45:50 GMT
Subject: RFR: 8280546: Remove hard-coded 127.0.0.1 loopback address
Message-ID: <P9Q9J7JbUV7sh3T00IWM4p75sjh3xfoZeSMr0Tdt2LI=.38b6a77d-801a-4565-a623-786740b7b21f@github.com>

This change replaces hard-coded 127.0.0.1 loopback addresses with `InetAddress.getLoopbackAddress().getHostAddress()`, to allow the tests to work on IPv6-only systems. This matches the approach of previous fixes in [JDK-8220083](https://bugs.openjdk.java.net/browse/JDK-8220083).

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

Commit messages:
 - 8280546: Remove hard-coded 127.0.0.1 loopback address

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

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

From michaelm at openjdk.java.net  Tue Jan 25 10:30:20 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 25 Jan 2022 10:30:20 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v8]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  final review update (pre CSR)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/0d529f9d..004466ea

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

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

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

From dfuchs at openjdk.java.net  Tue Jan 25 11:13:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 25 Jan 2022 11:13:37 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v8]
In-Reply-To: <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>
Message-ID: <MhZIDxkEQC-A-QyEEDOW6t_z9foZjM1Zuxpd1W4_oTw=.298fed9f-3cc6-4bea-bc29-6c0f2abe7f10@github.com>

On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final review update (pre CSR)

The new version LGTM.

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

Marked as reviewed by dfuchs (Reviewer).

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

From duke at openjdk.java.net  Tue Jan 25 11:38:35 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 25 Jan 2022 11:38:35 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v8]
In-Reply-To: <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>
Message-ID: <GjZzxi9vkovxDQYKGSB18ax4f-E8xWiJ_mWO1-ZOZMg=.dd04ac8a-d21b-4776-beb1-e8a18abcb358@github.com>

On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final review update (pre CSR)

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150:

> 148:      * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is
> 149:      * a comma separated list of arbitrary length with no white-space allowed.
> 150:      * If enabled (for a particular destination) then SPNEGO authentication requests will include

Previously `Negotiate` was used, now `SPNEGO`?

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

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

From michaelm at openjdk.java.net  Tue Jan 25 12:50:37 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 25 Jan 2022 12:50:37 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v8]
In-Reply-To: <GjZzxi9vkovxDQYKGSB18ax4f-E8xWiJ_mWO1-ZOZMg=.dd04ac8a-d21b-4776-beb1-e8a18abcb358@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>
 <GjZzxi9vkovxDQYKGSB18ax4f-E8xWiJ_mWO1-ZOZMg=.dd04ac8a-d21b-4776-beb1-e8a18abcb358@github.com>
Message-ID: <vNg-j7oOCUEBS4D1v2g1e5fA98ETcDDFNe-qP5fiWCk=.848a8bb1-ea80-4460-8597-f97fa416e15f@github.com>

On Tue, 25 Jan 2022 11:34:57 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   final review update (pre CSR)
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150:
> 
>> 148:      * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is
>> 149:      * a comma separated list of arbitrary length with no white-space allowed.
>> 150:      * If enabled (for a particular destination) then SPNEGO authentication requests will include
> 
> Previously `Negotiate` was used, now `SPNEGO`?

"Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here.

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

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

From duke at openjdk.java.net  Tue Jan 25 13:03:33 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 25 Jan 2022 13:03:33 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v8]
In-Reply-To: <vNg-j7oOCUEBS4D1v2g1e5fA98ETcDDFNe-qP5fiWCk=.848a8bb1-ea80-4460-8597-f97fa416e15f@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <pEOaV-DECkq1Te5_0ak-CwHz4x3T5TuhBS7ehjnS2zs=.981317f7-f01d-4e37-8e2d-fcfce4f2993e@github.com>
 <GjZzxi9vkovxDQYKGSB18ax4f-E8xWiJ_mWO1-ZOZMg=.dd04ac8a-d21b-4776-beb1-e8a18abcb358@github.com>
 <vNg-j7oOCUEBS4D1v2g1e5fA98ETcDDFNe-qP5fiWCk=.848a8bb1-ea80-4460-8597-f97fa416e15f@github.com>
Message-ID: <OIRYMfqewup-Z47g27dkAWDMtIb1PrUcscluyws2ubI=.c7c7897d-d927-467b-bca4-ba951f4a91ca@github.com>

On Tue, 25 Jan 2022 12:47:26 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150:
>> 
>>> 148:      * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is
>>> 149:      * a comma separated list of arbitrary length with no white-space allowed.
>>> 150:      * If enabled (for a particular destination) then SPNEGO authentication requests will include
>> 
>> Previously `Negotiate` was used, now `SPNEGO`?
>
> "Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here.

Yes, I know. That's the point. Clearly differentiate between GSS-API mech and HTTP auth scheme.

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

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

From weijun at openjdk.java.net  Tue Jan 25 14:19:33 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 Jan 2022 14:19:33 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled
In-Reply-To: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
Message-ID: <bV-JDcOOAGBa5f-AGVLuLprqOPpAiqA0ziZaGRQkNZs=.49da56d2-66bd-4860-814a-218f632a81d8@github.com>

On Tue, 25 Jan 2022 00:13:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
> 
> The update should be verified with jshell.  No new regression test added as there is a need of Fully-Qualified Domain Name.
> $ $JDK_HOME/bin/jshell
> jshell> URL url = new URL("https://www.google.com./");
> jshell> URLConnection conn = url.openConnection();
> jshell> conn.connect();

Is it possible to add a regression test using the `-Djdk.net.hosts.file` feature? It is a JVM-only `/etc/hosts` alternative.

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

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

From mullan at openjdk.java.net  Tue Jan 25 15:12:32 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 Jan 2022 15:12:32 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v4]
In-Reply-To: <9642mqqWH07Nx0yngwy1LzeAtfnnK2drQSfVWTno66g=.4c6e5304-3d04-4e06-bd99-214d851c6691@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <9642mqqWH07Nx0yngwy1LzeAtfnnK2drQSfVWTno66g=.4c6e5304-3d04-4e06-bd99-214d851c6691@github.com>
Message-ID: <sz7bfoIHV7nmNL1LaJVdG0dArSFuOevJtM4gEadz0Bk=.9bc813f1-109c-4b2c-a202-202d6d504194@github.com>

On Mon, 24 Jan 2022 21:21:58 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to get denyAfter and init caks

Changes requested by mullan (Reviewer).

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

> 1136: 
> 1137:         if (trustcacerts) {
> 1138:             caks = cakstore;

I just realized there is a slight change in behavior in that `buildTrustedCerts` ignores exceptions, whereas `KeyStoreUtil.getCacertsKeyStore()` does not. An exception should be a very rare case, but I recommend changing line 1138 to:


if (cakstore != null) {
    caks = cakstore;
} else {
    // try to load cacerts again, and let exception propagate if it cannot be loaded
    caks = KeyStoreUtil.getCacertsKeyStore();
}

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

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

From mullan at openjdk.java.net  Tue Jan 25 15:12:33 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 Jan 2022 15:12:33 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v2]
In-Reply-To: <juGCMz4uonp1w_cabedfp7NCH3nymD2uharPfw4DN4s=.ec8f6be2-e3f6-45b9-a79c-4fdee4cfabfe@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <iT5xQXLzvR8p2zSMomw2JNYzJAtP_IYKxS7NEdcwVc8=.231c7264-6a4d-4c93-95ac-7712f2358980@github.com>
 <UZ98Xtun2-DnJ_R8gLCt36i1HZ3hgFAQy9-OR1LB51I=.eb4cee0b-7635-4732-8f7f-da9a06c0d191@github.com>
 <juGCMz4uonp1w_cabedfp7NCH3nymD2uharPfw4DN4s=.ec8f6be2-e3f6-45b9-a79c-4fdee4cfabfe@github.com>
Message-ID: <2ECweU40YIeLbGZQ4zc9X6YFTT5Pcs5FIkPBitL9l5A=.11056491-b919-472e-8d37-7c58998183c6@github.com>

On Mon, 24 Jan 2022 21:17:42 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4908:
>> 
>>> 4906:                 if (eMessage.contains("denyAfter constraint check failed") &&
>>> 4907:                         e.getReason() == BasicReason.ALGORITHM_CONSTRAINED) {
>>> 4908:                     String separator = "java.security: ";
>> 
>> Did you consider extracting the date from the security property? Ex: `Security.getProperty("jdk.certpath.disabledAlgorithms")`? I think that would be a better solution instead of parsing the exception message, which might change in the future.
>
> Fixed.

After further thought, I'm now not sure my suggestion is any better (sorry for the rework). It is possible that there could be more than one `denyAfter` constraint, and in that case, you would need to also match on the algorithm that the constraint applies to, and that gets pretty complicated.

So, I now think your previous fix is probably better, even though it means we are depending on the syntax of the exception message. To avoid that from causing issues in the future, I would enhance your regression test to fail if the exception message changes in the future such that the denyAfter date cannot be parsed and is not what is expected.

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

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

From sebastian.stenzel at gmail.com  Tue Jan 25 20:06:16 2022
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Tue, 25 Jan 2022 21:06:16 +0100
Subject: Lots of allocations in CipherCore
Message-ID: <BA98969C-20B1-4A1D-AB56-901616420103@gmail.com>

Hi all,

while playing around with JFR today, I stumbled upon a piece of code that causes a thousands of byte[] allocations. In fact it is responsible for 90% of the memory allocations in my application and causes GC to run without pause during decryption of large files.

The line in question can be found here [1]. The behaviour can be triggered with a simple AES-CTR cipher as in this minimal example [2].

As you can see, the comments in [1] even say that this byte[] _should_ only be allocated if there is insufficient space in the provided output buffer. However some kind of conditional statement is missing.

There used to be a `if (getMode() != GCM_MODE || outputCapacity < estOutSize)`, before GCM has been decoupled from CipherCore. But this line seems wrong to me either.

I guess this should be fixed, as I'm probably not the only one affected by those allocations. I'd be volunteering, unless the behaviour is intended.

Cheers!
Sebastian


[1] https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818 <https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818>
[2] https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5 <https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220125/f9f0ba7f/attachment.htm>

From hchao at openjdk.java.net  Tue Jan 25 20:51:17 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 25 Jan 2022 20:51:17 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v5]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <kUClDrqDBeOzMIyisI8S3BKpfvbcvMfMb0Js91wgfaA=.3af94abb-6ea7-4aba-a422-c38b2abf7521@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Revert to get denyAfter from exception and reload caks

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/e91bb05f..74fd1423

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

  Stats: 28 lines in 3 files changed: 15 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7039/head:pull/7039

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

From hchao at openjdk.java.net  Tue Jan 25 20:51:19 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 25 Jan 2022 20:51:19 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v4]
In-Reply-To: <9642mqqWH07Nx0yngwy1LzeAtfnnK2drQSfVWTno66g=.4c6e5304-3d04-4e06-bd99-214d851c6691@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <9642mqqWH07Nx0yngwy1LzeAtfnnK2drQSfVWTno66g=.4c6e5304-3d04-4e06-bd99-214d851c6691@github.com>
Message-ID: <7Tt4Xfk3RS1OYANRU5JrWnCRqEsOnZWmtQAVjxAZ46M=.6937d644-0c6e-4fa8-88cf-f8e7abbe77a4@github.com>

On Mon, 24 Jan 2022 21:21:58 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to get denyAfter and init caks

Changed to use the previous fix, and modified test case to check for the expected date string.

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

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

From hchao at openjdk.java.net  Tue Jan 25 20:51:21 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 25 Jan 2022 20:51:21 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v4]
In-Reply-To: <sz7bfoIHV7nmNL1LaJVdG0dArSFuOevJtM4gEadz0Bk=.9bc813f1-109c-4b2c-a202-202d6d504194@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <9642mqqWH07Nx0yngwy1LzeAtfnnK2drQSfVWTno66g=.4c6e5304-3d04-4e06-bd99-214d851c6691@github.com>
 <sz7bfoIHV7nmNL1LaJVdG0dArSFuOevJtM4gEadz0Bk=.9bc813f1-109c-4b2c-a202-202d6d504194@github.com>
Message-ID: <2pn4rwmGqtmEWtlbTHMAzkpkrHdX88MePEgFc4IEOak=.348e1bc3-da3d-4f8a-8f4b-9791e69b972e@github.com>

On Tue, 25 Jan 2022 14:38:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to get denyAfter and init caks
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1138:
> 
>> 1136: 
>> 1137:         if (trustcacerts) {
>> 1138:             caks = cakstore;
> 
> I just realized there is a slight change in behavior in that `buildTrustedCerts` ignores exceptions, whereas `KeyStoreUtil.getCacertsKeyStore()` does not. An exception should be a very rare case, but I recommend changing line 1138 to:
> 
> 
> if (cakstore != null) {
>     caks = cakstore;
> } else {
>     // try to load cacerts again, and let exception propagate if it cannot be loaded
>     caks = KeyStoreUtil.getCacertsKeyStore();
> }

Added the exception as recommended.

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

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

From anthony.scarpino at oracle.com  Tue Jan 25 21:43:19 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 25 Jan 2022 13:43:19 -0800
Subject: Lots of allocations in CipherCore
In-Reply-To: <BA98969C-20B1-4A1D-AB56-901616420103@gmail.com>
References: <BA98969C-20B1-4A1D-AB56-901616420103@gmail.com>
Message-ID: <f5d91c66-f90c-4824-2c00-edf84b945399@oracle.com>

Hi,

I think it's a mistake. Looking at the old code I believe the if() for 
cipher.save() above that was suppose to include the new byte allocation 
and offset, but got missed.

Feel free to fix it if you like.  Let me know if you need something.

Tony

On 1/25/22 12:06 PM, Sebastian Stenzel wrote:
> Hi all,
> 
> while playing around with JFR today, I stumbled upon a piece of code 
> that causes a thousands of byte[] allocations. In fact it is responsible 
> for 90% of the memory allocations in my application and causes GC to run 
> without pause during decryption of large files.
> 
> The line in question can be found here?[1]. The behaviour can be 
> triggered with a simple AES-CTR cipher as in this minimal example [2].
> 
> As you can see, the comments in [1] even say that this byte[] _should_ 
> only be allocated if there is insufficient space in the provided output 
> buffer. However some kind of conditional statement is missing.
> 
> There used to be a `if (getMode() != GCM_MODE || outputCapacity < 
> estOutSize)`, before GCM has been decoupled from CipherCore. But this 
> line seems wrong to me either.
> 
> I guess this should be fixed, as I'm probably not the only one affected 
> by those allocations. I'd be volunteering, unless the behaviour is intended.
> 
> Cheers!
> Sebastian
> 
> 
> [1] 
> https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818 
> <https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818>
> [2] 
> https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5 
> <https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5>
> 
> 

From mullan at openjdk.java.net  Tue Jan 25 22:44:37 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 Jan 2022 22:44:37 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v5]
In-Reply-To: <kUClDrqDBeOzMIyisI8S3BKpfvbcvMfMb0Js91wgfaA=.3af94abb-6ea7-4aba-a422-c38b2abf7521@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <kUClDrqDBeOzMIyisI8S3BKpfvbcvMfMb0Js91wgfaA=.3af94abb-6ea7-4aba-a422-c38b2abf7521@github.com>
Message-ID: <P8UhUZd6T7_8wPx1VYoDj1RvDW9V2yXgnlzsWut-p_A=.fbb803c0-50ee-4a08-b15a-5fd4176d621d@github.com>

On Tue, 25 Jan 2022 20:51:17 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to get denyAfter from exception and reload caks

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 759:

> 757:                         "denyAfter constraint check failed: " + algorithm +
> 758:                         " used with Constraint date: " +
> 759:                         denyAfterDate + " (in java.security: " + denyAfterString +

An application could override what was in the `java.security` file by setting the property directly, so saying `java.security` is not totally precise. However, it seems you don't actually need to add this extra info to the exception messsage. Could we just use the `denyAfterDate` (after "used with Constraint date: ") and reformat it into YYYY-MM-DD format if necessary?

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

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

From hchao at openjdk.java.net  Wed Jan 26 05:38:17 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 05:38:17 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v6]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <LS0GCz4_zn-fFLgGnjsF5h_arMPlctnPg1VixVejOXU=.39bb0531-4707-406d-b01c-172652d76035@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Revert change to DisabledAlgorithmConstraints.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/74fd1423..53799e06

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

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

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

From hchao at openjdk.java.net  Wed Jan 26 05:50:05 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 05:50:05 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v7]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <Fk1kYNOfX8-lx0kOwJFbRpcx88bGgFUKExD7hN3a3lw=.90cbf009-0d33-47cf-8d3f-dc3280db53b3@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Reformat denyAfter date in exception message to YYYY-MM-DD

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/53799e06..34f7efd8

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

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

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

From hchao at openjdk.java.net  Wed Jan 26 05:50:08 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 05:50:08 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v5]
In-Reply-To: <P8UhUZd6T7_8wPx1VYoDj1RvDW9V2yXgnlzsWut-p_A=.fbb803c0-50ee-4a08-b15a-5fd4176d621d@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <kUClDrqDBeOzMIyisI8S3BKpfvbcvMfMb0Js91wgfaA=.3af94abb-6ea7-4aba-a422-c38b2abf7521@github.com>
 <P8UhUZd6T7_8wPx1VYoDj1RvDW9V2yXgnlzsWut-p_A=.fbb803c0-50ee-4a08-b15a-5fd4176d621d@github.com>
Message-ID: <H5yXO_pTRAjyo5kJMlo24Hvx5pqEJC00TjtQrUP8EAY=.f9df11fb-26ca-4b2c-9618-1070e4ec5c04@github.com>

On Tue, 25 Jan 2022 22:40:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to get denyAfter from exception and reload caks
>
> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 759:
> 
>> 757:                         "denyAfter constraint check failed: " + algorithm +
>> 758:                         " used with Constraint date: " +
>> 759:                         denyAfterDate + " (in java.security: " + denyAfterString +
> 
> An application could override what was in the `java.security` file by setting the property directly, so saying `java.security` is not totally precise. However, it seems you don't actually need to add this extra info to the exception messsage. Could we just use the `denyAfterDate` (after "used with Constraint date: ") and reformat it into YYYY-MM-DD format if necessary?

Done. Removed the extra info (YYYY-MM-DD form) from the exception message that was set in `DisabledAlgorithmConstraints` class, and re-formated the `denyAfterDate` into YYYY-MM-DD format in keytool.

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

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

From hchao at openjdk.java.net  Wed Jan 26 05:59:32 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 05:59:32 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v5]
In-Reply-To: <H5yXO_pTRAjyo5kJMlo24Hvx5pqEJC00TjtQrUP8EAY=.f9df11fb-26ca-4b2c-9618-1070e4ec5c04@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <kUClDrqDBeOzMIyisI8S3BKpfvbcvMfMb0Js91wgfaA=.3af94abb-6ea7-4aba-a422-c38b2abf7521@github.com>
 <P8UhUZd6T7_8wPx1VYoDj1RvDW9V2yXgnlzsWut-p_A=.fbb803c0-50ee-4a08-b15a-5fd4176d621d@github.com>
 <H5yXO_pTRAjyo5kJMlo24Hvx5pqEJC00TjtQrUP8EAY=.f9df11fb-26ca-4b2c-9618-1070e4ec5c04@github.com>
Message-ID: <YRvHZSXIN8TdZjI1xA3l_ox6U2qBgKRWiGfctakT1ak=.72da00f9-dab2-4f76-87d8-74a48007258d@github.com>

On Wed, 26 Jan 2022 05:45:58 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 759:
>> 
>>> 757:                         "denyAfter constraint check failed: " + algorithm +
>>> 758:                         " used with Constraint date: " +
>>> 759:                         denyAfterDate + " (in java.security: " + denyAfterString +
>> 
>> An application could override what was in the `java.security` file by setting the property directly, so saying `java.security` is not totally precise. However, it seems you don't actually need to add this extra info to the exception messsage. Could we just use the `denyAfterDate` (after "used with Constraint date: ") and reformat it into YYYY-MM-DD format if necessary?
>
> Done. Removed the extra info (YYYY-MM-DD form) from the exception message that was set in `DisabledAlgorithmConstraints` class, and re-formated the `denyAfterDate` into YYYY-MM-DD format in keytool.

The CertPathValidatorException is: `denyAfter constraint check failed: SHA1 used with Constraint date: Mon Dec 31 16:00:00 PST 2018; params date: Tue Jan 25 19:56:48 PST 2022 used with certificate: CN=CA`
So, the reformat of the `denyAfterDate` to YYYY-MM-DD format will be 2018-12-31.

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

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

From sebastian.stenzel at gmail.com  Wed Jan 26 10:44:03 2022
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Wed, 26 Jan 2022 11:44:03 +0100
Subject: Lots of allocations in CipherCore
In-Reply-To: <f5d91c66-f90c-4824-2c00-edf84b945399@oracle.com>
References: <BA98969C-20B1-4A1D-AB56-901616420103@gmail.com>
 <f5d91c66-f90c-4824-2c00-edf84b945399@oracle.com>
Message-ID: <8096AF88-379C-4620-93F3-90CA149F7B76@gmail.com>

Hi Tony,

while running regression tests, I noticed that my assumption only holds true for unpadded ciphers. For padded ciphers, we still need the temporary buffer, as only the unpadded cleartext shall be written to the output buffer.

That said, here is my PR. I'd be happy if you could review it (and act as a sponsor for the commit): https://github.com/openjdk/jdk/pull/7230 <https://github.com/openjdk/jdk/pull/7230>

Cheers!
Sebastian

> On 25. Jan 2022, at 22:43, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> Hi,
> 
> I think it's a mistake. Looking at the old code I believe the if() for cipher.save() above that was suppose to include the new byte allocation and offset, but got missed.
> 
> Feel free to fix it if you like.  Let me know if you need something.
> 
> Tony
> 
> On 1/25/22 12:06 PM, Sebastian Stenzel wrote:
>> Hi all,
>> while playing around with JFR today, I stumbled upon a piece of code that causes a thousands of byte[] allocations. In fact it is responsible for 90% of the memory allocations in my application and causes GC to run without pause during decryption of large files.
>> The line in question can be found here [1]. The behaviour can be triggered with a simple AES-CTR cipher as in this minimal example [2].
>> As you can see, the comments in [1] even say that this byte[] _should_ only be allocated if there is insufficient space in the provided output buffer. However some kind of conditional statement is missing.
>> There used to be a `if (getMode() != GCM_MODE || outputCapacity < estOutSize)`, before GCM has been decoupled from CipherCore. But this line seems wrong to me either.
>> I guess this should be fixed, as I'm probably not the only one affected by those allocations. I'd be volunteering, unless the behaviour is intended.
>> Cheers!
>> Sebastian
>> [1] https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818 <https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818>
>> [2] https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5 <https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220126/95d36e5b/attachment.htm>

From duke at openjdk.java.net  Wed Jan 26 10:45:47 2022
From: duke at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 26 Jan 2022 10:45:47 GMT
Subject: RFR: JDK-8280703 CipherCore.doFinal(...) causes potentially massive
 byte[] allocations during decryption
Message-ID: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>

Related to #411, however it turns out that for unpadded ciphers, there is no need to allocate `internalOutput`, if `output` provides sufficient capacity.

For padded ciphers, only the unpadded cleartext is expected to be copied to the output buffer. In this case, there is no way around the temporary buffer (without major changes).

While a small change, please review with care, as I might be missing some security-relevant side effect (such as: don't copy cleartext to output buffer before validating the a tag - just as an example, even if there is no authentication involved in this method).

I have some test failures in Tier 1 tests, but these seem to be unrelated. Tests for `com.sun.crypto` and `javax.crypto` run fine:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/com/sun/crypto                       141   141     0     0   
   jtreg:test/jdk/javax/crypto                          56    56     0     0   
==============================
TEST SUCCESS

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

Commit messages:
 - keep using a temporary buffer for unpadding the cleartext
 - only allocate internal buffer in case of insufficient output capacity

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

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

From mullan at openjdk.java.net  Wed Jan 26 14:33:38 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 26 Jan 2022 14:33:38 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v7]
In-Reply-To: <Fk1kYNOfX8-lx0kOwJFbRpcx88bGgFUKExD7hN3a3lw=.90cbf009-0d33-47cf-8d3f-dc3280db53b3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <Fk1kYNOfX8-lx0kOwJFbRpcx88bGgFUKExD7hN3a3lw=.90cbf009-0d33-47cf-8d3f-dc3280db53b3@github.com>
Message-ID: <NOEH5wYEuUaW-QHUhMmrEIc9UAqz-8ottUW94DOH85Y=.3b2276d3-f0ef-4ee0-b0d0-f37c81c26a43@github.com>

On Wed, 26 Jan 2022 05:50:05 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat denyAfter date in exception message to YYYY-MM-DD

Marked as reviewed by mullan (Reviewer).

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

> 4918:                     String endSeparator = "; params date";
> 4919:                     int endSepPos = eMessage.indexOf(endSeparator);
> 4920:                     String denyAfterDate = eMessage.substring(startSepPos + startSeparator.length(),

I think you should catch `IndexOutOfBoundException` here, just in case, and bail out with your new error message "Unable.to.parse.denyAfter.string.in.exception.message".

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

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

From michaelm at openjdk.java.net  Wed Jan 26 15:41:22 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 26 Jan 2022 15:41:22 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v9]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <hYiwg7Lw5GEqiDqCnYPPy97ELUog5jVoeNIJrkVgtJk=.2968f900-93d4-4646-b72f-3e20ab649c5e@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  Added unit test and comment update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/004466ea..e5a5a79a

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

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

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

From mullan at openjdk.java.net  Wed Jan 26 15:51:29 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 26 Jan 2022 15:51:29 GMT
Subject: RFR: 8280546: Remove hard-coded 127.0.0.1 loopback address
In-Reply-To: <P9Q9J7JbUV7sh3T00IWM4p75sjh3xfoZeSMr0Tdt2LI=.38b6a77d-801a-4565-a623-786740b7b21f@github.com>
References: <P9Q9J7JbUV7sh3T00IWM4p75sjh3xfoZeSMr0Tdt2LI=.38b6a77d-801a-4565-a623-786740b7b21f@github.com>
Message-ID: <DMEhdoMNnSBcfzrx-qJ-wWdB8GUGzJqv8r1e_u4EfyU=.c1823707-1280-49bc-b667-e9e567ec7416@github.com>

On Tue, 25 Jan 2022 03:39:54 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change replaces hard-coded 127.0.0.1 loopback addresses with `InetAddress.getLoopbackAddress().getHostAddress()`, to allow the tests to work on IPv6-only systems. This matches the approach of previous fixes in [JDK-8220083](https://bugs.openjdk.java.net/browse/JDK-8220083).

This looks fine to me. Please change the JBS bug component to "security-libs" as these tests are in the security area.

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

Marked as reviewed by mullan (Reviewer).

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

From michaelm at openjdk.java.net  Wed Jan 26 16:02:09 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 26 Jan 2022 16:02:09 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v10]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  removed ^M from test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/e5a5a79a..b44184de

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

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

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

From dfuchs at openjdk.java.net  Wed Jan 26 16:32:38 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 26 Jan 2022 16:32:38 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v10]
In-Reply-To: <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>
Message-ID: <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>

On Wed, 26 Jan 2022 16:02:09 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed ^M from test

Looks mostly good. Some doubts about catching just any exception indiscriminately though.

test/jdk/sun/security/krb5/auto/HttpsCB.java line 120:

> 118: 
> 119:         boolean expected1 = Boolean.parseBoolean(args[0]);
> 120:         boolean expected2 = Boolean.parseBoolean(args[1]);

It might be better for future maintainers and readability if these two variables could have better names, and possibly a comment to explain their purpose. AFAIU it's the expected result of running with/without CBT - where `true` means that the operation should succeed and `false` that it's expected to fail with some exception...

test/jdk/sun/security/krb5/auto/HttpsCB.java line 201:

> 199:             return reader.readLine().equals(CONTENT);
> 200:         } catch (Exception e) {
> 201:             return false;

Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting?

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

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

From ascarpino at openjdk.java.net  Wed Jan 26 17:34:41 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 26 Jan 2022 17:34:41 GMT
Subject: RFR: JDK-8280703 CipherCore.doFinal(...) causes potentially
 massive byte[] allocations during decryption
In-Reply-To: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
References: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
Message-ID: <Lvaf93wUcYgiB5uMGjzHsPqoVy0iVOu14VGtYN8A3o0=.0d31e613-36f0-4061-aa00-f468348dc731@github.com>

On Wed, 26 Jan 2022 10:07:01 GMT, Sebastian Stenzel <duke at openjdk.java.net> wrote:

> Related to #411, however it turns out that for unpadded ciphers, there is no need to allocate `internalOutput`, if `output` provides sufficient capacity.
> 
> For padded ciphers, only the unpadded cleartext is expected to be copied to the output buffer. In this case, there is no way around the temporary buffer (without major changes).
> 
> While a small change, please review with care, as I might be missing some security-relevant side effect (such as: don't copy cleartext to output buffer before validating the a tag - just as an example, even if there is no authentication involved in this method).
> 
> I have some test failures in Tier 1 tests, but these seem to be unrelated. Tests for `com.sun.crypto` and `javax.crypto` run fine:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/com/sun/crypto                       141   141     0     0   
>    jtreg:test/jdk/javax/crypto                          56    56     0     0   
> ==============================
> TEST SUCCESS

The copyright date will need to be updated from 2021 to 2022

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

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

From hchao at openjdk.java.net  Wed Jan 26 17:43:08 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 17:43:08 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v8]
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <Jbo1pH_dUIsYNg6Vkw0Q5lUgyQ7osVrJBLK5kau_PZ0=.ad44d35f-708c-47cb-a7b0-0e5bc4a0e06a@github.com>

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

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

  Update test as reformatted denyAfterDate not fixed that depends on date in exception msg

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7039/files
  - new: https://git.openjdk.java.net/jdk/pull/7039/files/34f7efd8..f7358702

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

  Stats: 13 lines in 2 files changed: 6 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7039/head:pull/7039

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

From hchao at openjdk.java.net  Wed Jan 26 17:43:12 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 17:43:12 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v7]
In-Reply-To: <NOEH5wYEuUaW-QHUhMmrEIc9UAqz-8ottUW94DOH85Y=.3b2276d3-f0ef-4ee0-b0d0-f37c81c26a43@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <Fk1kYNOfX8-lx0kOwJFbRpcx88bGgFUKExD7hN3a3lw=.90cbf009-0d33-47cf-8d3f-dc3280db53b3@github.com>
 <NOEH5wYEuUaW-QHUhMmrEIc9UAqz-8ottUW94DOH85Y=.3b2276d3-f0ef-4ee0-b0d0-f37c81c26a43@github.com>
Message-ID: <w8KCvk7XKJBWSHRGhXBNU7a0g7BKCZyVy74Ai0DqPZg=.3cdaa7a3-89ba-4478-a238-294bda8ac065@github.com>

On Wed, 26 Jan 2022 14:30:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reformat denyAfter date in exception message to YYYY-MM-DD
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4920:
> 
>> 4918:                     String endSeparator = "; params date";
>> 4919:                     int endSepPos = eMessage.indexOf(endSeparator);
>> 4920:                     String denyAfterDate = eMessage.substring(startSepPos + startSeparator.length(),
> 
> I think you should catch `IndexOutOfBoundException` here, just in case, and bail out with your new error message "Unable.to.parse.denyAfter.string.in.exception.message".

Fixed.

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

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

From hchao at openjdk.java.net  Wed Jan 26 17:43:15 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 17:43:15 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v5]
In-Reply-To: <YRvHZSXIN8TdZjI1xA3l_ox6U2qBgKRWiGfctakT1ak=.72da00f9-dab2-4f76-87d8-74a48007258d@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <kUClDrqDBeOzMIyisI8S3BKpfvbcvMfMb0Js91wgfaA=.3af94abb-6ea7-4aba-a422-c38b2abf7521@github.com>
 <P8UhUZd6T7_8wPx1VYoDj1RvDW9V2yXgnlzsWut-p_A=.fbb803c0-50ee-4a08-b15a-5fd4176d621d@github.com>
 <H5yXO_pTRAjyo5kJMlo24Hvx5pqEJC00TjtQrUP8EAY=.f9df11fb-26ca-4b2c-9618-1070e4ec5c04@github.com>
 <YRvHZSXIN8TdZjI1xA3l_ox6U2qBgKRWiGfctakT1ak=.72da00f9-dab2-4f76-87d8-74a48007258d@github.com>
Message-ID: <AQWV8z35qCh2rtyzPR84Ath1YF2rq4LRitp2u2W86DM=.90ac538e-bbde-415d-ad66-018227ea559d@github.com>

On Wed, 26 Jan 2022 05:56:31 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Done. Removed the extra info (YYYY-MM-DD form) from the exception message that was set in `DisabledAlgorithmConstraints` class, and re-formated the `denyAfterDate` into YYYY-MM-DD format in keytool.
>
> The CertPathValidatorException is: `denyAfter constraint check failed: SHA1 used with Constraint date: Mon Dec 31 16:00:00 PST 2018; params date: Tue Jan 25 19:56:48 PST 2022 used with certificate: CN=CA`
> So, the reformat of the `denyAfterDate` to YYYY-MM-DD format will be 2018-12-31.

Additional regression tests on various platforms showed that the exception messages could be:
CertPathValidatorException: `denyAfter constraint check failed: SHA1 used with Constraint date: Tue Jan 01 00:00:00 GMT 2019; params date: Wed Jan 26 11:02:48 GMT 2022 used with certificate: CN=CA`
CertPathValidatorException: `denyAfter constraint check failed: SHA1 used with Constraint date: Tue Jan 01 00:00:00 UTC 2019; params date: Wed Jan 26 10:39:02 UTC 2022 used with certificate: CN=CA`
Hence, updated test to not check for a fixed date as the reformatted `denyAfterDate` done in keytool depends on the exception messages.

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

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

From cushon at openjdk.java.net  Wed Jan 26 17:43:39 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 26 Jan 2022 17:43:39 GMT
Subject: RFR: 8280546: Remove hard-coded 127.0.0.1 loopback address
In-Reply-To: <DMEhdoMNnSBcfzrx-qJ-wWdB8GUGzJqv8r1e_u4EfyU=.c1823707-1280-49bc-b667-e9e567ec7416@github.com>
References: <P9Q9J7JbUV7sh3T00IWM4p75sjh3xfoZeSMr0Tdt2LI=.38b6a77d-801a-4565-a623-786740b7b21f@github.com>
 <DMEhdoMNnSBcfzrx-qJ-wWdB8GUGzJqv8r1e_u4EfyU=.c1823707-1280-49bc-b667-e9e567ec7416@github.com>
Message-ID: <4ipQzcU-zQUKNS--pBSXbTc7zZk9WZrSfh-6DCWxCLM=.dde8d861-a49b-4fda-a996-9d6c31f2b3b6@github.com>

On Wed, 26 Jan 2022 15:48:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please change the JBS bug component to "security-libs" as these tests are in the security area.

Done. Thanks for the review!

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

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

From cushon at openjdk.java.net  Wed Jan 26 17:43:40 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 26 Jan 2022 17:43:40 GMT
Subject: Integrated: 8280546: Remove hard-coded 127.0.0.1 loopback address
In-Reply-To: <P9Q9J7JbUV7sh3T00IWM4p75sjh3xfoZeSMr0Tdt2LI=.38b6a77d-801a-4565-a623-786740b7b21f@github.com>
References: <P9Q9J7JbUV7sh3T00IWM4p75sjh3xfoZeSMr0Tdt2LI=.38b6a77d-801a-4565-a623-786740b7b21f@github.com>
Message-ID: <pvzXTx71bRJmO35O5puTw3U80d8EHQvrSbsvmp0dmuo=.4daedbde-8a1a-43b2-8d1f-9d898bda9b7c@github.com>

On Tue, 25 Jan 2022 03:39:54 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change replaces hard-coded 127.0.0.1 loopback addresses with `InetAddress.getLoopbackAddress().getHostAddress()`, to allow the tests to work on IPv6-only systems. This matches the approach of previous fixes in [JDK-8220083](https://bugs.openjdk.java.net/browse/JDK-8220083).

This pull request has now been integrated.

Changeset: b5de2cc9
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b5de2cc9d36e1fad7d0bf70f7c83ff829e16b7f3
Stats:     5 lines in 2 files changed: 3 ins; 0 del; 2 mod

8280546: Remove hard-coded 127.0.0.1 loopback address

Reviewed-by: mullan

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

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

From duke at openjdk.java.net  Wed Jan 26 18:07:24 2022
From: duke at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 26 Jan 2022 18:07:24 GMT
Subject: RFR: JDK-8280703 CipherCore.doFinal(...) causes potentially
 massive byte[] allocations during decryption [v2]
In-Reply-To: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
References: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
Message-ID: <vKEEi8z4xKsVupXlhbK0_N8HIYeYmjoDVFbBx7mAoTg=.af7643b7-a63a-4d1b-88dc-713a27c6d093@github.com>

> Related to #411, however it turns out that for unpadded ciphers, there is no need to allocate `internalOutput`, if `output` provides sufficient capacity.
> 
> For padded ciphers, only the unpadded cleartext is expected to be copied to the output buffer. In this case, there is no way around the temporary buffer (without major changes).
> 
> While a small change, please review with care, as I might be missing some security-relevant side effect (such as: don't copy cleartext to output buffer before validating the a tag - just as an example, even if there is no authentication involved in this method).
> 
> I have some test failures in Tier 1 tests, but these seem to be unrelated. Tests for `com.sun.crypto` and `javax.crypto` run fine:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/com/sun/crypto                       141   141     0     0   
>    jtreg:test/jdk/javax/crypto                          56    56     0     0   
> ==============================
> TEST SUCCESS

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

  updated copyright header

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7230/files
  - new: https://git.openjdk.java.net/jdk/pull/7230/files/520fec52..ffef8362

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

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

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

From xuelei at openjdk.java.net  Wed Jan 26 18:58:07 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 26 Jan 2022 18:58:07 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled [v2]
In-Reply-To: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
Message-ID: <CbkUCTEJ14-Em7UKsjDkZMYuHXS1j_gMjlgTl4ufhXI=.4126366b-9cdc-44d2-9e41-8fc83b0d1657@github.com>

> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
> 
> The update could be verified with jshell.
> $ $JDK_HOME/bin/jshell
> jshell> URL url = new URL("https://www.google.com./");
> jshell> URLConnection conn = url.openConnection();
> jshell> conn.connect();

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

  Add regression test with customized hosts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7205/files
  - new: https://git.openjdk.java.net/jdk/pull/7205/files/3c94dfc5..fe3e5f6b

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

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

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

From xuelei at openjdk.java.net  Wed Jan 26 18:58:09 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 26 Jan 2022 18:58:09 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled
In-Reply-To: <bV-JDcOOAGBa5f-AGVLuLprqOPpAiqA0ziZaGRQkNZs=.49da56d2-66bd-4860-814a-218f632a81d8@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
 <bV-JDcOOAGBa5f-AGVLuLprqOPpAiqA0ziZaGRQkNZs=.49da56d2-66bd-4860-814a-218f632a81d8@github.com>
Message-ID: <RItLIgCu25ERqjI2V_Sk-p9qQcsjxEKX3c2EF01R3og=.3bdcbe75-292c-46e6-af0b-7f67f1db7140@github.com>

On Tue, 25 Jan 2022 14:16:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Is it possible to add a regression test using the `-Djdk.net.hosts.file` feature? It is a JVM-only `/etc/hosts` alternative.

Good to know that.  I added the test with customized hosts, and use URL "www.example.com.".

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

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

From weijun at openjdk.java.net  Wed Jan 26 19:03:40 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 26 Jan 2022 19:03:40 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v10]
In-Reply-To: <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>
 <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>
Message-ID: <bC7xWfn4GCWVbbCs05LE-2KACTVEHTkTvZE3luSK55A=.450d8e5b-c648-40a0-b1ec-7c935541eec1@github.com>

On Wed, 26 Jan 2022 16:27:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed ^M from test
>
> test/jdk/sun/security/krb5/auto/HttpsCB.java line 201:
> 
>> 199:             return reader.readLine().equals(CONTENT);
>> 200:         } catch (Exception e) {
>> 201:             return false;
> 
> Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting?

It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing.

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

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

From weijun at openjdk.java.net  Wed Jan 26 19:08:38 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 26 Jan 2022 19:08:38 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v10]
In-Reply-To: <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>
 <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>
Message-ID: <IPNLsVaPC8dC-DGFb7EQXCcL5pOf4ml5U7aZJQ3UFH0=.22a7ad93-13b3-42e7-9206-05aae2d28fa1@github.com>

On Wed, 26 Jan 2022 16:25:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed ^M from test
>
> test/jdk/sun/security/krb5/auto/HttpsCB.java line 120:
> 
>> 118: 
>> 119:         boolean expected1 = Boolean.parseBoolean(args[0]);
>> 120:         boolean expected2 = Boolean.parseBoolean(args[1]);
> 
> It might be better for future maintainers and readability if these two variables could have better names, and possibly a comment to explain their purpose. AFAIU it's the expected result of running with/without CBT - where `true` means that the operation should succeed and `false` that it's expected to fail with some exception...

Maybe `expectedCbtUrlResult` and `expectedNormalUrlResult`.

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

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

From hchao at openjdk.java.net  Wed Jan 26 20:31:33 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 20:31:33 GMT
Subject: RFR: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints [v7]
In-Reply-To: <NOEH5wYEuUaW-QHUhMmrEIc9UAqz-8ottUW94DOH85Y=.3b2276d3-f0ef-4ee0-b0d0-f37c81c26a43@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
 <Fk1kYNOfX8-lx0kOwJFbRpcx88bGgFUKExD7hN3a3lw=.90cbf009-0d33-47cf-8d3f-dc3280db53b3@github.com>
 <NOEH5wYEuUaW-QHUhMmrEIc9UAqz-8ottUW94DOH85Y=.3b2276d3-f0ef-4ee0-b0d0-f37c81c26a43@github.com>
Message-ID: <-sN8ayrk-soBNwtVxY6SfxhQyzPaxRtc0bhUGpiwAts=.f8108a7b-4316-4586-b82d-5b85d7c85017@github.com>

On Wed, 26 Jan 2022 14:30:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reformat denyAfter date in exception message to YYYY-MM-DD
>
> Marked as reviewed by mullan (Reviewer).

@seanjmullan Thanks for your review!

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

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

From hchao at openjdk.java.net  Wed Jan 26 20:34:45 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 26 Jan 2022 20:34:45 GMT
Subject: Integrated: 8273236: keytool does not accurately warn about algorithms
 that are disabled but have additional constraints
In-Reply-To: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
References: <Az6voL2AQ7t4JbMXUIQZm_WzYobggPTmCTisieXGjp8=.e5408f3f-a1ec-413e-a8da-bebab0fde5c3@github.com>
Message-ID: <eYTiArETm5m8ID4evMPP86E82AI9H8TR4TSjQl41LUk=.446dedf8-9906-451b-841c-efea2d02cfaf@github.com>

On Wed, 12 Jan 2022 02:15:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> `keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor.

This pull request has now been integrated.

Changeset: c2ee1b33
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c2ee1b33c37e6f2848dc8b3e5417b93b1dac1112
Stats:     432 lines in 3 files changed: 377 ins; 0 del; 55 mod

8273236: keytool does not accurately warn about algorithms that are disabled but have additional constraints

Reviewed-by: mullan

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

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

From myano at openjdk.java.net  Thu Jan 27 08:01:34 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 27 Jan 2022 08:01:34 GMT
Subject: RFR: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid
 subjectAlternativeNames [v2]
In-Reply-To: <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
References: <asBcdBBAhog87FzLP0wFU1UAxY6MOGVFHPXTpXnq4Jg=.7bd62829-36db-422f-8b3a-a0f53595238d@github.com>
 <Jgidq3zK2KZ8rCo028HOBcnfo4jwMrKi3tkjqqsBHwU=.690a0d1e-8cff-4325-b378-d4247bd91214@github.com>
Message-ID: <dZiVa37q6ewkb28yoHHclHYVMBk8W4-WnJ3uQm1TOsc=.51395902-af72-4b90-a9a0-48612782c11d@github.com>

On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the JDK-8255739 bug fix?
>> 
>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>> 
>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255739: x509Certificate returns ? for invalid subjectAlternativeNames

Thank you for discussing this with many comments.

I understood that the fix is risky, requires additional matching checks, and is preferable to be selectable by a parameter.
I would like to consider them, but it will take a little time to reflect them in the change.

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

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

From phh at openjdk.java.net  Thu Jan 27 14:37:39 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 27 Jan 2022 14:37:39 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <qA07oqlMKvhaMBGivvakHmfb9mSSLBfVxT09le2oE5g=.2e86a6b4-55e6-4833-9c5b-5c721c60440b@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Hi, Boris,

I'd go with option 2 for this patch and option 1 in a separate JBS issue. Safer and more straightforward that way. The only change I'd make to the [option 2 patch](https://github.com/bulasevich/jdk/commit/095fc9db) is to try replace raw constants with derivations of DM. E.g. in smChi() replace 0, 5, 10, 15, 20, and 25 with 0*DM, 1*DM, 2*DM, 3*DM, 4*DM, and 5*DM. In smTheta, replace a[0] with a[0*DM], a[1] with a[0*DM+1], etc. But, if doing so causes C2 to fail to constant fold, revert to raw constants.

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

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

From phh at openjdk.java.net  Thu Jan 27 15:39:41 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 27 Jan 2022 15:39:41 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <n7rqOlB9NPI9rfjXJFr94bZMyxf5xnbx8l_etsxry08=.4e064657-d242-491c-b9da-3879099647eb@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Also, going with option 2 first leaves a progression record that might be useful to future compiler optimizer implementors.

The option 1 patch looks good too.

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

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

From michaelm at openjdk.java.net  Thu Jan 27 15:54:15 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 27 Jan 2022 15:54:15 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v11]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <G0yVl3EH_KdI7mXaFh3TzH0f_tc25ihG_Kn3RH4mweE=.b2ec31dc-10fb-46b3-bf21-1848d2a5dcb2@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  test update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/b44184de..d604ee7f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=09-10

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

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

From dfuchs at openjdk.java.net  Thu Jan 27 16:50:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 27 Jan 2022 16:50:49 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v10]
In-Reply-To: <bC7xWfn4GCWVbbCs05LE-2KACTVEHTkTvZE3luSK55A=.450d8e5b-c648-40a0-b1ec-7c935541eec1@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>
 <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>
 <bC7xWfn4GCWVbbCs05LE-2KACTVEHTkTvZE3luSK55A=.450d8e5b-c648-40a0-b1ec-7c935541eec1@github.com>
Message-ID: <TAPRlDbSJaF7WNsqxRvSXJkf0W1Xt5wbCBrfWKeh-zI=.d10f2421-7010-4162-9276-a2b610998f01@github.com>

On Wed, 26 Jan 2022 19:00:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/krb5/auto/HttpsCB.java line 201:
>> 
>>> 199:             return reader.readLine().equals(CONTENT);
>>> 200:         } catch (Exception e) {
>>> 201:             return false;
>> 
>> Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting?
>
> It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing.

Thanks. Then it would be better to catch only `SocketException` here rather than `Exception`.

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

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

From ascarpino at openjdk.java.net  Thu Jan 27 17:24:32 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 27 Jan 2022 17:24:32 GMT
Subject: RFR: JDK-8280703 CipherCore.doFinal(...) causes potentially
 massive byte[] allocations during decryption [v2]
In-Reply-To: <vKEEi8z4xKsVupXlhbK0_N8HIYeYmjoDVFbBx7mAoTg=.af7643b7-a63a-4d1b-88dc-713a27c6d093@github.com>
References: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
 <vKEEi8z4xKsVupXlhbK0_N8HIYeYmjoDVFbBx7mAoTg=.af7643b7-a63a-4d1b-88dc-713a27c6d093@github.com>
Message-ID: <1AJl9L6kCIcGYPCQuf83lbVQJfCLdWt1bsZD9vNp8J4=.161d2256-4caa-4efd-a462-42b82f4d86f2@github.com>

On Wed, 26 Jan 2022 18:07:24 GMT, Sebastian Stenzel <duke at openjdk.java.net> wrote:

>> Related to #411, however it turns out that for unpadded ciphers, there is no need to allocate `internalOutput`, if `output` provides sufficient capacity.
>> 
>> For padded ciphers, only the unpadded cleartext is expected to be copied to the output buffer. In this case, there is no way around the temporary buffer (without major changes).
>> 
>> While a small change, please review with care, as I might be missing some security-relevant side effect (such as: don't copy cleartext to output buffer before validating the a tag - just as an example, even if there is no authentication involved in this method).
>> 
>> I have some test failures in Tier 1 tests, but these seem to be unrelated. Tests for `com.sun.crypto` and `javax.crypto` run fine:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/com/sun/crypto                       141   141     0     0   
>>    jtreg:test/jdk/javax/crypto                          56    56     0     0   
>> ==============================
>> TEST SUCCESS
>
> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright header

The diff passed tier1 and crypto tests.  Looks good to me

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

Marked as reviewed by ascarpino (Reviewer).

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

From cjplummer at openjdk.java.net  Thu Jan 27 17:40:37 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 27 Jan 2022 17:40:37 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
Message-ID: <Ydqi0fM-Jlc2gSlSWexJWyiDpQiOf-St_khcexyHkLA=.02ea589e-3be8-422d-9b11-ab2d1d518a43@github.com>

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

Marked as reviewed by cjplummer (Reviewer).

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

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

From ascarpino at openjdk.java.net  Thu Jan 27 17:43:38 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 27 Jan 2022 17:43:38 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <3IENCx7ke0FRfmlYkHRf5fcOLGRCxTb9ccZw2YoFcBY=.7adcfbc0-5b2f-4c96-94cf-1dd55b8883ae@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Sorry this feel off my stack with the holidays and everything else going on.
I am fine proceeding change in this PR, option 1 I believe. Have you run the tests to make sure it passes the Known Answer Tests?
Can you also include the before and after JMH benchmarks for SHA3 in the PR?  they are under test/micro/org/openjdk/bench/java/security/MessageDigests

Thanks

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

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

From rriggs at openjdk.java.net  Thu Jan 27 17:48:35 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 27 Jan 2022 17:48:35 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
Message-ID: <0Lxi3U1p3qn6Jyl7Uy7UU4RLi95JNCliqhqfEF1l_6A=.a4d281a7-44d9-49e0-ae93-6a652a52d87f@github.com>

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

LGTM

test/jdk/sun/tools/jstatd/JstatdTest.java line 2:

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

Update copyrights.

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

Marked as reviewed by rriggs (Reviewer).

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

From michaelm at openjdk.java.net  Thu Jan 27 18:05:25 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 27 Jan 2022 18:05:25 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v12]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

 - test update
 - Merge branch 'master' into spnego
 - test update
 - removed ^M from test
 - Added unit test and comment update
 - final review update (pre CSR)
 - more updates
 - fixed failing test issue and update for latest comments
 - Merge branch 'master' into spnego
 - added root cause to NamingException
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/35ce454c...59f703da

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/d604ee7f..59f703da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=10-11

  Stats: 4735 lines in 368 files changed: 2835 ins; 809 del; 1091 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7065.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065

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

From michaelm at openjdk.java.net  Thu Jan 27 18:05:27 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 27 Jan 2022 18:05:27 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v10]
In-Reply-To: <TAPRlDbSJaF7WNsqxRvSXJkf0W1Xt5wbCBrfWKeh-zI=.d10f2421-7010-4162-9276-a2b610998f01@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <ouNpuyF_K100fRcPhkdCwc-Pg0a02tV2UfEzRyjfTkw=.e60ac370-44f6-4a15-b0b0-de6e70b59478@github.com>
 <IG7kfMqSV08nQaWkzNuBUoI4SdHQW10qD5mZiBi3brA=.e94d083f-b6ee-4a02-94d0-ebf62b2a4e64@github.com>
 <bC7xWfn4GCWVbbCs05LE-2KACTVEHTkTvZE3luSK55A=.450d8e5b-c648-40a0-b1ec-7c935541eec1@github.com>
 <TAPRlDbSJaF7WNsqxRvSXJkf0W1Xt5wbCBrfWKeh-zI=.d10f2421-7010-4162-9276-a2b610998f01@github.com>
Message-ID: <64ecMlTGcFJvgXe-Wo_R7F_3yrxSom_mb549yKt0MGo=.9b40e87d-59be-4a63-8b05-947afa00f475@github.com>

On Thu, 27 Jan 2022 16:47:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing.
>
> Thanks. Then it would be better to catch only `SocketException` here rather than `Exception`.

I'll make it catch `IOException`

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

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

From dfuchs at openjdk.java.net  Thu Jan 27 18:12:47 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 27 Jan 2022 18:12:47 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v12]
In-Reply-To: <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com>
Message-ID: <scuvTviR58Sc3_tuiBf2NEPC8t68SeqEwri3BRTxvmo=.9f91bb5b-a749-4945-9ca9-3a265b3a76f0@github.com>

On Thu, 27 Jan 2022 18:05:25 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - test update
>  - Merge branch 'master' into spnego
>  - test update
>  - removed ^M from test
>  - Added unit test and comment update
>  - final review update (pre CSR)
>  - more updates
>  - fixed failing test issue and update for latest comments
>  - Merge branch 'master' into spnego
>  - added root cause to NamingException
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/ceb44101...59f703da

LGTM!

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

Marked as reviewed by dfuchs (Reviewer).

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

From kevinw at openjdk.java.net  Thu Jan 27 18:27:14 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 27 Jan 2022 18:27:14 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v3]
In-Reply-To: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
Message-ID: <VseqaxLbIjPlpP9X3p7KzTgFyKOxzTmPdOzDHM5OFIM=.9516f8c1-3105-4534-b8ff-3f508c3aac8f@github.com>

> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
> 
> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
> ..as that is no longer needed.
> 
> Docs/man page update to follow (JDK-8278619).

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

  Copyright update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6919/files
  - new: https://git.openjdk.java.net/jdk/pull/6919/files/e49b9fe2..443b18b4

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

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

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

From kevinw at openjdk.java.net  Thu Jan 27 18:27:17 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 27 Jan 2022 18:27:17 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
Message-ID: <6ZHzhq7yufRXfEMcPQOkK4qkD4E0yzYTuoC5P05ia_g=.ab33d4ad-95fa-4fef-ac12-c2444819da9c@github.com>

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>> 
>> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
>> ..as that is no longer needed.
>> 
>> Docs/man page update to follow (JDK-8278619).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.

Many thanks Chris, Roger!

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

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

From kevinw at openjdk.java.net  Thu Jan 27 18:27:18 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 27 Jan 2022 18:27:18 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v2]
In-Reply-To: <0Lxi3U1p3qn6Jyl7Uy7UU4RLi95JNCliqhqfEF1l_6A=.a4d281a7-44d9-49e0-ae93-6a652a52d87f@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
 <zVs4n3eWOW9qrz0cEuMe2JKa5A0kVWq3k6Y1wX2ok9U=.dd027138-ba23-4384-a7c6-45d92ef0e159@github.com>
 <0Lxi3U1p3qn6Jyl7Uy7UU4RLi95JNCliqhqfEF1l_6A=.a4d281a7-44d9-49e0-ae93-6a652a52d87f@github.com>
Message-ID: <98pqpp2wEkSGlCL_5SrRGY8mooq2CjUuTV4H_56Aqi8=.95f8d69f-0638-462d-a83a-04dc4c693421@github.com>

On Thu, 27 Jan 2022 17:44:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.
>
> test/jdk/sun/tools/jstatd/JstatdTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Update copyrights.

Yes, thanks, time has moved on since I started!...

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

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

From xuelei at openjdk.java.net  Thu Jan 27 22:13:44 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 27 Jan 2022 22:13:44 GMT
Subject: RFR: 8280494: (D)TLS signature schemes
Message-ID: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>

This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

Commit messages:
 - 8280494: https://bugs.openjdk.java.net/browse/JDK-8280494
 - 8280494: Implementation: (D)TLS signature schemes

Changes: https://git.openjdk.java.net/jdk/pull/7252/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280494
  Stats: 297 lines in 4 files changed: 253 ins; 12 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252

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

From jiefu at openjdk.java.net  Thu Jan 27 23:47:10 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 27 Jan 2022 23:47:10 GMT
Subject: RFR: 8280494: (D)TLS signature schemes
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <AOOxg5lE_E4htnwvTStCxi-H838zeQpnvuxAH54N4ro=.9b62974e-c280-441e-b60d-0ca73ce263ae@github.com>

On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 3:

> 1: /*
> 2:  * Copyright (c) 2005, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved.

No sure if we should add this new copyright line for Tencent.

But for hotspot changes, we usually just update the copyright year from 2021 to 2022 if the original copyright is from Oracle.

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

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

From duke at openjdk.java.net  Fri Jan 28 01:19:12 2022
From: duke at openjdk.java.net (Bernd)
Date: Fri, 28 Jan 2022 01:19:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>

On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

I like the per-parameters configuration and we really should get it for more Systeme properties in the future. But I wonder if the additional allocations (some while doing handshakes?) can be avoided by doing more parsing/analysing in the parameter object already. It could even do the analysis of the system property at that time. Also the toggle semantic seems to be a bit different then you would expect, a extra flag to keep track of customized settings would probably fix that and avoid the array compares.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 92:

> 90:     private int maximumPacketSize = 0;
> 91:     private String[] applicationProtocols = new String[0];
> 92:     private String[] signatureSchemes = new String[0];

There are some places in here which could use a local or global static EMPTY = new String[0]` value. That would be safe to share and reduces allocations (they surely escape).

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 745:

> 743:      * This method will make a copy of the {@code signatureSchemes} array.
> 744:      *
> 745:      * @param signatureSchemes an ordered array of signature scheme names,

Should it mention that unknown schemes are ignored and not trigger a exception?

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763:

> 761: 
> 762:         String[] tempSchemes = signatureSchemes.clone();
> 763:         for (String scheme : tempSchemes) {

In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused)

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 66:

> 64:     // The configured signature schemes for "signature_algorithms" and
> 65:     // "signature_algorithms_cert" extensions
> 66:     String[]                   signatureSchemes;

I would keep the typed list (get it from the parameters or system property cache).

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262:

> 260:         }   // otherwise, use the default values
> 261: 
> 262:         String[] ss = params.getSignatureSchemes();

If we don?t use the cloning getter here (and use the pre-parsed list) it would be more efficient.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 410:

> 408: 
> 409:         // Reset the signature schemes, if it was configured with SSLParameters.
> 410:         if (Arrays.equals(signatureSchemes,

The duals here does not mean it was configure with parameters, it only means it is currently the same configuration as the parameters, but it still could be a different source?

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439:

> 437:                     (config.signatureSchemes == null ||
> 438:                         config.signatureSchemes.length == 0 ||
> 439:                         Arrays.asList(config.signatureSchemes)

Is that a allocation per handshake*availablesize?

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

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

From xuelei at openjdk.java.net  Fri Jan 28 07:21:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 28 Jan 2022 07:21:56 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

  Copyright correction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/c7537b16..822565d5

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

  Stats: 24 lines in 4 files changed: 5 ins; 5 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252

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

From xuelei at openjdk.java.net  Fri Jan 28 07:21:58 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 28 Jan 2022 07:21:58 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <AOOxg5lE_E4htnwvTStCxi-H838zeQpnvuxAH54N4ro=.9b62974e-c280-441e-b60d-0ca73ce263ae@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <AOOxg5lE_E4htnwvTStCxi-H838zeQpnvuxAH54N4ro=.9b62974e-c280-441e-b60d-0ca73ce263ae@github.com>
Message-ID: <E-RJah4Z99ybRkkgoeFZ5q0XdRFiCGU3nrSHnRV8ruM=.ed29e8de-3c0a-42c5-9814-fc2904321135@github.com>

On Thu, 27 Jan 2022 23:43:51 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2005, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved.
> 
> No sure if we should add this new copyright line for Tencent.
> 
> But for hotspot changes, we usually just update the copyright year from 2021 to 2022 if the original copyright is from Oracle.

Thank you for catching this.  Updated.

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

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

From bulasevich at openjdk.java.net  Fri Jan 28 07:48:11 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Fri, 28 Jan 2022 07:48:11 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <XJriglqtgdNDLkfwuINdW96rYWQf1LkP7_DiTrhTB-g=.c16b7d5a-42b8-4885-bf3c-0083da09d06e@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Hi,

Thanks for looking at this!

> Have you run the tests to make sure it passes the Known Answer Tests?

In my original post I included the test suite and KAT - I have not found ready-to use one, so I did it from scratch using the test vectors provided for KECCAK Final Algorithm Package.

> Can you also include the before and after JMH benchmarks for SHA3 in the PR? they are under test/micro/org/openjdk/bench/java/security/MessageDigests

There are before/after MessageDigests benchmark results for option1/options2 on ARM32/PPC/ARM64/AMD: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html - is it OK?

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

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

From kevinw at openjdk.java.net  Fri Jan 28 11:41:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 28 Jan 2022 11:41:49 GMT
Subject: RFR: 8272317: jstatd has dependency on Security Manager which
 needs to be removed [v4]
In-Reply-To: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
Message-ID: <XpoV8KpNx9AoIC__z5QpSY5Ury4v5MBL4hslA7e10fw=.9170f0e3-cb6b-47b9-9d94-2df428cc4102@github.com>

> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
> 
> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
> ..as that is no longer needed.
> 
> Docs/man page update to follow (JDK-8278619).

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

 - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr
 - Copyright update
 - Wildcard in object filter to permit proxies, in case other activity in this JVM changes the nameing/numbering of proxy classes.
 - Remove jstad launcher property setting to allow Security Manager.
 - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr
 - Add ObjectInputFilter
 - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr
 - 8272317: jstatd has dependency on Security Manager which needs to be removed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6919/files
  - new: https://git.openjdk.java.net/jdk/pull/6919/files/443b18b4..e6f016a8

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

  Stats: 34764 lines in 1297 files changed: 23346 ins; 6357 del; 5061 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6919.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6919/head:pull/6919

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

From kevinw at openjdk.java.net  Fri Jan 28 12:59:16 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 28 Jan 2022 12:59:16 GMT
Subject: Integrated: 8272317: jstatd has dependency on Security Manager which
 needs to be removed
In-Reply-To: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
References: <aA0YN4W1HA8HZu6CLMp7igVfwid4bYSVYAMPrxe5BUM=.87232d4e-2f84-4b1c-8adf-334644048f94@github.com>
Message-ID: <63PFp2A_4BIAq1uxTyJHWTLMO8Y0eQw-ZAuGomIwQnY=.282b7947-846e-4e95-8eb3-ed60c28966dd@github.com>

On Wed, 22 Dec 2021 18:14:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
> 
> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
> ..as that is no longer needed.
> 
> Docs/man page update to follow (JDK-8278619).

This pull request has now been integrated.

Changeset: cb8a82ee
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb8a82ee24881113af4eea04d7ce5963d18e9b83
Stats:     29 lines in 4 files changed: 4 ins; 15 del; 10 mod

8272317: jstatd has dependency on Security Manager which needs to be removed

Reviewed-by: cjplummer, rriggs

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

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

From mullan at openjdk.java.net  Fri Jan 28 15:34:15 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 28 Jan 2022 15:34:15 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
Message-ID: <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>

On Fri, 28 Jan 2022 07:21:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright correction

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 94:

> 92: 
> 93:     /**
> 94:      * Constructs SSLParameters.

Would it be useful to add another ctor that takes a signature schemes array parameter?

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 709:

> 707:      * "{@docRoot}/../specs/security/standard-names.html#signature-schemes">
> 708:      * Signature Schemes</a> section of the Java Cryptography
> 709:      * Architecture Standard Algorithm Name Documentation, and may also

The correct name is "Java Security Standard Algorithm Names Specification". Same comment below for `setSignatureSchemes`.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710:

> 708:      * Signature Schemes</a> section of the Java Cryptography
> 709:      * Architecture Standard Algorithm Name Documentation, and may also
> 710:      * include other signature schemes that the provider supports.

There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name.
I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names). 

It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 746:

> 744:      * @param signatureSchemes an ordered array of signature scheme names,
> 745:      *        with the first entry being the most preferred. If the array
> 746:      *        is empty (zero-length), the prodiver-specific default signature

typo: prodiver -> provider

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

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

From mullan at openjdk.java.net  Fri Jan 28 15:48:12 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 28 Jan 2022 15:48:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
Message-ID: <vmNt-XjlXqQzliGdrL-BpjANyVX0ZD1XoeCYXKN31n8=.7fbc02ed-1fbc-4287-9ab8-13cfed95b583@github.com>

On Fri, 28 Jan 2022 15:17:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710:
> 
>> 708:      * Signature Schemes</a> section of the Java Cryptography
>> 709:      * Architecture Standard Algorithm Name Documentation, and may also
>> 710:      * include other signature schemes that the provider supports.
> 
> There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name.
> I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names). 
> 
> It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list.

You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider?

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

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

From jnimeh at openjdk.java.net  Fri Jan 28 15:54:15 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 28 Jan 2022 15:54:15 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <vmNt-XjlXqQzliGdrL-BpjANyVX0ZD1XoeCYXKN31n8=.7fbc02ed-1fbc-4287-9ab8-13cfed95b583@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
 <vmNt-XjlXqQzliGdrL-BpjANyVX0ZD1XoeCYXKN31n8=.7fbc02ed-1fbc-4287-9ab8-13cfed95b583@github.com>
Message-ID: <Mc8RArc1WheLf2qbO8Fxx51rt6Yz428-m3jHpzlk0E0=.9b3525cf-0bb4-43a7-a51c-526b259148a1@github.com>

On Fri, 28 Jan 2022 15:44:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710:
>> 
>>> 708:      * Signature Schemes</a> section of the Java Cryptography
>>> 709:      * Architecture Standard Algorithm Name Documentation, and may also
>>> 710:      * include other signature schemes that the provider supports.
>> 
>> There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name.
>> I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names). 
>> 
>> It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list.
>
> You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider?

I asked a similar question about the System property interaction in the CSR and he has some answers there.

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

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

From duke at openjdk.java.net  Fri Jan 28 16:46:15 2022
From: duke at openjdk.java.net (Sebastian Stenzel)
Date: Fri, 28 Jan 2022 16:46:15 GMT
Subject: Integrated: JDK-8280703 CipherCore.doFinal(...) causes potentially
 massive byte[] allocations during decryption
In-Reply-To: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
References: <UXnROwNevwWsqR9vtCZtQ__cPP28PIUEt9xE-IpHwi8=.79c92553-0c34-497e-baf7-80ad97ddd937@github.com>
Message-ID: <1c3na5W_CTHxxJTycjBAV8IOy9dVdC6j0LEjSx2erOA=.82b0bf06-f44c-4b75-ac81-79ea72a9eccb@github.com>

On Wed, 26 Jan 2022 10:07:01 GMT, Sebastian Stenzel <duke at openjdk.java.net> wrote:

> Related to #411, however it turns out that for unpadded ciphers, there is no need to allocate `internalOutput`, if `output` provides sufficient capacity.
> 
> For padded ciphers, only the unpadded cleartext is expected to be copied to the output buffer. In this case, there is no way around the temporary buffer (without major changes).
> 
> While a small change, please review with care, as I might be missing some security-relevant side effect (such as: don't copy cleartext to output buffer before validating the a tag - just as an example, even if there is no authentication involved in this method).
> 
> I have some test failures in Tier 1 tests, but these seem to be unrelated. Tests for `com.sun.crypto` and `javax.crypto` run fine:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/com/sun/crypto                       141   141     0     0   
>    jtreg:test/jdk/javax/crypto                          56    56     0     0   
> ==============================
> TEST SUCCESS

This pull request has now been integrated.

Changeset: 409382ba
Author:    Sebastian Stenzel <sebastian.stenzel at skymatic.de>
Committer: Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/409382ba4b43bf48ed0086020dd20641effd35b6
Stats:     8 lines in 1 file changed: 3 ins; 0 del; 5 mod

8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption

Reviewed-by: ascarpino

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

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

From michaelm at openjdk.java.net  Fri Jan 28 16:58:55 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 28 Jan 2022 16:58:55 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v13]
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com>

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

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

  spec update from CSR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7065/files
  - new: https://git.openjdk.java.net/jdk/pull/7065/files/59f703da..468e5345

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=11-12

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

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

From dfuchs at openjdk.java.net  Fri Jan 28 17:24:22 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 28 Jan 2022 17:24:22 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v13]
In-Reply-To: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com>
Message-ID: <EpPaSGSGmhttGtwOmIhjC7_jR9pXFhuho4xV3r6Lq9Y=.c231c6be-1393-47b8-a4aa-62dace1e0caa@github.com>

On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spec update from CSR

Marked as reviewed by dfuchs (Reviewer).

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

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

From xuelei at openjdk.java.net  Fri Jan 28 18:33:11 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 28 Jan 2022 18:33:11 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
Message-ID: <q6-qWJWTBvOfWrmVvRkfLkm059Jh-HwVn0KRZnKZA0U=.c6023bb3-62eb-49e5-83a1-73902df66693@github.com>

On Fri, 28 Jan 2022 15:17:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 709:
> 
>> 707:      * "{@docRoot}/../specs/security/standard-names.html#signature-schemes">
>> 708:      * Signature Schemes</a> section of the Java Cryptography
>> 709:      * Architecture Standard Algorithm Name Documentation, and may also
> 
> The correct name is "Java Security Standard Algorithm Names Specification". Same comment below for `setSignatureSchemes`.

Good catch!

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

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

From xuelei at openjdk.java.net  Fri Jan 28 19:53:13 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 28 Jan 2022 19:53:13 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <Mc8RArc1WheLf2qbO8Fxx51rt6Yz428-m3jHpzlk0E0=.9b3525cf-0bb4-43a7-a51c-526b259148a1@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
 <vmNt-XjlXqQzliGdrL-BpjANyVX0ZD1XoeCYXKN31n8=.7fbc02ed-1fbc-4287-9ab8-13cfed95b583@github.com>
 <Mc8RArc1WheLf2qbO8Fxx51rt6Yz428-m3jHpzlk0E0=.9b3525cf-0bb4-43a7-a51c-526b259148a1@github.com>
Message-ID: <mHa7NudWcDi-nGp0O90eCaiQb3O0yukpXWgFvf8Wetk=.8adffb49-ad71-477a-be85-f025a8b3f27f@github.com>

On Fri, 28 Jan 2022 15:50:49 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider?
>
> I asked a similar question about the System property interaction in the CSR and he has some answers there.

All good catches, Sean and Jamil.  I updated the CSR accordingly, and will update the PR after I complete other comments.

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

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

From xuelei at openjdk.java.net  Sat Jan 29 05:30:11 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 29 Jan 2022 05:30:11 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
Message-ID: <bhMVgkPJuMVBGz_uRtFIqqcrG5Qwoh-JdPnWfcR_YIU=.fee4d37e-e4ae-4a86-afe6-a1df0b2b6142@github.com>

On Fri, 28 Jan 2022 00:54:53 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 92:
> 
>> 90:     private int maximumPacketSize = 0;
>> 91:     private String[] applicationProtocols = new String[0];
>> 92:     private String[] signatureSchemes = new String[0];
> 
> There are some places in here which could use a local or global static EMPTY = new String[0]` value. That would be safe to share and reduces allocations (they surely escape).

Good point.  I will make the update.

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 745:
> 
>> 743:      * This method will make a copy of the {@code signatureSchemes} array.
>> 744:      *
>> 745:      * @param signatureSchemes an ordered array of signature scheme names,
> 
> Should it mention that unknown schemes are ignored and not trigger a exception?

Good catch!  I missed that.

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

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

From xuelei at openjdk.java.net  Sat Jan 29 05:30:11 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 29 Jan 2022 05:30:11 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
Message-ID: <Xuzs8p6keG9rol3ad_Eh6JQcZV5Hu5yV9u70xJ8HD4o=.aaf3d417-54f2-45df-804c-ca1418e0a109@github.com>

On Fri, 28 Jan 2022 15:26:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 94:
> 
>> 92: 
>> 93:     /**
>> 94:      * Constructs SSLParameters.
> 
> Would it be useful to add another ctor that takes a signature schemes array parameter?

As there is increasing number of SSL parameters, applications may just use the constructor with no argument, and use the set methods individually.

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

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

From xuelei at openjdk.java.net  Sat Jan 29 05:38:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 29 Jan 2022 05:38:10 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
Message-ID: <tAvvkqGBkKQ8xaYLlget71uxScRKDgMJXGi_QwEk7V8=.2b960a31-4c3b-41bd-90d6-b3f78891dd92@github.com>

On Fri, 28 Jan 2022 00:58:37 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763:
> 
>> 761: 
>> 762:         String[] tempSchemes = signatureSchemes.clone();
>> 763:         for (String scheme : tempSchemes) {
> 
> In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused)

If we want to reuse the result, we may have to cache something.  It is not good to me.  The parsing of the signature scheme names actually depends on the provider.  So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me.

> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 66:
> 
>> 64:     // The configured signature schemes for "signature_algorithms" and
>> 65:     // "signature_algorithms_cert" extensions
>> 66:     String[]                   signatureSchemes;
> 
> I would keep the typed list (get it from the parameters or system property cache).

I see your point.  There is a tricky question that it would be nice to return (SSLParameters.getXXX()) to what it has been set (SSLParameters.setXXX()).  If the typed list get kept, it means that unknown names would filtered out, and the get method cannot return the property values.

> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262:
> 
>> 260:         }   // otherwise, use the default values
>> 261: 
>> 262:         String[] ss = params.getSignatureSchemes();
> 
> If we don?t use the cloning getter here (and use the pre-parsed list) it would be more efficient.

Yes.  Array copy is a concern of mine, too.  Hopefully, the frozen array feature could help address the array copy issues in the future.

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

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

From xuelei at openjdk.java.net  Sat Jan 29 05:51:04 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 29 Jan 2022 05:51:04 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v3]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <Kt9yUEWtSBgNoKdH19cb7w_5l8GCL_3-Fv6duZeq7AA=.2d887fb8-1622-453e-a120-036b5c11921b@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

  Enrich the APIs specification

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/822565d5..53d4db9e

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

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

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

From xuelei at openjdk.java.net  Sat Jan 29 05:51:04 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 29 Jan 2022 05:51:04 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v3]
In-Reply-To: <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
Message-ID: <ALM8sOgMaXQoPxXXEyRqQRU0fkoVw0BtMntpIrItZ3w=.cded0d05-1a15-441d-9414-61d42f08ee3d@github.com>

On Fri, 28 Jan 2022 01:05:22 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Enrich the APIs specification
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 410:
> 
>> 408: 
>> 409:         // Reset the signature schemes, if it was configured with SSLParameters.
>> 410:         if (Arrays.equals(signatureSchemes,
> 
> The duals here does not mean it was configure with parameters, it only means it is currently the same configuration as the parameters, but it still could be a different source?

You are right.  Toggle client mode is a pretty hard to implement method to me, especially considering the impact of various SSL parameters.  There are more than one method to set the parameters, as make it hard to know what an application really want to do.  Here is a best effort I can think of, but not really an accurate implementation.  Hopefully, the impact is minimal.

> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439:
> 
>> 437:                     (config.signatureSchemes == null ||
>> 438:                         config.signatureSchemes.length == 0 ||
>> 439:                         Arrays.asList(config.signatureSchemes)
> 
> Is that a allocation per handshake*availablesize?

Yes, it does.  Do you like to use a for-loop, without new object allocation?

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

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

From ascarpino at openjdk.java.net  Sat Jan 29 16:50:05 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Sat, 29 Jan 2022 16:50:05 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <B66jQyqEP3a1JrXRTYLOjhljK-2huqqDyn1WrZFVHrU=.c862a599-cfc2-4564-b350-67d7bc03cd91@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Ah yes.  Sorry, I saw the replied email that left that out

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

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

From xuelei at openjdk.java.net  Sat Jan 29 18:56:57 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 29 Jan 2022 18:56:57 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v4]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <wgyvgRxXI5ayVRyzBO69U7BgLssVPPRzk6FwnZe0D_E=.e8fef382-ed7c-44ec-bad5-a6d0961072b4@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

  Checke blank strings

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/53d4db9e..0000922f

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

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

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

From duke at openjdk.java.net  Sun Jan 30 03:11:12 2022
From: duke at openjdk.java.net (Bernd)
Date: Sun, 30 Jan 2022 03:11:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v4]
In-Reply-To: <tAvvkqGBkKQ8xaYLlget71uxScRKDgMJXGi_QwEk7V8=.2b960a31-4c3b-41bd-90d6-b3f78891dd92@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
 <tAvvkqGBkKQ8xaYLlget71uxScRKDgMJXGi_QwEk7V8=.2b960a31-4c3b-41bd-90d6-b3f78891dd92@github.com>
Message-ID: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>

On Sat, 29 Jan 2022 05:31:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763:
>> 
>>> 761: 
>>> 762:         String[] tempSchemes = signatureSchemes.clone();
>>> 763:         for (String scheme : tempSchemes) {
>> 
>> In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused)
>
> If we want to reuse the result, we may have to cache something.  It is not good to me.  The parsing of the signature scheme names actually depends on the provider.  So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me.

Yes you are right, it would require a setter where the provider can register the resolved array into the parameter instance (if we need to support multiple providers). But it would be a good optimization assuming clients keep the parameters around in a frequent Connection scenario.

>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262:
>> 
>>> 260:         }   // otherwise, use the default values
>>> 261: 
>>> 262:         String[] ss = params.getSignatureSchemes();
>> 
>> If we don?t use the cloning getter here (and use the pre-parsed list) it would be more efficient.
>
> Yes.  Array copy is a concern of mine, too.  Hopefully, the frozen array feature could help address the array copy issues in the future.

Hmm.. I guess the different packages make it really hard to have an internal optimized getter. What about a single concatenated string, it would be immutable ?sig1,sig2?..

>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439:
>> 
>>> 437:                     (config.signatureSchemes == null ||
>>> 438:                         config.signatureSchemes.length == 0 ||
>>> 439:                         Arrays.asList(config.signatureSchemes)
>> 
>> Is that a allocation per handshake*availablesize?
>
> Yes, it does.  Do you like to use a for-loop, without new object allocation?

Yes, static helper

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

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

From xuelei at openjdk.java.net  Sun Jan 30 07:33:52 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 30 Jan 2022 07:33:52 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v5]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <VJZkMAJ7q03nwxc5aE5RN_bqvPj7r1P-wQFAtbe2lDs=.cccc296d-62a9-4ce4-9199-8cb67d9f6591@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

  Less objects construction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/0000922f..b8ed2506

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

  Stats: 13 lines in 2 files changed: 10 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252

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

From xuelei at openjdk.java.net  Sun Jan 30 07:39:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 30 Jan 2022 07:39:10 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v5]
In-Reply-To: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
 <tAvvkqGBkKQ8xaYLlget71uxScRKDgMJXGi_QwEk7V8=.2b960a31-4c3b-41bd-90d6-b3f78891dd92@github.com>
 <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>
Message-ID: <zOY9WSYQOl9TD3quhA654oMz2yrTjwtfKmlgToj_XPs=.4db9eb0d-7e1d-4e49-942c-aa7c27867acc@github.com>

On Sun, 30 Jan 2022 03:03:37 GMT, Bernd <duke at openjdk.java.net> wrote:

>> If we want to reuse the result, we may have to cache something.  It is not good to me.  The parsing of the signature scheme names actually depends on the provider.  So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me.
>
> Yes you are right, it would require a setter where the provider can register the resolved array into the parameter instance (if we need to support multiple providers). But it would be a good optimization assuming clients keep the parameters around in a frequent Connection scenario.

I see your point.  The API default implementation could be complicated, if considering loading and unloading providers at runtime.  I agree with you about the potential performance impact (minimal, but we may want to optimizing), and let's see if we could have a solution later.  Since it is a common issue, I will not address it in this PR.

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

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

From xuelei at openjdk.java.net  Sun Jan 30 07:43:07 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 30 Jan 2022 07:43:07 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v5]
In-Reply-To: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
 <tAvvkqGBkKQ8xaYLlget71uxScRKDgMJXGi_QwEk7V8=.2b960a31-4c3b-41bd-90d6-b3f78891dd92@github.com>
 <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>
Message-ID: <-FIxZLPhl80oVo0PC6X2XenAvYPxbWwUPMo4oNCVrp4=.756b3461-6258-4ca5-bad1-31d9f000ddf2@github.com>

On Sun, 30 Jan 2022 03:06:35 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Yes.  Array copy is a concern of mine, too.  Hopefully, the frozen array feature could help address the array copy issues in the future.
>
> Hmm.. I guess the different packages make it really hard to have an internal optimized getter. What about a single concatenated string, it would be immutable ?sig1,sig2?..

It's an interesting idea.  I would like to choose simple API, in an affordable performance impact.  I don't worry a lot if considering the frozen array enhancement.

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

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

From xuelei at openjdk.java.net  Mon Jan 31 15:19:01 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 15:19:01 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v6]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <oifvP7FCsSOi-L__Ts-xoUOFf9PmzV0hUxjqH1Q0fUM=.2d78dfb9-b2a4-4b2e-85df-db72e8e9a48f@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

  typo correction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/b8ed2506..0d3c52dd

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

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

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

From xuelei at openjdk.java.net  Mon Jan 31 15:19:02 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 15:19:02 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v6]
In-Reply-To: <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <PGjfGd23O3XMwBvCWlEs8NZz03z_PETL7Gpim5VUNc0=.af0bb035-2170-4ac7-963f-aa34024c0948@github.com>
 <tAvvkqGBkKQ8xaYLlget71uxScRKDgMJXGi_QwEk7V8=.2b960a31-4c3b-41bd-90d6-b3f78891dd92@github.com>
 <5VIdUq8Ub0mZsS6V2Qz_BoFCD_U0xt5PlWfMC-7Z4vM=.73e49b71-e14f-49c9-a8d4-12bd1f0b2698@github.com>
Message-ID: <nM9semvHCRsK9cZE1L9Y3ugON7MyAQ9MSBu5_4xTfrI=.70b47dde-6f0d-405e-896c-2bcc4919e13e@github.com>

On Sun, 30 Jan 2022 03:08:22 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Yes, it does.  Do you like to use a for-loop, without new object allocation?
>
> Yes, static helper

Thanks for confirm.  Updated to use a static helper method.

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

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

From xuelei at openjdk.java.net  Mon Jan 31 15:43:43 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 15:43:43 GMT
Subject: RFR: 8280949: Correct the references for the Java Security Standard
 Algorithm Names specification
Message-ID: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>

In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation".  As should be corrected.

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

Commit messages:
 - 8280949: Correct the references for the Java Security Standard Algorithm Names specification

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

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

From xuelei at openjdk.java.net  Mon Jan 31 16:01:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 16:01:56 GMT
Subject: RFR: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification [v2]
In-Reply-To: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
Message-ID: <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com>

> In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation".  As should be corrected.

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

  Update the copyright  years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7290/files
  - new: https://git.openjdk.java.net/jdk/pull/7290/files/96b3e528..9f75163b

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

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

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

From mullan at openjdk.java.net  Mon Jan 31 16:43:17 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 31 Jan 2022 16:43:17 GMT
Subject: RFR: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification [v2]
In-Reply-To: <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
 <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com>
Message-ID: <hwrCc0rGEQjpK-MjbZRDbbUeV6H800auCm_A2uxeleM=.2930160c-2404-4940-a200-4b041ad68495@github.com>

On Mon, 31 Jan 2022 16:01:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation".  As should be corrected.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the copyright  years

Please capitalize "specification"  (i.e. "Specification")  to be consistent with other references in the javadoc. Looks good otherwise.

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

Marked as reviewed by mullan (Reviewer).

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

From aturbanov at openjdk.java.net  Mon Jan 31 18:33:28 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 31 Jan 2022 18:33:28 GMT
Subject: RFR: 8280970: Cleanup dead code in java.security.Provider
Message-ID: <G0Hx4RPo_c8gmFz7mlfEhEHRg-6s2SbEvcnEy_VME4Y=.205f4a50-9922-4629-8a7c-43182d56d8bb@github.com>

Method `Provider.getKey` was added in [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660). It was unused since introduction.
Method `EngineDescription.getConstructorParameterClass()` and field `EngineDescription.constructorParameterClass` is unused since [JDK-7191662](https://bugs.openjdk.java.net/browse/JDK-7191662)

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

Commit messages:
 - [PATCH] Cleanup dead code in java.security.Provider

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

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

From xuelei at openjdk.java.net  Mon Jan 31 19:23:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 19:23:56 GMT
Subject: RFR: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification [v3]
In-Reply-To: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
Message-ID: <7KfgId9VMKq7zDfm96IDwGBWVpgTZe__qBXvvBx9Ffw=.731771c0-2ec4-4654-a931-4ca4f25724fd@github.com>

> In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation".  As should be corrected.

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

  Use capital S

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7290/files
  - new: https://git.openjdk.java.net/jdk/pull/7290/files/9f75163b..d5792cee

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

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

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

From xuelei at openjdk.java.net  Mon Jan 31 19:23:57 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 19:23:57 GMT
Subject: RFR: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification [v2]
In-Reply-To: <hwrCc0rGEQjpK-MjbZRDbbUeV6H800auCm_A2uxeleM=.2930160c-2404-4940-a200-4b041ad68495@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
 <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com>
 <hwrCc0rGEQjpK-MjbZRDbbUeV6H800auCm_A2uxeleM=.2930160c-2404-4940-a200-4b041ad68495@github.com>
Message-ID: <IX2ScSfUT23BfxLlUptQtX3W-QK1BItYjQwEm2Jh4LU=.a6f98b0c-a8e0-43e7-a05a-827515f5c858@github.com>

On Mon, 31 Jan 2022 16:39:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise.

OK.  Just curious, why we want to use capitalized "specification"?  This word "specification" is not a part of the document title.

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

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

From mullan at openjdk.java.net  Mon Jan 31 20:09:09 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 31 Jan 2022 20:09:09 GMT
Subject: RFR: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification [v2]
In-Reply-To: <IX2ScSfUT23BfxLlUptQtX3W-QK1BItYjQwEm2Jh4LU=.a6f98b0c-a8e0-43e7-a05a-827515f5c858@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
 <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com>
 <hwrCc0rGEQjpK-MjbZRDbbUeV6H800auCm_A2uxeleM=.2930160c-2404-4940-a200-4b041ad68495@github.com>
 <IX2ScSfUT23BfxLlUptQtX3W-QK1BItYjQwEm2Jh4LU=.a6f98b0c-a8e0-43e7-a05a-827515f5c858@github.com>
Message-ID: <Jrf4KIIPjUkPhYMQMIMDC8507XABDVXHl0lPwyJwj98=.69b4e086-fd21-4ad0-adb9-d36e5e2bb6b0@github.com>

On Mon, 31 Jan 2022 19:19:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise.
> 
> OK. Just curious, why we want to use capitalized "specification"? This word "specification" is not a part of the document title.

True (although in hindsight we could have added it to the title). However, I think capitalizing when referencing it signifies that it is an important and normative document, similar to when you refer to standard documents even if it is not in title (ex: "The AES Standard"). If we referred to it again in subsequent text, then it is not as necessary, i.e. you could say "This specification includes list of names that are defined as standard ...

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

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

From xuelei at openjdk.java.net  Mon Jan 31 20:20:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 20:20:10 GMT
Subject: RFR: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification [v2]
In-Reply-To: <Jrf4KIIPjUkPhYMQMIMDC8507XABDVXHl0lPwyJwj98=.69b4e086-fd21-4ad0-adb9-d36e5e2bb6b0@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
 <4a-0RKTLUuxVyD-itK3CJR7a2WoB2otGcPSsQLVwEPU=.8c5dccd9-ee87-476b-9088-f5c0e4882849@github.com>
 <hwrCc0rGEQjpK-MjbZRDbbUeV6H800auCm_A2uxeleM=.2930160c-2404-4940-a200-4b041ad68495@github.com>
 <IX2ScSfUT23BfxLlUptQtX3W-QK1BItYjQwEm2Jh4LU=.a6f98b0c-a8e0-43e7-a05a-827515f5c858@github.com>
 <Jrf4KIIPjUkPhYMQMIMDC8507XABDVXHl0lPwyJwj98=.69b4e086-fd21-4ad0-adb9-d36e5e2bb6b0@github.com>
Message-ID: <pJBeurueS5Tsa1iFP4pfHvnRjxrhl0O9-OxV9T1KJJs=.7c139b66-3a50-43e6-a949-b5bab4381618@github.com>

On Mon, 31 Jan 2022 20:05:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Please capitalize "specification" (i.e. "Specification") to be consistent with other references in the javadoc. Looks good otherwise.
> > 
> > 
> > OK. Just curious, why we want to use capitalized "specification"? This word "specification" is not a part of the document title.
> 
> True (although in hindsight we could have added it to the title). However, I think capitalizing when referencing it signifies that it is an important and normative document, similar to when you refer to standard documents even if it is not in title (ex: "The AES Standard"). If we referred to it again in subsequent text, then it is not as necessary, i.e. you could say "This specification includes list of names that are defined as standard ...

Good point!  Thank you!

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

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

From xuelei at openjdk.java.net  Mon Jan 31 20:24:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 20:24:47 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v7]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <DcOEfb1M7AcRaOEWlri_5APSAtNrddKcprzwGQSJPTk=.693c6fc2-3ca4-4f48-9222-bea370854996@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

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

  Rollback to use captialized S

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/0d3c52dd..dfcb7f7d

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

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

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

From xuelei at openjdk.java.net  Mon Jan 31 20:29:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 31 Jan 2022 20:29:12 GMT
Subject: Integrated: 8280949: Correct the references for the Java Security
 Standard Algorithm Names specification
In-Reply-To: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
References: <-Rsb7Fg7NcCh6cvaRHRgyXm4pMf3hgJoFFu3ZYPM9Qg=.7a426673-6e8e-43fc-ba5c-74f21a371808@github.com>
Message-ID: <Dnc3cld-JZDmRVdlrWaycInWS2ly72rxtU7ocdAGm8Q=.c02e0931-890f-4f64-9181-883e5e68b352@github.com>

On Mon, 31 Jan 2022 15:37:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the JSSE specification, the reference to "Java Security Standard Algorithm Names" specification is documented as "Java Cryptography Architecture Standard Algorithm Name Documentation".  As should be corrected.

This pull request has now been integrated.

Changeset: f991891b
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f991891b0ba7a3767d2abd85ab9b2d284dc3d013
Stats:     61 lines in 6 files changed: 0 ins; 0 del; 61 mod

8280949: Correct the references for the Java Security Standard Algorithm Names specification

Reviewed-by: mullan

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

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

From ascarpino at openjdk.java.net  Mon Jan 31 21:44:09 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 31 Jan 2022 21:44:09 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <A9PQSndZKjfqxdmHTRI6mYXwRI7goKlGoTGJKjiibM4=.c8413a36-ffaf-47f6-88bd-ea4aecd8c5dc@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Please update the copyright date from 2020 to 2022.
I'll run regression tests to make sure things are ok.

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

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

From mullan at openjdk.java.net  Mon Jan 31 22:06:12 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 31 Jan 2022 22:06:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v7]
In-Reply-To: <DcOEfb1M7AcRaOEWlri_5APSAtNrddKcprzwGQSJPTk=.693c6fc2-3ca4-4f48-9222-bea370854996@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <DcOEfb1M7AcRaOEWlri_5APSAtNrddKcprzwGQSJPTk=.693c6fc2-3ca4-4f48-9222-bea370854996@github.com>
Message-ID: <PjhIBZfJetbTaC9Fw2czpxVv6jr6kHxJphsLGUSWio0=.f7bcd1a0-dff4-447e-92e9-d7d663e1d71c@github.com>

On Mon, 31 Jan 2022 20:24:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback to use captialized S

A few more comments on the API.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 727:

> 725:      * Note that the underlying provider may define the default signature
> 726:      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
> 727:      * System Property, "jdk.tls.client.SignatureSchemes" and/or

Use the javadoc annotation @systemProperty when referring to the system properties. Look at other code for examples.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 734:

> 732:      * pre-populated objects.
> 733:      *
> 734:      * @return a non-null, possibly zero-length array of signature scheme

The other methods that return arrays like `getCipherSuites` and `getProtocols` return `null` if none have been set. While one could argue whether returning `null` or an empty array is better, there is already a precedent in this API of returning `null`, and with this API programmers will have to check for two different ways of checking for parameters that are not set. I'm not really sure if the inconsistency is worth it.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 765:

> 763:      * System Property, "jdk.tls.client.SignatureSchemes" and/or
> 764:      * "jdk.tls.server.SignatureSchemes", to customize the provider-specific
> 765:      * default signature schemes. If the {@code signatureSchemes} array is

In this sentence does `signatureSchemes` mean the "*.SignatureSchemes" property or the `signatureSchemes` parameter? I don't think I understand this sentence. I think you should explain when the system property overrides the parameter in this API, and/or vice-versa.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 774:

> 772:      *        is empty (zero-length), the provider-specific default signature
> 773:      *        schemes will be used for the SSL/TLS/DTLS connection.
> 774:      * @throws IllegalArgumentException if signatureSchemes is null, or if

The other methods that accept arrays like `setCipherSuites` and `setProtocols` accept `null` as a parameter. Like my previous comment, it seems more important to keep this behavior consistent in the API and allow `null` as an acceptable value, which is also useful for clearing the current value of the parameter.

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

Changes requested by mullan (Reviewer).

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

From mullan at openjdk.java.net  Mon Jan 31 22:06:13 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 31 Jan 2022 22:06:13 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <Xuzs8p6keG9rol3ad_Eh6JQcZV5Hu5yV9u70xJ8HD4o=.aaf3d417-54f2-45df-804c-ca1418e0a109@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
 <Xuzs8p6keG9rol3ad_Eh6JQcZV5Hu5yV9u70xJ8HD4o=.aaf3d417-54f2-45df-804c-ca1418e0a109@github.com>
Message-ID: <TRp4gf1XxdtDmwWZJ41H_oZc6Wt8K_KU5U1VRFFXkZI=.80fc1318-d2f6-436b-aa68-88d54b164b63@github.com>

On Sat, 29 Jan 2022 05:26:33 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 94:
>> 
>>> 92: 
>>> 93:     /**
>>> 94:      * Constructs SSLParameters.
>> 
>> Would it be useful to add another ctor that takes a signature schemes array parameter?
>
> As there is increasing number of SSL parameters, applications may just use the constructor with no argument, and use the set methods individually.

Ok. You should specify what the default value of the signature schemes parameter is for this constructor as it does for the other parameters.

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

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

From valeriep at openjdk.java.net  Mon Jan 31 23:16:11 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 31 Jan 2022 23:16:11 GMT
Subject: RFR: 8280970: Cleanup dead code in java.security.Provider
In-Reply-To: <G0Hx4RPo_c8gmFz7mlfEhEHRg-6s2SbEvcnEy_VME4Y=.205f4a50-9922-4629-8a7c-43182d56d8bb@github.com>
References: <G0Hx4RPo_c8gmFz7mlfEhEHRg-6s2SbEvcnEy_VME4Y=.205f4a50-9922-4629-8a7c-43182d56d8bb@github.com>
Message-ID: <rHpv7do98b5XhwZpdHA2ms70JjCklaevMB5hMdLSIzI=.85ce051f-bee3-42fb-bb00-14c7d807b587@github.com>

On Thu, 20 Jan 2022 18:25:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `Provider.getKey` was added in [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660). It was unused since introduction.
> Method `EngineDescription.getConstructorParameterClass()` and field `EngineDescription.constructorParameterClass` is unused since [JDK-7191662](https://bugs.openjdk.java.net/browse/JDK-7191662)

Looks good. Thanks for the clean up.

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

Marked as reviewed by valeriep (Reviewer).

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

From d.h.bowes at lancaster.ac.uk  Sun Jan 23 17:00:39 2022
From: d.h.bowes at lancaster.ac.uk (Bowes, David)
Date: Sun, 23 Jan 2022 17:00:39 -0000
Subject: deprecation of SecurityManager JEP 411
Message-ID: <LNXP265MB0443D4A9AB4338B79BA3DE25F75D9@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>




Unfortunately I have to completely disagree with deprecating the SecurityManager: JEP411


?The Security Manager, then, had ambitions to protect against two kinds of threat: Malicious intent, especially in remote code, and accidental vulnerabilities, especially in local code.

The threat of malicious intent by remote code has receded because the Java Platform no longer supports applets. The Applet API was deprecated in Java 9 in 2017<https://openjdk.java.net/jeps/289>, then deprecated for removal in Java 17 in 2021<https://openjdk.java.net/jeps/398> with the intent to remove it in a future release. The closed-source browser plugin that ran applets was removed from Oracle's JDK 11 in 2018<https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdatev2020may-6548840.pdf#%5B%7B%22num%22%3A34%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C93%2C665%2C0%5D> along with the closed-source Java Web Start technology<https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdatev2020may-6548840.pdf#%5B%7B%22num%22%3A34%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C93%2C504%2C0%5D>. Accordingly, many of the risks that the Security Manager protects against are no longer significant. Furthermore, the Security Manager cannot protect against many risks that now are significant. The Security Manager cannot address 19 of the 25 most dangerous issues identified by industry leaders in 2020<https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html>, so issues such as XML external entity reference (XXE) injection and improper input validation have required direct countermeasures in the Java class libraries. (For example, JAXP can protect against XXE attacks and XML entity expansion<https://docs.oracle.com/en/java/javase/16/security/java-api-xml-processing-jaxp-security-guide.html#GUID-D97A1F1D-8DDF-4D19-A7E5-99099F27346E>, while serialization filtering<https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A> can prevent malicious data from being deserialized before it can do any damage.) The Security Manager is also incapable of preventing malicious behavior based on speculative-execution vulnerabilities<https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/000002.html>.
?

I used the SecurityManger with great success to protect against Log4JShell.

It helped me identify the permissions being requested and then the stack track where certain patterns of permission requests were occurring.  The SecurityManager rules were then added to  prevent the vulnerability.  It is the basic of active research into behaviour based attacks.

None of the techniques you describe above which ?replace? the SecurityManager functionality were sufficient.  I would suggest that the SecurityManager does protect me from singinficant threats.

Davd Bowes




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220123/7e6b5ba7/attachment-0001.htm>