From ascarpino at openjdk.java.net  Fri Oct  1 00:55:27 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 1 Oct 2021 00:55:27 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
Message-ID: <TZyTFhR7vTPkmA0BrUGQKD1T3cQ_gqc_OW1BQJ75ypw=.bad4cafd-3ecc-4f99-bbe8-134451333b6b@github.com>

On Fri, 17 Sep 2021 23:22:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
> 
> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
> 
> The rest are minor code refactoring and updates for the PKCS11 Exception class.
> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
> 
> Thanks,
> Valerie

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java line 30:

> 28:  *     AES/KW/PKCS5Padding, and AES/KWP/NoPadding impls of SunPKCS11 provider.
> 29:  * @library /test/lib ../..
> 30:  * @run main/othervm TestGeneral

General question about all the tests.  They use othervm, did they not work with agentvm?

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java line 74:

> 72:                 }
> 73: 
> 74:                 //System.out.println("enc out.length=" + out.length);

Lelftover debug line?

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

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

From weijun at openjdk.java.net  Fri Oct  1 01:49:35 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 01:49:35 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails
In-Reply-To: <GGsIK9s-37Dyee0-x5XxiIcGg_Gfd0_TDKqWuXMSrrs=.7d5741bb-1cb2-40aa-b97b-53ee1606449e@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <GGsIK9s-37Dyee0-x5XxiIcGg_Gfd0_TDKqWuXMSrrs=.7d5741bb-1cb2-40aa-b97b-53ee1606449e@github.com>
Message-ID: <v3pkYB_WbPwCgrWPsLLS2Ig2U3ubSddnTdRbJ0jdDHA=.4f511d46-ead4-4fbc-a7f0-9893f4bc9ebe@github.com>

On Thu, 30 Sep 2021 23:15:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> As throwing ProviderException is removed from initVerifyWithParam(), could we remove the ProviderException in the try-catch block from the callers of initVerifyWithParam()? For example, one of the callers at:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/pkcs/SignerInfo.java#L476

`ProviderException` is a `RuntimeException`, so removing it from the method signature does not mean the method will not throw it. Therefore, removing those catch blocks might lead to behavior changes. I'd rather not touch them.

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

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

From weijun at openjdk.java.net  Fri Oct  1 03:32:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 03:32:11 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails [v2]
In-Reply-To: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
Message-ID: <TuKzFtOe6nG5Z0s2jPcoyHTnQs6FdRQNL8tqpHV7LIw=.52439931-46cc-4160-9860-47a7e406a1d7@github.com>

> Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that.
> 
> Some other cleanups:
> 1. When using GET for OCSP, make sure no double slash.
> 2. Several throws clauses are not necessary.
> 
> No regression test. OCSP needs to access an external server.

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

  a test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5778/files
  - new: https://git.openjdk.java.net/jdk/pull/5778/files/12e8f249..ae58fe45

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

  Stats: 62 lines in 4 files changed: 19 ins; 26 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5778.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5778/head:pull/5778

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

From abakhtin at openjdk.java.net  Fri Oct  1 10:41:49 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 1 Oct 2021 10:41:49 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v2]
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: <Icn-51JggKkCmb5Gt4M1Su0U6P1HDTZQbv5k0wW_R28=.27cc32c8-d4b9-4265-aa59-a24efa76dbc3@github.com>

> 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

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

  Reimplemented readLock, added lock in readHandshakeRecord

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5760/files
  - new: https://git.openjdk.java.net/jdk/pull/5760/files/d1c2a4fe..065073d1

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

  Stats: 51 lines in 2 files changed: 12 ins; 24 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5760/head:pull/5760

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

From abakhtin at openjdk.java.net  Fri Oct  1 10:52:26 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 1 Oct 2021 10:52:26 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <YuOE_kqJ5Im6tz6ubc9fntSb3RkSz1Ofh6y5JEGYHPs=.92f6a99f-2578-4e6e-9d4d-c2eb5912a20f@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <YuOE_kqJ5Im6tz6ubc9fntSb3RkSz1Ofh6y5JEGYHPs=.92f6a99f-2578-4e6e-9d4d-c2eb5912a20f@github.com>
Message-ID: <jp36sJlTDElVuHbK1dGrFTtI_Jq7bkw2Yjl4NOV_yDU=.09c59796-4726-4457-bf0b-27ae1361e1a5@github.com>

On Thu, 30 Sep 2021 23:04:20 GMT, Clive Verghese <cverghese at openjdk.org> wrote:

> Hi @alexeybakhtin,
> 
> Thank you for the PR.
> 
> I have a question regarding the lock, Would adding a `appInput.readLock.lock()` in `SSLSocketImpl:decode(ByteBuffer)` resolve this issue?

Hi Clive,
Thank you for your review. I think you are right. It can be simplified by using the existing appInput.readLock.
SSLSocketImpl: decode () already protected by appInput.readLock in readApplicationRecord () and waitForClose (), so I've added readLock in the readHandshakeRecord (). These are the only places were decode() is called.

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

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

From weijun at openjdk.java.net  Fri Oct  1 14:43:24 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 14:43:24 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails [v3]
In-Reply-To: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
Message-ID: <JZ_3tdyt_rcAXe_UwDva3pYDBmD39N6k0g3HRtyo7p8=.06b0b96c-b764-4a35-8a5b-7c2c29df901a@github.com>

> Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that.
> 
> Some other cleanups:
> 1. When using GET for OCSP, make sure no double slash.
> 2. Several throws clauses are not necessary.
> 
> No regression test. OCSP needs to access an external server.

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

  verifier should not use automatically derived parameters fails

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5778/files
  - new: https://git.openjdk.java.net/jdk/pull/5778/files/ae58fe45..f6ba88a9

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

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

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

From weijun at openjdk.java.net  Fri Oct  1 14:43:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 14:43:25 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails [v2]
In-Reply-To: <TuKzFtOe6nG5Z0s2jPcoyHTnQs6FdRQNL8tqpHV7LIw=.52439931-46cc-4160-9860-47a7e406a1d7@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <TuKzFtOe6nG5Z0s2jPcoyHTnQs6FdRQNL8tqpHV7LIw=.52439931-46cc-4160-9860-47a7e406a1d7@github.com>
Message-ID: <U_wWBv8W89TS3x0XFnbeH4RJGqTxRrZDYtlRpkWv2hk=.4f8ff4e1-abe4-460f-8179-5e9325a1b660@github.com>

On Fri, 1 Oct 2021 03:32:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that.
>> 
>> Some other cleanups:
>> 1. When using GET for OCSP, make sure no double slash.
>> 2. Several throws clauses are not necessary.
>> 
>> No regression test. OCSP needs to access an external server.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a test

New commit to disallow a verifier `Signature` be created directly from algorithm and key and initialized with a default parameters. For verifiers, params must be provided explicitly (if needed); otherwise, it's an error. Fortunately no code is using this function at the moment.

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

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

From cverghese at openjdk.java.net  Fri Oct  1 15:33:29 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Fri, 1 Oct 2021 15:33:29 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <jp36sJlTDElVuHbK1dGrFTtI_Jq7bkw2Yjl4NOV_yDU=.09c59796-4726-4457-bf0b-27ae1361e1a5@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <YuOE_kqJ5Im6tz6ubc9fntSb3RkSz1Ofh6y5JEGYHPs=.92f6a99f-2578-4e6e-9d4d-c2eb5912a20f@github.com>
 <jp36sJlTDElVuHbK1dGrFTtI_Jq7bkw2Yjl4NOV_yDU=.09c59796-4726-4457-bf0b-27ae1361e1a5@github.com>
Message-ID: <XcRBfpA22mEOvBeJTt5524muLqRwGBQD3D7M5-ZKuEk=.ac5c2b40-3c40-41a0-8e96-b08bb0113991@github.com>

On Fri, 1 Oct 2021 10:49:00 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hi @alexeybakhtin, 
>> 
>> Thank you for the PR. 
>> 
>> I have a question regarding the lock, Would adding a `appInput.readLock.lock()` in `SSLSocketImpl:decode(ByteBuffer)` resolve this issue?
>
>> Hi @alexeybakhtin,
>> 
>> Thank you for the PR.
>> 
>> I have a question regarding the lock, Would adding a `appInput.readLock.lock()` in `SSLSocketImpl:decode(ByteBuffer)` resolve this issue?
> 
> Hi Clive,
> Thank you for your review. I think you are right. It can be simplified by using the existing appInput.readLock.
> SSLSocketImpl: decode () already protected by appInput.readLock in readApplicationRecord () and waitForClose (), so I've added readLock in the readHandshakeRecord (). These are the only places were decode() is called.

Thank you @alexeybakhtin, 

The change looks good to me, but I am not a reviewer.

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

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

From weijun at openjdk.java.net  Fri Oct  1 17:09:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 17:09:03 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v5]
In-Reply-To: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
Message-ID: <DVAqW0Mvs1nCXmp1hz987XCE-EVX82hdn3xO3-Ct6KI=.5521f36e-af06-4b0d-8881-1fc0fbfc5c04@github.com>

> This code change removes weak etypes from the default list so it's safer to enable one of them. See the corresponding CSR at https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, please review the CSR as well.

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

  backout checksum changes
  
  reverted:

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5654/files
  - new: https://git.openjdk.java.net/jdk/pull/5654/files/173dc441..7371a1b5

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

  Stats: 145 lines in 4 files changed: 51 ins; 59 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5654/head:pull/5654

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

From weijun at openjdk.java.net  Fri Oct  1 17:09:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 17:09:05 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v4]
In-Reply-To: <O357WrPNQ2movbXEwHx5mZE-JciWoJxgLCPHoCAUB2U=.f87a9c70-b503-43e5-b8c3-63db85ff4b35@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <O357WrPNQ2movbXEwHx5mZE-JciWoJxgLCPHoCAUB2U=.f87a9c70-b503-43e5-b8c3-63db85ff4b35@github.com>
Message-ID: <SpX8h7p8qvpl53O_9657FSxg1-w5r8HRDVDqelXQUyA=.9fe46546-b4ff-4920-bea7-d7ea3f5fe7c1@github.com>

On Tue, 28 Sep 2021 14:24:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change removes weak etypes from the default list so it's safer to enable one of them. See the corresponding CSR at https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, please review the CSR as well.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restrict availability

Backout checksum related changes. Will deal with it in another issue.

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

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

From weijun at openjdk.java.net  Fri Oct  1 17:43:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 1 Oct 2021 17:43:50 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf
Message-ID: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>

Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.

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

Commit messages:
 - 8274656: Remove default_checksum and safe_checksum_type from krb5.conf

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

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

From valeriep at openjdk.java.net  Fri Oct  1 18:00:33 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 1 Oct 2021 18:00:33 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
Message-ID: <0RvXkwDXeSVrGZEtMM-eR-m_DtgnM8hzvZb2xQsIyIg=.72f77e3f-9de4-493b-941c-91c8506ba233@github.com>

On Wed, 29 Sep 2021 22:40:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 824:
> 
>> 822:         } else if (e.match(CKR_ENCRYPTED_DATA_INVALID) ||
>> 823:                 e.match(CKR_GENERAL_ERROR)) {
>> 824:             // CKR_GENERAL_ERROR is Solaris-specific workaround
> 
> With Solaris no longer support, this could be removed.  Are you leaving it for backporting?

Yes, thought that it may be useful in case this got backported.

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java line 57:
> 
>> 55:  * doFinal() is called.
>> 56:  *
>> 57:  * @since   18
> 
> Is there only suppose to be one space between `@since` and 18?

Sure, will fix.

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

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

From valeriep at openjdk.java.net  Fri Oct  1 18:07:34 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 1 Oct 2021 18:07:34 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
Message-ID: <GXFvkQ355GWR5yS38Rdg7KnPEDjYowOOP5Zp4jNb9_g=.16cb0af8-db68-4477-b361-325f313a646c@github.com>

On Wed, 29 Sep 2021 23:56:07 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestCipherKeyWrapperTest.java line 65:
> 
>> 63: // com/sun/crypto/provider/Cipher/KeyWrap/TestCipherKeyWrapperTest.java
>> 64: public class TestCipherKeyWrapperTest extends PKCS11Test {
>> 65:     private static final int LINIMITED_KEYSIZE = 128;
> 
> Did you mean this to be LIMITED_KEYSIZE?

Not sure, the tests are adapted from the existing tests under com/sun/crypto/provider/Cipher/KeyWrap/ and I only do minimum edits to make them test against SunPKCS11 provider.

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

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

From valeriep at openjdk.java.net  Fri Oct  1 19:08:28 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 1 Oct 2021 19:08:28 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <TZyTFhR7vTPkmA0BrUGQKD1T3cQ_gqc_OW1BQJ75ypw=.bad4cafd-3ecc-4f99-bbe8-134451333b6b@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <TZyTFhR7vTPkmA0BrUGQKD1T3cQ_gqc_OW1BQJ75ypw=.bad4cafd-3ecc-4f99-bbe8-134451333b6b@github.com>
Message-ID: <hrhnGFhrR3ZuJIU_4Srjf2NHQ6C0RKT7_WZyhkfyENA=.288701a5-313f-455a-9fda-8a049a995c65@github.com>

On Thu, 30 Sep 2021 23:05:44 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java line 74:
> 
>> 72:                 }
>> 73: 
>> 74:                 //System.out.println("enc out.length=" + out.length);
> 
> Lelftover debug line?

Yes, will remove.

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

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

From valeriep at openjdk.java.net  Fri Oct  1 21:37:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 1 Oct 2021 21:37:38 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
Message-ID: <vd2xWdzL-bEcim9KjF2B5HN3661mDzqXB-7tdUob34g=.f360bf41-76e1-4584-a02b-4cb2a51ddab6@github.com>

On Thu, 30 Sep 2021 02:32:33 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java line 129:
> 
>> 127:         if (algoParts[0].startsWith("AES")) {
>> 128:             // need 3 parts
>> 129:             if (algoParts.length != 3) {
> 
> At this point in the code, isn't it already certain to be a valid transform?  The SunPKCS11 entries are limited to the valid transforms.   Additionally do you really want AssertionError?  Not NoSuchAlgorithmException?

Hmm, you are right, no need to check again as there are code in javax.crypto.Cipher class which handles this. I will remove it.

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

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

From hchao at openjdk.java.net  Fri Oct  1 22:13:39 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 1 Oct 2021 22:13:39 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails [v3]
In-Reply-To: <JZ_3tdyt_rcAXe_UwDva3pYDBmD39N6k0g3HRtyo7p8=.06b0b96c-b764-4a35-8a5b-7c2c29df901a@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <JZ_3tdyt_rcAXe_UwDva3pYDBmD39N6k0g3HRtyo7p8=.06b0b96c-b764-4a35-8a5b-7c2c29df901a@github.com>
Message-ID: <d1iIrQIuHGJxW2968R3yc1fJqCt1t4_JZNZkkTOJKh4=.4d52164e-6c7e-4f0a-84de-583cbc587690@github.com>

On Fri, 1 Oct 2021 14:43:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that.
>> 
>> Some other cleanups:
>> 1. When using GET for OCSP, make sure no double slash.
>> 2. Several throws clauses are not necessary.
>> 
>> No regression test. OCSP needs to access an external server.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   verifier should not use automatically derived parameters fails

Looks good.

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

Marked as reviewed by hchao (Committer).

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

From valeriep at openjdk.java.net  Fri Oct  1 22:18:34 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 1 Oct 2021 22:18:34 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@github.com>
Message-ID: <dei7b1a9XH0cNrsRv0UX7OxpAKzpNR-Sp2Vkaci6ZCg=.3ad3d52e-ef09-4f5c-85c7-fa4a31926329@github.com>

On Thu, 30 Sep 2021 19:14:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java line 437:
> 
>> 435:     protected byte[] engineDoFinal(byte[] in, int inOfs, int inLen)
>> 436:             throws IllegalBlockSizeException, BadPaddingException {
>> 437:         int minOutLen = doFinalLength(inLen);
> 
> nit: seems like this could be maxOutLen given it's the length used to allocate out[].  It can't be any larger, otherwise the operations would fail

Sure, I will rename it to maxOutLen

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

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

From valeriep at openjdk.java.net  Fri Oct  1 23:59:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 1 Oct 2021 23:59:38 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <TZyTFhR7vTPkmA0BrUGQKD1T3cQ_gqc_OW1BQJ75ypw=.bad4cafd-3ecc-4f99-bbe8-134451333b6b@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <TZyTFhR7vTPkmA0BrUGQKD1T3cQ_gqc_OW1BQJ75ypw=.bad4cafd-3ecc-4f99-bbe8-134451333b6b@github.com>
Message-ID: <apIRNi9ME3FD8sxzpCECR9o9e0mh2t30K4RepGDC7jw=.4d8f222d-3d25-4df7-a565-346563aea8bd@github.com>

On Fri, 1 Oct 2021 00:51:27 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java line 30:
> 
>> 28:  *     AES/KW/PKCS5Padding, and AES/KWP/NoPadding impls of SunPKCS11 provider.
>> 29:  * @library /test/lib ../..
>> 30:  * @run main/othervm TestGeneral
> 
> General question about all the tests.  They use othervm, did they not work with agentvm?

Hmm, good question. There are system provider manipulation code in PKCS11Test class, i.e. Security.addProvider(), Security.removeProvider() calls as well as setting/getting system properties. I suppose if we can be sure that things are back to a clean state after each test, then should be ok to use agentvm instead of othervm.

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

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

From cverghese at openjdk.java.net  Sat Oct  2 05:53:54 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Sat, 2 Oct 2021 05:53:54 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext initialization.
Message-ID: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>

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

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

Commit messages:
 - 8274308: Improve efficiency for HandshakeContext initialization
 - Benchmark

Changes: https://git.openjdk.java.net/jdk/pull/5793/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5793&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274308
  Stats: 796 lines in 8 files changed: 607 ins; 148 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5793/head:pull/5793

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

From kustos at gmx.net  Sun Oct  3 15:32:05 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Sun, 3 Oct 2021 17:32:05 +0200
Subject: Different way to solve 8241047
Message-ID: <f14c2150-0130-baad-187a-3a08e4397e51@gmx.net>

Hello

First I hope this is the right mailing list. Second, I realize I'm late
to the party and this ship may already have sailed.

We're using a third party library from a vendor that calls
SSLSession.getPeerCertificateChain() [1]. The vendor is unlikely to ship
a JDK 17 compatible version of this library this decade.

I was wondering if any consideration was given to implementing
#getPeerCertificateChain by calling #getPeerCertificates [2] and
implementing javax.security.cert.X509Certificate by delegating to
java.security.cert.X509Certificate [3]. I believe this would preserve
source, binary and behavior compatibility while at the same time freeing
implementations from having to deal with javax.security.cert types or
#getPeerCertificateChain.

The third party library we use does support configuring a custom
SSLSocketFactory and we'll likely go with a custom SSLSocketFactory.

  [1] https://bugs.openjdk.java.net/browse/JDK-8241047
  [2]
https://github.com/marschall/legacy-compatibility-ssl-socket-factory/blob/master/src/main/java/com/github/marschall/legacycompatibilitysslsocketfactory/LegacyCompatibilitySSLSession.java#L86
  [3]
https://github.com/marschall/legacy-compatibility-ssl-socket-factory/blob/master/src/main/java/com/github/marschall/legacycompatibilitysslsocketfactory/CertificateAdapter.java

Cheers
Philippe

From github.com+30433125+djelinski at openjdk.java.net  Mon Oct  4 06:34:20 2021
From: github.com+30433125+djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 4 Oct 2021 06:34:20 GMT
Subject: RFR: 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: <d2JzGjKvTSrlUtqvLNcgUgbkhjQIdP5qyUFujzEocNI=.0e0bcfe7-0eeb-4b67-80a2-a2473a912a5d@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

The results look very impressive. Could you also benchmark SSLEngine? With SSLEngine we could benchmark the improvements on client and server side separately, and OS's socket handling wouldn't influence the results.

I quickly hacked together a SSLEngine benchmark for server-side handshakes [here](https://github.com/djelinski/jdk/blob/2bee5c471b41d60d4248d5d16e868060f0efda19/test/micro/org/openjdk/bench/java/security/SSLEngineStartHandshake.java); note that on the server side I run the following code on every connection;

            SSLEngine serverEngine = context.createSSLEngine();
            serverEngine.setUseClientMode(false);
            serverEngine.setEnabledProtocols(new String[]{"TLSv1.3"});
            serverEngine.setEnabledCipherSuites(new String[]{"TLS_AES_256_GCM_SHA384"});
            serverEngine.beginHandshake();

not sure if that's the best way to initialize SSLEngine. Anyway, in this setup I observed a 16% performance degradation; results without your patch:

Benchmark                                         Mode  Cnt  Score   Error   Units
SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.837 ? 0.006  ops/ms
SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.187 ? 0.006   ms/op

with your patch:

Benchmark                                         Mode  Cnt  Score   Error   Units
SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.702 ? 0.009  ops/ms
SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.416 ? 0.013   ms/op

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

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

From cverghese at openjdk.java.net  Mon Oct  4 06:34:35 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Mon, 4 Oct 2021 06:34:35 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization.
In-Reply-To: <d2JzGjKvTSrlUtqvLNcgUgbkhjQIdP5qyUFujzEocNI=.0e0bcfe7-0eeb-4b67-80a2-a2473a912a5d@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <d2JzGjKvTSrlUtqvLNcgUgbkhjQIdP5qyUFujzEocNI=.0e0bcfe7-0eeb-4b67-80a2-a2473a912a5d@github.com>
Message-ID: <BLlFRkd_Y5fF2KxN5J74qCup0s0AvsPEODG6R6tsP2c=.3738c234-6b41-4a59-a89d-4b81db1654fb@github.com>

On Sun, 3 Oct 2021 18:20:29 GMT, Daniel Jeli?ski <github.com+30433125+djelinski 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
>
> I quickly hacked together a SSLEngine benchmark for server-side handshakes [here](https://github.com/djelinski/jdk/blob/2bee5c471b41d60d4248d5d16e868060f0efda19/test/micro/org/openjdk/bench/java/security/SSLEngineStartHandshake.java); note that on the server side I run the following code on every connection;
> 
>             SSLEngine serverEngine = context.createSSLEngine();
>             serverEngine.setUseClientMode(false);
>             serverEngine.setEnabledProtocols(new String[]{"TLSv1.3"});
>             serverEngine.setEnabledCipherSuites(new String[]{"TLS_AES_256_GCM_SHA384"});
>             serverEngine.beginHandshake();
> 
> not sure if that's the best way to initialize SSLEngine. Anyway, in this setup I observed a 16% performance degradation; results without your patch:
> 
> Benchmark                                         Mode  Cnt  Score   Error   Units
> SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.837 ? 0.006  ops/ms
> SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.187 ? 0.006   ms/op
> 
> with your patch:
> 
> Benchmark                                         Mode  Cnt  Score   Error   Units
> SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.702 ? 0.009  ops/ms
> SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.416 ? 0.013   ms/op

Hi @djelinski 

Thank you for putting this together. I will investigate the results of your benchmarks.

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

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

From github.com+1887540+benefrati at openjdk.java.net  Mon Oct  4 07:08:07 2021
From: github.com+1887540+benefrati at openjdk.java.net (BenEfrati)
Date: Mon, 4 Oct 2021 07:08:07 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key
In-Reply-To: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
Message-ID: <wE-o8gzF2GLUoJr8WFTYNyrCu6WelC00cyVyVME2EQs=.736a784b-398c-4f4a-8847-e1dd0d4c0285@github.com>

On Fri, 23 Jul 2021 10:33:14 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Hello,
> 
> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
> 
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
> If not applied, implementation can try to select signer from other providers
> 
> Regards
> Alexey

Hey,
Same issue using nCipherKM provider

Caused by: com.ncipher.provider.nCSecurityException: The key material is not exportable outside of the HSM
        at com.ncipher.provider.Utils.exportKey(Utils.java:1539)
        at com.ncipher.provider.Utils.getCrtParams(Utils.java:1486)
        at com.ncipher.provider.km.KMRSAPrivateCrtKey.getPrimeP(KMRSAPrivateCrtKey.java:87)
        at sun.security.rsa.RSACore.crtCrypt(RSACore.java:168)
        at sun.security.rsa.RSACore.rsa(RSACore.java:122)
        at sun.security.rsa.RSAPSSSignature.engineSign(RSAPSSSignature.java:371)
        at java.security.Signature.engineSign(Signature.java:1382)
        at java.security.Signature.sign(Signature.java:698)
        at sun.security.ssl.CertificateVerify.<init>(CertificateVerify.java:608)
        at sun.security.ssl.CertificateVerify.produce(CertificateVerify.java:760)
        at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:421)
        at sun.security.ssl.ServerHelloDone.consume(ServerHelloDone.java:182)
        at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377)
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
        at sun.security.ssl.TransportContext.dispatch(TransportContext.java:182)
        at sun.security.ssl.SSLTransport.decode(SSLTransport.java:149)
        at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1143)
        at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1054)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:394)
        


Is this fix is planned for OpenJDK 8u312?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Oct  4 07:39:17 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 4 Oct 2021 07:39:17 GMT
Subject: RFR: 8274679: Remove unnecessary conversion to String in security
 code in java.base
Message-ID: <6dwlq8Qcojm7hEvmWW1AHyd-Ucs40xbvNZnW70uFnh0=.49999deb-c869-4da1-9904-f1e4ddd5b6e9@github.com>

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

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

Commit messages:
 - [PATCH] Remove unnecessary conversion to String in security code in java.base

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

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

From abakhtin at openjdk.java.net  Mon Oct  4 08:07:11 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 4 Oct 2021 08:07:11 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key
In-Reply-To: <wE-o8gzF2GLUoJr8WFTYNyrCu6WelC00cyVyVME2EQs=.736a784b-398c-4f4a-8847-e1dd0d4c0285@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <wE-o8gzF2GLUoJr8WFTYNyrCu6WelC00cyVyVME2EQs=.736a784b-398c-4f4a-8847-e1dd0d4c0285@github.com>
Message-ID: <WlCNXE76E1QnMhut6tXmkEWSLKvkAcMdhenr2s6tjXU=.96420d12-32f1-4860-8c79-c3c027c15cc2@github.com>

On Sun, 3 Oct 2021 09:11:40 GMT, BenEfrati <github.com+1887540+BenEfrati at openjdk.org> wrote:

> Is this fix is planned for OpenJDK 8u312?
Hi @BenEfrati, No chance to go to OpenJDK 8u312. Maybe 8u322 if it will be approved

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Oct  4 13:10:10 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 4 Oct 2021 13:10:10 GMT
Subject: RFR: 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: <hdmbpxC7tOsDRETPNlMMW8Fqar5lE2F-p6VvWkq4rPk=.05d1f579-a0c1-4108-a258-b66669dd4bcf@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

src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 169:

> 167:         this.algorithmConstraints = new SSLAlgorithmConstraints(
> 168:                 sslConfig.userSpecifiedAlgorithmConstraints);
> 169:         this.activeProtocols = new LinkedList<ProtocolVersion>(sslConfig.activeProtocols);

Just wonder why LinkedLIst, not ArrayList?

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

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

From weijun at openjdk.java.net  Mon Oct  4 13:38:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 13:38:12 GMT
Subject: RFR: 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: <LxU3wxOTCicb9qABE0tNKnKqFHOfLhfuUTlGe_Nwd_0=.a923d512-5507-4d80-9278-b710b6bd63b8@github.com>

On Sun, 3 Oct 2021 16:24:33 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

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

Change looks fine. Thanks for taking of this.

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

Marked as reviewed by weijun (Reviewer).

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

From weijun at openjdk.java.net  Mon Oct  4 14:03:09 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 14:03:09 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <-v-g_AZBWN_FeMpHTD9MZaJhVwAbFexqtbAFaq-cJ0M=.8667796b-cb16-4d67-870e-2237d48bfeda@github.com>

On Wed, 29 Sep 2021 10:45:41 GMT, Larry-N <github.com+75672469+Larry-N at openjdk.org> wrote:

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 306:

> 304:                                 () -> java.util.ServiceLoader.load(
> 305:                                     LoginModule.class, contextClassLoader));
> 306:                 Set<Provider<LoginModule>> lmProviders = sc.stream().collect(Collectors.toSet());

It's probably necessary to put the `collect` call above inside doPriv as well. The actual class loading might happen later.

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

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

From weijun at openjdk.java.net  Mon Oct  4 14:22:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 14:22:08 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <ccutL6Qc_o6nPLZpyA410qKs2beJzEn6636an-iRD1M=.51162354-9d78-4f3f-bdee-a039f3dcca9b@github.com>

On Wed, 29 Sep 2021 10:45:41 GMT, Larry-N <github.com+75672469+Larry-N at openjdk.org> wrote:

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 721:

> 719:                         for ( Provider<LoginModule> lm: lmp){
> 720:                             if (lm.type().getName().equals(name)){
> 721:                                 moduleStack[i].module = lm.get();

There is a small behavior change here. Originally the login module class is loaded first and then its name is checked. With this change, the name is first checked and then class loaded. This is certainly a performance boost but unfortunately the test at `test/jdk/javax/security/auth/spi/Loader.java` would fail. That test was written to ensure that services provided through a service loader are checked first and then fallback to `Class.forName()`. Either you need to enhance the test to confirm this in a new way, or it would have to be removed.

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

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

From weijun at openjdk.java.net  Mon Oct  4 14:25:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 14:25:14 GMT
Subject: RFR: 8274333: Redundant null comparison after Pattern.split
In-Reply-To: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
References: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>
Message-ID: <oPb_jkeF20O2VNyQ9aRr69mlGny7TmwsvaUKmF-3c0g=.59000391-4712-4e72-8d65-27c3e73e213f@github.com>

On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant.

Marked as reviewed by weijun (Reviewer).

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

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

From jnimeh at openjdk.java.net  Mon Oct  4 15:27:08 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 4 Oct 2021 15:27:08 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails [v3]
In-Reply-To: <JZ_3tdyt_rcAXe_UwDva3pYDBmD39N6k0g3HRtyo7p8=.06b0b96c-b764-4a35-8a5b-7c2c29df901a@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <JZ_3tdyt_rcAXe_UwDva3pYDBmD39N6k0g3HRtyo7p8=.06b0b96c-b764-4a35-8a5b-7c2c29df901a@github.com>
Message-ID: <ZuKPyg9Xm0zJskvHzOYmOZbk7kYGY9aJ_ZkeFqbMytc=.5e1f71e8-f9bd-4090-a976-e63d53e957e8@github.com>

On Fri, 1 Oct 2021 14:43:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that.
>> 
>> Some other cleanups:
>> 1. When using GET for OCSP, make sure no double slash.
>> 2. Several throws clauses are not necessary.
>> 
>> No regression test. OCSP needs to access an external server.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   verifier should not use automatically derived parameters fails

Looks good.  I like the algorithm agility enhancements to SimpleOCSPServer and CertificateBuilder.

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

Marked as reviewed by jnimeh (Reviewer).

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

From weijun at openjdk.java.net  Mon Oct  4 15:34:10 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 15:34:10 GMT
Subject: Integrated: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails
In-Reply-To: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
Message-ID: <5_DfeMsAEWMWC8OC1I0K3f17Fbos6D2q2dEYZmZz8hA=.3c2f2516-2130-4efc-a5b2-5ac530051b5a@github.com>

On Thu, 30 Sep 2021 15:44:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that.
> 
> Some other cleanups:
> 1. When using GET for OCSP, make sure no double slash.
> 2. Several throws clauses are not necessary.
> 
> No regression test. OCSP needs to access an external server.

This pull request has now been integrated.

Changeset: f63c4a83
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f63c4a832a1aea451f47aaf86d5361e970c6a28f
Stats:     112 lines in 9 files changed: 26 ins; 47 del; 39 mod

8274471: Verification of OCSP Response signed with RSASSA-PSS fails

Reviewed-by: hchao, jnimeh

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

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

From weijun at openjdk.java.net  Mon Oct  4 17:47:16 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 17:47:16 GMT
Subject: RFR: 8274721: UnixSystem fails to provide uid,
 gid or groups if no username is available
Message-ID: <EN23sCuUiAI8twxMH6vHcWKIECfGHrY9gclRZ9-D-58=.81bebba6-d08b-4719-bb62-6e2b55cad57d@github.com>

Two changes:

1. Calculation of groups is put in a separate block.
2. Add fallback for uid and gid

No regression test. Hard to reproduce bud reporter's environment in jtreg.

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

Commit messages:
 - 8274721: UnixSystem fails to provide uid, gid or groups if no username is available

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

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

From valeriep at openjdk.java.net  Mon Oct  4 18:51:09 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 4 Oct 2021 18:51:09 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v5]
In-Reply-To: <DVAqW0Mvs1nCXmp1hz987XCE-EVX82hdn3xO3-Ct6KI=.5521f36e-af06-4b0d-8881-1fc0fbfc5c04@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <DVAqW0Mvs1nCXmp1hz987XCE-EVX82hdn3xO3-Ct6KI=.5521f36e-af06-4b0d-8881-1fc0fbfc5c04@github.com>
Message-ID: <p7MGX8CjvKZH_5lGCH9mCzcHTyzN8i3lGWpDD_gRwJ8=.23b35f21-2cd0-4bde-884b-8c909ba78f94@github.com>

On Fri, 1 Oct 2021 17:09:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change removes weak etypes from the default list so it's safer to enable one of them. See the corresponding CSR at https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, please review the CSR as well.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   backout checksum changes
>   
>   reverted:

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.java.net  Mon Oct  4 19:21:07 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 4 Oct 2021 19:21:07 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf
In-Reply-To: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
Message-ID: <2Lmj3dJpuUJXMBDqrS9DexxJ1Zk7djfTw9yPdb3S8a8=.f47cf8d9-ffb5-4f7a-984a-09c2d0b17e25@github.com>

On Fri, 1 Oct 2021 17:36:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.

src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java line 75:

> 73:     // draft-brezak-win2k-krb-rc4-hmac-04.txt
> 74:     public static final int CKSUMTYPE_HMAC_MD5_ARCFOUR = -138;
> 75: 

nit: How about updating and fixing the copyright years?

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

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

From weijun at openjdk.java.net  Mon Oct  4 19:25:06 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 19:25:06 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf
In-Reply-To: <2Lmj3dJpuUJXMBDqrS9DexxJ1Zk7djfTw9yPdb3S8a8=.f47cf8d9-ffb5-4f7a-984a-09c2d0b17e25@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
 <2Lmj3dJpuUJXMBDqrS9DexxJ1Zk7djfTw9yPdb3S8a8=.f47cf8d9-ffb5-4f7a-984a-09c2d0b17e25@github.com>
Message-ID: <ZYRooRYRNgs5a53eaNbQZpVL2McymPCYqRQDGG5LFOo=.54e4d178-377c-41d9-93bd-036a3dc24f5d@github.com>

On Mon, 4 Oct 2021 19:18:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.
>
> src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java line 75:
> 
>> 73:     // draft-brezak-win2k-krb-rc4-hmac-04.txt
>> 74:     public static final int CKSUMTYPE_HMAC_MD5_ARCFOUR = -138;
>> 75: 
> 
> nit: How about updating and fixing the copyright years?

Will update it in the next commit.

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

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

From weijun at openjdk.java.net  Mon Oct  4 19:32:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 19:32:30 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf [v2]
In-Reply-To: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
Message-ID: <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>

> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.

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

  update copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5788/files
  - new: https://git.openjdk.java.net/jdk/pull/5788/files/dd85a079..83b94920

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

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

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

From valeriep at openjdk.java.net  Mon Oct  4 19:32:30 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 4 Oct 2021 19:32:30 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf
In-Reply-To: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
Message-ID: <mjPdEs2p_Un60tanYHs6XFDQGysb-lXRfPJSfiNIKEc=.1e16c368-30cc-4faa-b131-c803ca802552@github.com>

On Fri, 1 Oct 2021 17:36:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.

Do we still need all the constants defined in sun/security/krb5/internal/cryptoKeyUsage.java now that the corresponding classes are removed?

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

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

From valeriep at openjdk.java.net  Mon Oct  4 19:32:31 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 4 Oct 2021 19:32:31 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf [v2]
In-Reply-To: <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
 <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>
Message-ID: <b68vdw59qWl0H9TsG3z9L6rfSpPmppdp7T9TkctykZc=.8789e31f-4594-4ab2-93d0-6f374720d373@github.com>

On Mon, 4 Oct 2021 19:29:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright years

src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsReq.java line 320:

> 318:         byte[] temp = reqBody.asn1Encode(Krb5.KRB_TGS_REQ);
> 319:         // if the checksum type is one of the keyed checksum types,
> 320:         // use session key.

nit: does this comment need updating?

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

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

From weijun at openjdk.java.net  Mon Oct  4 19:32:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 19:32:32 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf [v2]
In-Reply-To: <b68vdw59qWl0H9TsG3z9L6rfSpPmppdp7T9TkctykZc=.8789e31f-4594-4ab2-93d0-6f374720d373@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
 <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>
 <b68vdw59qWl0H9TsG3z9L6rfSpPmppdp7T9TkctykZc=.8789e31f-4594-4ab2-93d0-6f374720d373@github.com>
Message-ID: <w87jcnoDORMdtA2G8uGm8-XekCSgBtCYgKUAxmgk-8o=.591d7ed9-c0b3-41fa-a84a-6d11a5846587@github.com>

On Mon, 4 Oct 2021 19:26:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright years
>
> src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsReq.java line 320:
> 
>> 318:         byte[] temp = reqBody.asn1Encode(Krb5.KRB_TGS_REQ);
>> 319:         // if the checksum type is one of the keyed checksum types,
>> 320:         // use session key.
> 
> nit: does this comment need updating?

Will remove it. I think there is no need to explain why -1 is used.

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

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

From weijun at openjdk.java.net  Mon Oct  4 19:42:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 4 Oct 2021 19:42:08 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf
In-Reply-To: <mjPdEs2p_Un60tanYHs6XFDQGysb-lXRfPJSfiNIKEc=.1e16c368-30cc-4faa-b131-c803ca802552@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
 <mjPdEs2p_Un60tanYHs6XFDQGysb-lXRfPJSfiNIKEc=.1e16c368-30cc-4faa-b131-c803ca802552@github.com>
Message-ID: <IbeHTITcICY2wGwB3m3eSGNhhzKSw-NAxHzFuDHhD8k=.755d323b-3d25-4c9c-adea-2f6d14a507a1@github.com>

On Mon, 4 Oct 2021 19:29:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Do we still need all the constants defined in sun/security/krb5/internal/cryptoKeyUsage.java now that the corresponding classes are removed?

I haven't touched this file, and I also haven't cleaned up constants in `sun/security/krb5/internal/Krb5.java`. I thought they can just be left there as placeholders.

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

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

From valeriep at openjdk.java.net  Mon Oct  4 19:59:08 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 4 Oct 2021 19:59:08 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf [v2]
In-Reply-To: <w87jcnoDORMdtA2G8uGm8-XekCSgBtCYgKUAxmgk-8o=.591d7ed9-c0b3-41fa-a84a-6d11a5846587@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
 <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>
 <b68vdw59qWl0H9TsG3z9L6rfSpPmppdp7T9TkctykZc=.8789e31f-4594-4ab2-93d0-6f374720d373@github.com>
 <w87jcnoDORMdtA2G8uGm8-XekCSgBtCYgKUAxmgk-8o=.591d7ed9-c0b3-41fa-a84a-6d11a5846587@github.com>
Message-ID: <8Lqc1vIelxx98OQYz9uHVEdLZmtZxuMiuaRcfouqdKA=.3999524a-04dc-48b7-bf73-384725d2abaa@github.com>

On Mon, 4 Oct 2021 19:28:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsReq.java line 320:
>> 
>>> 318:         byte[] temp = reqBody.asn1Encode(Krb5.KRB_TGS_REQ);
>>> 319:         // if the checksum type is one of the keyed checksum types,
>>> 320:         // use session key.
>> 
>> nit: does this comment need updating?
>
> Will remove it. I think there is no need to explain why -1 is used.

Sure

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

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

From weijun at openjdk.java.net  Tue Oct  5 01:00:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 5 Oct 2021 01:00:11 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application
In-Reply-To: <-v-g_AZBWN_FeMpHTD9MZaJhVwAbFexqtbAFaq-cJ0M=.8667796b-cb16-4d67-870e-2237d48bfeda@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <-v-g_AZBWN_FeMpHTD9MZaJhVwAbFexqtbAFaq-cJ0M=.8667796b-cb16-4d67-870e-2237d48bfeda@github.com>
Message-ID: <NFBmdYvfcPBkuDQFfFTJxDbsCI5jWagzVKBa7lyvIvc=.a216d79f-7f73-4b1f-b1dd-4c334da68b15@github.com>

On Mon, 4 Oct 2021 13:59:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 306:
> 
>> 304:                                 () -> java.util.ServiceLoader.load(
>> 305:                                     LoginModule.class, contextClassLoader));
>> 306:                 Set<Provider<LoginModule>> lmProviders = sc.stream().collect(Collectors.toSet());
> 
> It's probably necessary to put the `collect` call above inside doPriv as well. The actual class loading might happen later.

I'm seeing a JCK failure on this change. Will investigate more. At the same time, is it possible to merge this synchronized block into the one below?

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

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

From aefimov at openjdk.java.net  Tue Oct  5 12:10:28 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 5 Oct 2021 12:10:28 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution
 SPI
Message-ID: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>

This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.

The following API classes are added to `java.net.spi` package to facilitate this:
- `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
- `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
- `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
- `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  

More details in [JEP-418](https://openjdk.java.net/jeps/418).

Testing: new and existing `tier1:tier3` tests

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

Commit messages:
 - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI

Changes: https://git.openjdk.java.net/jdk/pull/5822/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244202
  Stats: 2779 lines in 50 files changed: 2524 ins; 134 del; 121 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Oct  5 13:40:12 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 5 Oct 2021 13:40:12 GMT
Subject: Integrated: 8274079: Cleanup unnecessary calls to
 Throwable.initCause() in java.base module
In-Reply-To: <yT2Auvz6F8-c5nHnfMb5rIfI7Q42sNyOHsyMFANd1jk=.5797dd93-89fd-4c53-9259-ec82fda1b387@github.com>
References: <yT2Auvz6F8-c5nHnfMb5rIfI7Q42sNyOHsyMFANd1jk=.5797dd93-89fd-4c53-9259-ec82fda1b387@github.com>
Message-ID: <dpR9pQwrUaQTc8PuRX7r1vXO7uf7xcE_rJp_0cL1Fmw=.20c9e2ac-ee63-4ec7-bcfa-17b78b0da439@github.com>

On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Pass "cause" exception as constructor parameter is shorter and easier to read.

This pull request has now been integrated.

Changeset: 1459180f
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1459180f352a5632c0afca2ed55abf31e4b0bfb0
Stats:     132 lines in 22 files changed: 0 ins; 77 del; 55 mod

8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

Reviewed-by: weijun

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

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

From aph-open at littlepinkcloud.com  Tue Oct  5 13:55:07 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 5 Oct 2021 14:55:07 +0100
Subject: Please have a quick look at 8274730: AArch64: AES/GCM acceleration is
 broken by the fix for JDK-8273297
Message-ID: <933c7ca3-2168-74a5-9f3d-68202005d1ec@littlepinkcloud.com>

I had to touch common code in C2 to unbreak AArch64, so I'd like
another reviewer, please. It's pretty simple, thanks.

https://github.com/openjdk/jdk/pull/5819

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From sean.mullan at oracle.com  Tue Oct  5 14:27:27 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 5 Oct 2021 10:27:27 -0400
Subject: Different way to solve 8241047
In-Reply-To: <f14c2150-0130-baad-187a-3a08e4397e51@gmx.net>
References: <f14c2150-0130-baad-187a-3a08e4397e51@gmx.net>
Message-ID: <09c69566-b8ea-9101-ff07-570922098a3e@oracle.com>

Hi Philippe,

On 10/3/21 11:32 AM, Philippe Marschall wrote:
> Hello
> 
> First I hope this is the right mailing list. Second, I realize I'm late
> to the party and this ship may already have sailed.

Yes, this is the right mailing list.

> We're using a third party library from a vendor that calls
> SSLSession.getPeerCertificateChain() [1]. The vendor is unlikely to ship
> a JDK 17 compatible version of this library this decade.

The method in question has not been removed from 17 so their code should 
continue to work as long as the deprecated methods continue to be 
overridden. It's unfortunate that the 3rd party library cannot be 
changed - is it active? The SSLSession.getPeerCertificateChain() has 
been deprecated since Java 9 and marked for removal since Java 13, and 
there has been a replacement API available 
SSLSession.getPeerCertificates() since Java 1.4. That's a lot of time to 
migrate.

> I was wondering if any consideration was given to implementing
> #getPeerCertificateChain by calling #getPeerCertificates [2] and
> implementing javax.security.cert.X509Certificate by delegating to
> java.security.cert.X509Certificate [3]. I believe this would preserve
> source, binary and behavior compatibility while at the same time freeing
> implementations from having to deal with javax.security.cert types or
> #getPeerCertificateChain.

It is an interesting suggestion and I can see your point. I don't think 
there is any fundamental reason we could not change the default 
implementation of the SSLSession.getPeerCertificateChain() method, but 
since it would be a change to the specification, it could not be 
backported to 17. Also, these methods are marked for removal, so 
changing the default implementation at this point probably doesn't add 
much value.

--Sean

> The third party library we use does support configuring a custom
> SSLSocketFactory and we'll likely go with a custom SSLSocketFactory.
> 
>    [1] https://bugs.openjdk.java.net/browse/JDK-8241047
>    [2]
> https://github.com/marschall/legacy-compatibility-ssl-socket-factory/blob/master/src/main/java/com/github/marschall/legacycompatibilitysslsocketfactory/LegacyCompatibilitySSLSession.java#L86
>    [3]
> https://github.com/marschall/legacy-compatibility-ssl-socket-factory/blob/master/src/main/java/com/github/marschall/legacycompatibilitysslsocketfactory/CertificateAdapter.java
> 
> Cheers
> Philippe
> 

From mullan at openjdk.java.net  Tue Oct  5 17:03:08 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 5 Oct 2021 17:03:08 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v5]
In-Reply-To: <DVAqW0Mvs1nCXmp1hz987XCE-EVX82hdn3xO3-Ct6KI=.5521f36e-af06-4b0d-8881-1fc0fbfc5c04@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <DVAqW0Mvs1nCXmp1hz987XCE-EVX82hdn3xO3-Ct6KI=.5521f36e-af06-4b0d-8881-1fc0fbfc5c04@github.com>
Message-ID: <6jeM6kYuz7aRI5zzj6i495FIgyu828f8sZq4o7YQugE=.fc91924b-0f9a-4d7b-938b-ac9320e9233e@github.com>

On Fri, 1 Oct 2021 17:09:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change removes weak etypes from the default list so it's safer to enable one of them. See the corresponding CSR at https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, please review the CSR as well.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   backout checksum changes
>   
>   reverted:

Marked as reviewed by mullan (Reviewer).

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

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

From valeriep at openjdk.java.net  Tue Oct  5 18:11:09 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 5 Oct 2021 18:11:09 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf [v2]
In-Reply-To: <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
 <F2lmDc4DeT6NNBfW11tkvO5ngsizca4-ItXqHexwLUs=.ab2214d4-c971-4109-9589-2b4189036780@github.com>
Message-ID: <0Xv50Va2q8KvdaRvhf0JFh3rEVsZf5JR9zvlvot2oY8=.9a7f15d5-3a63-4ea1-abee-8a2d4746efba@github.com>

On Mon, 4 Oct 2021 19:32:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright years

Looks good. Thanks.

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

Marked as reviewed by valeriep (Reviewer).

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

From weijun at openjdk.java.net  Tue Oct  5 18:21:22 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 5 Oct 2021 18:21:22 GMT
Subject: Integrated: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
Message-ID: <OUKaVXHzAPogok_AXBDV0WL0dMt4EAy2vijf09bV68Y=.a85c152a-574a-47cc-a7b4-f92a14a30a16@github.com>

On Thu, 23 Sep 2021 14:32:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change removes weak etypes from the default list so it's safer to enable one of them. See the corresponding CSR at https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, please review the CSR as well.

This pull request has now been integrated.

Changeset: 03d3c033
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03d3c0338437bf10b631881c8910ca85985742f6
Stats:     173 lines in 7 files changed: 73 ins; 61 del; 39 mod

8273670: Remove weak etypes from default krb5 etype list

Reviewed-by: valeriep, mullan

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

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

From weijun at openjdk.java.net  Tue Oct  5 18:23:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 5 Oct 2021 18:23:34 GMT
Subject: RFR: 8274656: Remove default_checksum and safe_checksum_type from
 krb5.conf [v3]
In-Reply-To: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
Message-ID: <I5AJxCnJCyL4xPMx4EKiDRRIT6OQyi6T_EkwS4CEMaQ=.8cbd0b78-bc1a-4d8b-b457-5d9f8e13d0fa@github.com>

> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.

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

  clean up comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5788/files
  - new: https://git.openjdk.java.net/jdk/pull/5788/files/83b94920..1a975f92

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

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

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

From weijun at openjdk.java.net  Tue Oct  5 18:23:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 5 Oct 2021 18:23:34 GMT
Subject: Integrated: 8274656: Remove default_checksum and safe_checksum_type
 from krb5.conf
In-Reply-To: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
References: <5_dUkH9npb4WOgEq8wSkJQWHxQgsQ2jR-ueFrLDUYgg=.5a58c92f-fd71-48f4-8073-9684a52ad5d3@github.com>
Message-ID: <y-hjYrOioEi7Mpl0Fz3LkyuRmAhIafQXZMXwOjiMlTQ=.f65d917a-afc9-4ea9-bcd7-49098b3baa6e@github.com>

On Fri, 1 Oct 2021 17:36:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java.

This pull request has now been integrated.

Changeset: 1e752033
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e75203356666a3213deddd775ad1e883ea6d78d
Stats:     1350 lines in 13 files changed: 0 ins; 1345 del; 5 mod

8274656: Remove default_checksum and safe_checksum_type from krb5.conf

Reviewed-by: valeriep

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

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

From cancomert at gmail.com  Tue Oct  5 18:36:06 2021
From: cancomert at gmail.com (can comert)
Date: Tue, 5 Oct 2021 20:36:06 +0200
Subject: Integrated: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails
In-Reply-To: <5_DfeMsAEWMWC8OC1I0K3f17Fbos6D2q2dEYZmZz8hA=.3c2f2516-2130-4efc-a5b2-5ac530051b5a@github.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <5_DfeMsAEWMWC8OC1I0K3f17Fbos6D2q2dEYZmZz8hA=.3c2f2516-2130-4efc-a5b2-5ac530051b5a@github.com>
Message-ID: <CAPnQxbbw1gYFE_xt1wQBWM8Y1QSeG+me5qAGR=EKDUSz0ey1qg@mail.gmail.com>

I have seen the issue is already fixed and will be available for the JDK 18.
Thank you very much for your great work and fast response!

Is there any backporting for a LTS version planned?

Best Regards,
Can

4 Eki 2021 Pzt 17:34 tarihinde Weijun Wang <weijun at openjdk.java.net> ?unu
yazd?:

> On Thu, 30 Sep 2021 15:44:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>
> > Extra parameters need to be set for RSASSA-PSS signatures. We already
> have a helper method for that.
> >
> > Some other cleanups:
> > 1. When using GET for OCSP, make sure no double slash.
> > 2. Several throws clauses are not necessary.
> >
> > No regression test. OCSP needs to access an external server.
>
> This pull request has now been integrated.
>
> Changeset: f63c4a83
> Author:    Weijun Wang <weijun at openjdk.org>
> URL:
> https://git.openjdk.java.net/jdk/commit/f63c4a832a1aea451f47aaf86d5361e970c6a28f
> Stats:     112 lines in 9 files changed: 26 ins; 47 del; 39 mod
>
> 8274471: Verification of OCSP Response signed with RSASSA-PSS fails
>
> Reviewed-by: hchao, jnimeh
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5778
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211005/467b6d02/attachment.htm>

From weijun.wang at oracle.com  Tue Oct  5 20:04:50 2021
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Tue, 5 Oct 2021 20:04:50 +0000
Subject: Integrated: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails
In-Reply-To: <CAPnQxbbw1gYFE_xt1wQBWM8Y1QSeG+me5qAGR=EKDUSz0ey1qg@mail.gmail.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <5_DfeMsAEWMWC8OC1I0K3f17Fbos6D2q2dEYZmZz8hA=.3c2f2516-2130-4efc-a5b2-5ac530051b5a@github.com>
 <CAPnQxbbw1gYFE_xt1wQBWM8Y1QSeG+me5qAGR=EKDUSz0ey1qg@mail.gmail.com>
Message-ID: <FD037ADF-40C6-49E8-B71B-E57F16C8686C@oracle.com>

I think it's worth backporting to older LTS releases. Will ask sustaining on it.

Thanks,
Weijun

> On Oct 5, 2021, at 2:36 PM, can comert <cancomert at gmail.com> wrote:
> 
> 
> Is there any backporting for a LTS version planned?


From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 07:12:20 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 07:12:20 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
Message-ID: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>

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

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

Commit messages:
 - [PATCH] Use try-with-resources to close FileInputStream in java.base

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct  6 07:23:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 6 Oct 2021 07:23:21 GMT
Subject: RFR: 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: <fQgG2FyuQIDLhzYKAXVrCJH_fLt7G9zeEhYhBD3ZLg0=.0e806df7-95cb-485b-b3d7-aa71eb3186c7@github.com>

On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov <github.com+741251+turbanoff 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

src/java.base/share/classes/java/util/ResourceBundle.java line 3732:

> 3730:     }
> 3731: 
> 3732:     private static final boolean TRACE_ON = Boolean.parseBoolean(

I think for `Boolean` it doesn't make significant difference, as both `Boolean.TRUE` and `Boolean.FALSE` are cached and initialized immediately along with the class itself:

public static Boolean valueOf(String s) {
  return parseBoolean(s) ? TRUE : FALSE;
}

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 07:23:20 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 07:23:20 GMT
Subject: RFR: 8274811: Remove superfluous use of boxing in java.base
Message-ID: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>

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

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

Commit messages:
 - [PATCH] Remove superfluous use of boxing in java.base
 - [PATCH] Remove superfluous use of boxing in java.* modules
 - [PATCH] Remove superfluous use of boxing in java.* modules

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 07:23:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 07:23:22 GMT
Subject: RFR: 8274811: Remove superfluous use of boxing in java.base
In-Reply-To: <fQgG2FyuQIDLhzYKAXVrCJH_fLt7G9zeEhYhBD3ZLg0=.0e806df7-95cb-485b-b3d7-aa71eb3186c7@github.com>
References: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
 <fQgG2FyuQIDLhzYKAXVrCJH_fLt7G9zeEhYhBD3ZLg0=.0e806df7-95cb-485b-b3d7-aa71eb3186c7@github.com>
Message-ID: <S3NmQ_TEn2rTd5Q6WB9e7dxpmYuzs5a4wnRCCWC328U=.07c8ab48-92ca-43f7-8862-577e2c077e7a@github.com>

On Sat, 11 Sep 2021 17:22:01 GMT, ?????? ??????? <github.com+10835776+stsypanov 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
>
> src/java.base/share/classes/java/util/ResourceBundle.java line 3732:
> 
>> 3730:     }
>> 3731: 
>> 3732:     private static final boolean TRACE_ON = Boolean.parseBoolean(
> 
> I think for `Boolean` it doesn't make significant difference, as both `Boolean.TRUE` and `Boolean.FALSE` are cached and initialized immediately along with the class itself:
> 
> public static Boolean valueOf(String s) {
>   return parseBoolean(s) ? TRUE : FALSE;
> }

Yes, there is no allocation for booleans. But still 2 redundant method calls in interpreter mode (valueOf+booleanValue)

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 12:29:23 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 12:29:23 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
Message-ID: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>

Redundant castings make code harder to read.
Found them by IntelliJ IDEA.
I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

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

Commit messages:
 - [PATCH] Remove unnecessary castings in java.base
 - [PATCH] Remove unnecessary castings in java.base

Changes: https://git.openjdk.java.net/jdk/pull/5454/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5454&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274835
  Stats: 38 lines in 15 files changed: 1 ins; 4 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5454.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5454/head:pull/5454

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

From mullan at openjdk.java.net  Wed Oct  6 13:05:07 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 6 Oct 2021 13:05:07 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <2g6lp6Qoc6CkGSZxYcxU6J9lyufzUB_nM-JtXOt7Yng=.66528e37-4512-47d6-9818-7acc6a99a42d@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

The security related files look fine.

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

Marked as reviewed by mullan (Reviewer).

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

From mullan at openjdk.java.net  Wed Oct  6 13:08:11 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 6 Oct 2021 13:08:11 GMT
Subject: RFR: 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: <UgKQoKJ7M34sdcOjGUoMS7m6VIqxLqm786L-NEHVbuo=.08be5cf9-d796-43f2-b113-faf4a09c054d@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

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

The security related files look fine.

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

Marked as reviewed by mullan (Reviewer).

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

From sebukoleth at gmail.com  Wed Oct  6 03:53:52 2021
From: sebukoleth at gmail.com (Sebu Koleth)
Date: Tue, 5 Oct 2021 20:53:52 -0700
Subject: X509TrustManager check in SSLContextImpl
Message-ID: <CAJTJeJjUNsiuA9o78oQpGhkogw=cLyX5pOz-2Yzj8+9RPNqNvQ@mail.gmail.com>

Apologies if this is the wrong mailing list for this question, and if yes,
please point to the right one.
In sun.security.ssl.SSLContextImpl we have the following method:

private X509TrustManager chooseTrustManager(TrustManager[] tm)
            throws KeyManagementException {
        // We only use the first instance of X509TrustManager passed to us.
        for (int i = 0; tm != null && i < tm.length; i++) {
            if (tm[i] instanceof X509TrustManager) {

* if (SunJSSE.isFIPS() &&                        !(tm[i] instanceof
X509TrustManagerImpl))* {
                    throw new KeyManagementException
                        ("FIPS mode: only SunJSSE TrustManagers may be
used");
                }

                if (tm[i] instanceof X509ExtendedTrustManager) {
                    return (X509TrustManager)tm[i];
                } else {
                    return new AbstractTrustManagerWrapper(
                                        (X509TrustManager)tm[i]);
                }
            }
        }

        // nothing found, return a dummy X509TrustManager.
        return DummyX509TrustManager.INSTANCE;
    }

In the FIPS case why is it required for the TrustManager to be an instance
of X509TrustManagerImpl? Isn't it sufficient for it to be an instance of
X509ExtendedTrustManager?

regards,
Sebu Koleth
-- 
The most popular software for writing fiction isn't Word. It's Excel.
408 dot 759 dot 1870
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211005/f80634ee/attachment.htm>

From wetmore at openjdk.java.net  Wed Oct  6 16:05:13 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 16:05:13 GMT
Subject: RFR: 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: <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

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

Reviewed the crypto/security files.

src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 115:

> 113: 
> 114:         // Send the request
> 115:         try (DataOutputStream output = new DataOutputStream(connection.getOutputStream())) {

Please break this up so it doesn't have lines > 80.  e.g.

        try (DataOutputStream output =
                new DataOutputStream(connection.getOutputStream())) {

This makes side-by-side viewing very hard without a wider monitor.  

Thank you.

src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 127:

> 125:         // Receive the reply
> 126:         byte[] replyBuffer = null;
> 127:         try (BufferedInputStream input = new BufferedInputStream(connection.getInputStream())) {

Same comment as above.

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

Marked as reviewed by wetmore (Reviewer).

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

From wetmore at openjdk.java.net  Wed Oct  6 16:14:09 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 16:14:09 GMT
Subject: RFR: 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: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

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

I checked the rest.  The one BufferedInputStream change is puzzling.  Please explain or address.

Files like HttpTimestamper need the copyright dates updated to 2021.

src/java.base/share/classes/sun/net/NetProperties.java line 71:

> 69:             f = new File(f, "net.properties");
> 70:             fname = f.getCanonicalPath();
> 71:             try (FileInputStream fis = new FileInputStream(fname)) {

Why did the BufferedInputStream get pulled out here?

src/java.base/share/classes/sun/security/util/PolicyUtil.java line 156:

> 154:                 }
> 155: 
> 156:                 try (InputStream inStream = new BufferedInputStream(getInputStream(keyStoreUrl))) {

Same comment as above.

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

Marked as reviewed by wetmore (Reviewer).

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

From naoto at openjdk.java.net  Wed Oct  6 16:28:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 16:28:06 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <bjZ-M-6Z6gJtz-cqjVE5v8-6mkv_3XnoLeU8vuq3U0E=.61ef8c3b-31e6-4ad2-872c-7934502fa8a7@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Calendar-related changes look good to me.

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

Marked as reviewed by naoto (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 16:29:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 16:29:08 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
Message-ID: <j2azoLMg49XzvhEi1EFfnNsuz2hKET6ONLfeGdsmPxg=.dd2a061f-d27d-4f03-a8d6-4037b0340666@github.com>

On Wed, 6 Oct 2021 16:04:54 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> src/java.base/share/classes/sun/net/NetProperties.java line 71:
> 
>> 69:             f = new File(f, "net.properties");
>> 70:             fname = f.getCanonicalPath();
>> 71:             try (FileInputStream fis = new FileInputStream(fname)) {
> 
> Why did the BufferedInputStream get pulled out here?

I decieded to remove it because `Properties.load` already buffers inputstream. So usage of BufferedInputStream seems redundant.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Properties.java#L471

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 16:29:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 16:29:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <j2azoLMg49XzvhEi1EFfnNsuz2hKET6ONLfeGdsmPxg=.dd2a061f-d27d-4f03-a8d6-4037b0340666@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
 <j2azoLMg49XzvhEi1EFfnNsuz2hKET6ONLfeGdsmPxg=.dd2a061f-d27d-4f03-a8d6-4037b0340666@github.com>
Message-ID: <aMlE4gAtTbyeoi6GXIEn9eeET1dkLFdZOJcqSOqCylY=.b218b6f9-48d2-4de2-9981-0ec2d3fb4a2b@github.com>

On Wed, 6 Oct 2021 16:24:03 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/NetProperties.java line 71:
>> 
>>> 69:             f = new File(f, "net.properties");
>>> 70:             fname = f.getCanonicalPath();
>>> 71:             try (FileInputStream fis = new FileInputStream(fname)) {
>> 
>> Why did the BufferedInputStream get pulled out here?
>
> I decieded to remove it because `Properties.load` already buffers inputstream. So usage of BufferedInputStream seems redundant.
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Properties.java#L471

I will revert back to `BufferedInputStream` and will create a separate PR to cleanup redundant buffering around Properties.load calls.

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

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

From prappo at openjdk.java.net  Wed Oct  6 16:29:09 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 6 Oct 2021 16:29:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
Message-ID: <XMuOg0gXY_Zrqud8qSHFffGKuSbGJG2snnFhvI7A_TE=.f10f99d8-f43e-4d9d-8de6-b6b2079e3b60@github.com>

On Wed, 6 Oct 2021 16:00:41 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 127:
> 
>> 125:         // Receive the reply
>> 126:         byte[] replyBuffer = null;
>> 127:         try (BufferedInputStream input = new BufferedInputStream(connection.getInputStream())) {
> 
> Same comment as above.

In this and the immediately preceding case, it might be better to use `var`.

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

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

From lancea at openjdk.java.net  Wed Oct  6 16:33:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 6 Oct 2021 16:33:09 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <izYxd9rrVsXAmp4ucJKzcuPcA9YMeQ8TcBQSARA-484=.fcfdb84d-518e-44b7-b878-d9a2aa7fe92e@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Marked as reviewed by lancea (Reviewer).

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

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

From coffeys at openjdk.java.net  Wed Oct  6 17:07:25 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 6 Oct 2021 17:07:25 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks
Message-ID: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>

Use correct manifest file name in the Manifest verifier checks. 
Also - extra null check

The test doesn't reproduce the exact issue reported but should prevent future regressions in this area.

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

Commit messages:
 - 8273826: Correct Manifest file name and NPE checks

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

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

From darcy at openjdk.java.net  Wed Oct  6 17:15:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 6 Oct 2021 17:15:08 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis.

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

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

From weijun at openjdk.java.net  Wed Oct  6 18:03:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 6 Oct 2021 18:03:11 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks
In-Reply-To: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
Message-ID: <JccIr7TFIBOjkYe4gnBdHAKi1sUIIzY4qDTMa38RxN8=.956cf861-acb7-4322-a29d-8d0353c649dc@github.com>

On Wed, 6 Oct 2021 16:58:51 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Use correct manifest file name in the Manifest verifier checks. 
> Also - extra null check
> 
> The test doesn't reproduce the exact issue reported but should prevent future regressions in this area.

Marked as reviewed by weijun (Reviewer).

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

> 64: 
> 65:     private String name = null;
> 66:     private String manifestFileName;

Make this final and add a comment that it will never be null.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:27:34 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:27:34 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v2]
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <kCR9NYb_cjq355Utk1hloVrmWB0HTTKyLJbjaYtaNGY=.3e54ac08-5fdc-4422-a95e-490ed596af5d@github.com>

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

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

  8274809: Update java.base classes to use try-with-resources
  fix post-review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5818/files
  - new: https://git.openjdk.java.net/jdk/pull/5818/files/6d8ce900..78893df9

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:27:35 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:27:35 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v2]
In-Reply-To: <XMuOg0gXY_Zrqud8qSHFffGKuSbGJG2snnFhvI7A_TE=.f10f99d8-f43e-4d9d-8de6-b6b2079e3b60@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
 <XMuOg0gXY_Zrqud8qSHFffGKuSbGJG2snnFhvI7A_TE=.f10f99d8-f43e-4d9d-8de6-b6b2079e3b60@github.com>
Message-ID: <U5j_EMVmod4TeFOPUYJoM-i0f8xCc3TIt4YEVhlDqP4=.1dd8529c-a29d-46ad-93f2-951d501b7ce8@github.com>

On Wed, 6 Oct 2021 16:20:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 127:
>> 
>>> 125:         // Receive the reply
>>> 126:         byte[] replyBuffer = null;
>>> 127:         try (BufferedInputStream input = new BufferedInputStream(connection.getInputStream())) {
>> 
>> Same comment as above.
>
> In this and the immediately preceding case, it might be better to use `var`.

I like variant with `var` more. Updated

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:47:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:47:26 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>

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

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5818/files
  - new: https://git.openjdk.java.net/jdk/pull/5818/files/78893df9..423c3069

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

  Stats: 5 lines in 4 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5818/head:pull/5818

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:47:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:47:27 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
Message-ID: <UUjftXz7iJaziZeMCKWfEuTHd1fx-yf6juWqnJcm_Uk=.c8f6a1c7-0368-42bc-8b65-2ad965fa60e4@github.com>

On Wed, 6 Oct 2021 16:11:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>Files like HttpTimestamper need the copyright dates updated to 2021.

Updated

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

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

From wetmore at openjdk.java.net  Wed Oct  6 19:48:09 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 19:48:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
Message-ID: <vOTsKEjrvDfZ81YauUCn6-FM8yA6x-Wly9ucYRRsQS4=.f36e216e-fe56-49a4-b892-73d1e6b5ee76@github.com>

On Wed, 6 Oct 2021 18:47:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274809: Update java.base classes to use try-with-resources
>   update copyright year

Greater than 80 chars comment missing in latest changeset.

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

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

From wetmore at openjdk.java.net  Wed Oct  6 19:48:10 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 19:48:10 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
Message-ID: <Xuaobz8vUg6qQCiTrqN45KysxBN3a2qTAoLfi11lylE=.8bdc7ee0-aa14-48a8-8154-b0c81a120d07@github.com>

On Wed, 6 Oct 2021 16:07:12 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274809: Update java.base classes to use try-with-resources
>>   update copyright year
>
> src/java.base/share/classes/sun/security/util/PolicyUtil.java line 156:
> 
>> 154:                 }
>> 155: 
>> 156:                 try (InputStream inStream = new BufferedInputStream(getInputStream(keyStoreUrl))) {
> 
> Same comment as above.

Looks like it's still > 80 chars

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

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

From wetmore at openjdk.java.net  Wed Oct  6 19:56:08 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 19:56:08 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
Message-ID: <lYZpk_72o-DFp2R1PwL9ZvijUF_uRvdyDVIpukL5RUY=.38c59cb6-64bb-4fed-9799-604f1e8d50ec@github.com>

On Wed, 6 Oct 2021 18:47:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274809: Update java.base classes to use try-with-resources
>   update copyright year

src/java.base/share/classes/sun/net/NetProperties.java line 72:

> 70:             fname = f.getCanonicalPath();
> 71:             try (FileInputStream in = new FileInputStream(fname)) {
> 72:                 BufferedInputStream bin = new BufferedInputStream(in);

Shouldn't this have a multiple resource block in the try-with block here:  

    try (FileInputStream in = new FileInputStream(fname);
            BufferedInputStream bin = new BufferedInputStream(in)) {
        props.land(bin);
    }

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 20:37:30 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 20:37:30 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v4]
In-Reply-To: <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
Message-ID: <G11s28BssBpoI4hpV5H4jLErkk6yLbhh-USd3wcDJqg=.f9b097a0-0738-4a87-8881-787ab10239bf@github.com>

On Wed, 6 Oct 2021 16:00:26 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274809: Update java.base classes to use try-with-resources
>>   fix review comments
>
> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 115:
> 
>> 113: 
>> 114:         // Send the request
>> 115:         try (DataOutputStream output = new DataOutputStream(connection.getOutputStream())) {
> 
> Please break this up so it doesn't have lines > 80.  e.g.
> 
>         try (DataOutputStream output =
>                 new DataOutputStream(connection.getOutputStream())) {
> 
> This makes side-by-side viewing very hard without a wider monitor.  
> 
> Thank you.

Update.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 20:37:29 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 20:37:29 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v4]
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <FZuIidy72Sp0Bj9To9eH5dUGHDyF_kd20Dyqw-fPPAA=.61a14a85-d5ab-4268-97f3-3d6e511e5988@github.com>

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

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5818/files
  - new: https://git.openjdk.java.net/jdk/pull/5818/files/423c3069..3b05ec49

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

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

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

From bpb at openjdk.java.net  Wed Oct  6 21:08:12 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 6 Oct 2021 21:08:12 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <wee37TyGNDjU0xrCVV9iO2UWHgZtVwT22jL8ZQTTJpI=.7ecb2791-480e-4b2b-b155-c826bcd7d161@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

`java.io` change looks all right.

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

Marked as reviewed by bpb (Reviewer).

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

From hchao at openjdk.java.net  Thu Oct  7 02:24:06 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 7 Oct 2021 02:24:06 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks
In-Reply-To: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
Message-ID: <QEjUYaM0QRNRn6DBPGBUJzMxniZNkKumLIrYXBXe5Qg=.c2ea4555-de00-4f11-b4a7-5b92b4eed914@github.com>

On Wed, 6 Oct 2021 16:58:51 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Use correct manifest file name in the Manifest verifier checks. 
> Also - extra null check
> 
> The test doesn't reproduce the exact issue reported but should prevent future regressions in this area.

Looks good.

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

Marked as reviewed by hchao (Committer).

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 07:35:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 07:35:21 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within
 java.base classes
Message-ID: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>

StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
1. Plain String concatenation should be preferred
2. StringBuilder is a direct replacement to StringBuffer which generally have better performance

In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

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

Commit messages:
 - [PATCH] Cleanup usages of StringBuffer in java.base module
 - [PATCH] Cleanup usages of StringBuffer in java.base module

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

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

From coffeys at openjdk.java.net  Thu Oct  7 10:44:39 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 7 Oct 2021 10:44:39 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
Message-ID: <vDd2sF-tfPhDg2FXogNFYmHhDbvgoDWhHsd86MJfr48=.ccd82f7c-53eb-4971-936a-8520e14c3dd8@github.com>

> Use correct manifest file name in the Manifest verifier checks. 
> Also - extra null check
> 
> The test doesn't reproduce the exact issue reported but should prevent future regressions in this area.

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

  Make variables final

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5841/files
  - new: https://git.openjdk.java.net/jdk/pull/5841/files/a63c81ad..3d72a6d7

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

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

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

From aefimov at openjdk.java.net  Thu Oct  7 12:11:36 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 7 Oct 2021 12:11:36 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v2]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <dMUneM5p-a7rqI0dGENOIlnu5UeYpsqz8LWFqAlJpSM=.4ec033de-9e34-41c0-a81d-b53855161d5f@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov 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 JDK-8244202_JEP418_impl
 - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/77551538..41717fc7

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

  Stats: 4216 lines in 179 files changed: 1929 ins; 1744 del; 543 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

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

From coffeys at openjdk.java.net  Thu Oct  7 14:24:10 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 7 Oct 2021 14:24:10 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <JccIr7TFIBOjkYe4gnBdHAKi1sUIIzY4qDTMa38RxN8=.956cf861-acb7-4322-a29d-8d0353c649dc@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
 <JccIr7TFIBOjkYe4gnBdHAKi1sUIIzY4qDTMa38RxN8=.956cf861-acb7-4322-a29d-8d0353c649dc@github.com>
Message-ID: <vl-hUYZw4P0Oat11G8za-re9exNVKltvJ10u-p7KBF4=.9d5cfea2-eb11-42c5-ae40-fb1b8d3d6307@github.com>

On Wed, 6 Oct 2021 17:54:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make variables final
>
> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 66:
> 
>> 64: 
>> 65:     private String name = null;
>> 66:     private String manifestFileName;
> 
> Make this final and add a comment that it will never be null.

Thanks for the review - Made final and added comment. Also decided to make the "Manifest man" variable final here also while here.

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

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

From mullan at openjdk.java.net  Thu Oct  7 15:02:10 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 7 Oct 2021 15:02:10 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <vDd2sF-tfPhDg2FXogNFYmHhDbvgoDWhHsd86MJfr48=.ccd82f7c-53eb-4971-936a-8520e14c3dd8@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
 <vDd2sF-tfPhDg2FXogNFYmHhDbvgoDWhHsd86MJfr48=.ccd82f7c-53eb-4971-936a-8520e14c3dd8@github.com>
Message-ID: <fPcqAv-yrmVaRqqFYNFUJ-WCmuWIpZ9tQm7LLVQotL4=.bfb44100-f8e1-46a9-9c18-536ddb2d82da@github.com>

On Thu, 7 Oct 2021 10:44:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Use correct manifest file name in the Manifest verifier checks. 
>> Also - extra null check
>> 
>> The test doesn't reproduce the exact issue reported but should prevent future regressions in this area.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make variables final

Marked as reviewed by mullan (Reviewer).

test/jdk/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java line 38:

> 36:  * @library /test/lib ../
> 37:  * @build jdk.test.lib.util.JarUtils
> 38:  * @run main LowerCaseManifest

You don't need this line as this is the default @run setting.

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

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

From weijun at openjdk.java.net  Thu Oct  7 15:02:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 7 Oct 2021 15:02:11 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <vl-hUYZw4P0Oat11G8za-re9exNVKltvJ10u-p7KBF4=.9d5cfea2-eb11-42c5-ae40-fb1b8d3d6307@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
 <JccIr7TFIBOjkYe4gnBdHAKi1sUIIzY4qDTMa38RxN8=.956cf861-acb7-4322-a29d-8d0353c649dc@github.com>
 <vl-hUYZw4P0Oat11G8za-re9exNVKltvJ10u-p7KBF4=.9d5cfea2-eb11-42c5-ae40-fb1b8d3d6307@github.com>
Message-ID: <q4C81Ca8nH2CS4EJ8Vb4EMBdLOPGlkUXAaSHo-00n1I=.fb9c962b-600c-46ef-b482-dbfd510a67f4@github.com>

On Thu, 7 Oct 2021 14:21:27 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 66:
>> 
>>> 64: 
>>> 65:     private String name = null;
>>> 66:     private String manifestFileName;
>> 
>> Make this final and add a comment that it will never be null.
>
> Thanks for the review - Made final and added comment. Also decided to make the "Manifest man" variable final here also while here.

Great, the more final there are, the less I need to look back and forth while reading the code.

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

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

From coffeys at openjdk.java.net  Thu Oct  7 15:17:13 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 7 Oct 2021 15:17:13 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <fPcqAv-yrmVaRqqFYNFUJ-WCmuWIpZ9tQm7LLVQotL4=.bfb44100-f8e1-46a9-9c18-536ddb2d82da@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
 <vDd2sF-tfPhDg2FXogNFYmHhDbvgoDWhHsd86MJfr48=.ccd82f7c-53eb-4971-936a-8520e14c3dd8@github.com>
 <fPcqAv-yrmVaRqqFYNFUJ-WCmuWIpZ9tQm7LLVQotL4=.bfb44100-f8e1-46a9-9c18-536ddb2d82da@github.com>
Message-ID: <c91EBC69jqQRwrrSrij8uN43JcBOeUa5lnwk65rAKx0=.b5d9263e-b7d9-4868-bb57-3e465ef67ee6@github.com>

On Thu, 7 Oct 2021 14:57:53 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make variables final
>
> test/jdk/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java line 38:
> 
>> 36:  * @library /test/lib ../
>> 37:  * @build jdk.test.lib.util.JarUtils
>> 38:  * @run main LowerCaseManifest
> 
> You don't need this line as this is the default @run setting.

Looks like it's required if there's a @build directive

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

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

From mullan at openjdk.java.net  Thu Oct  7 15:17:13 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 7 Oct 2021 15:17:13 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <c91EBC69jqQRwrrSrij8uN43JcBOeUa5lnwk65rAKx0=.b5d9263e-b7d9-4868-bb57-3e465ef67ee6@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
 <vDd2sF-tfPhDg2FXogNFYmHhDbvgoDWhHsd86MJfr48=.ccd82f7c-53eb-4971-936a-8520e14c3dd8@github.com>
 <fPcqAv-yrmVaRqqFYNFUJ-WCmuWIpZ9tQm7LLVQotL4=.bfb44100-f8e1-46a9-9c18-536ddb2d82da@github.com>
 <c91EBC69jqQRwrrSrij8uN43JcBOeUa5lnwk65rAKx0=.b5d9263e-b7d9-4868-bb57-3e465ef67ee6@github.com>
Message-ID: <juh7jrz_jeKozvKTWFNSr6JrAbHp_xmiUysU_l6iUHw=.b6072c7d-dce4-4923-a447-4a30668b20a3@github.com>

On Thu, 7 Oct 2021 15:09:22 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> test/jdk/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java line 38:
>> 
>>> 36:  * @library /test/lib ../
>>> 37:  * @build jdk.test.lib.util.JarUtils
>>> 38:  * @run main LowerCaseManifest
>> 
>> You don't need this line as this is the default @run setting.
>
> Looks like it's required if there's a @build directive

Ok.

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

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

From weijun at openjdk.java.net  Thu Oct  7 15:17:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 7 Oct 2021 15:17:13 GMT
Subject: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
In-Reply-To: <juh7jrz_jeKozvKTWFNSr6JrAbHp_xmiUysU_l6iUHw=.b6072c7d-dce4-4923-a447-4a30668b20a3@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
 <vDd2sF-tfPhDg2FXogNFYmHhDbvgoDWhHsd86MJfr48=.ccd82f7c-53eb-4971-936a-8520e14c3dd8@github.com>
 <fPcqAv-yrmVaRqqFYNFUJ-WCmuWIpZ9tQm7LLVQotL4=.bfb44100-f8e1-46a9-9c18-536ddb2d82da@github.com>
 <c91EBC69jqQRwrrSrij8uN43JcBOeUa5lnwk65rAKx0=.b5d9263e-b7d9-4868-bb57-3e465ef67ee6@github.com>
 <juh7jrz_jeKozvKTWFNSr6JrAbHp_xmiUysU_l6iUHw=.b6072c7d-dce4-4923-a447-4a30668b20a3@github.com>
Message-ID: <Vl8WOIPfqbvD-jiSRzSijPM7haqJ607B7EsJF2UrylY=.99741cdd-2453-4b0e-9a71-643e1e25b887@github.com>

On Thu, 7 Oct 2021 15:12:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Looks like it's required if there's a @build directive
>
> Ok.

It might be necessary because there is already a `@build` there.

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

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

From coffeys at openjdk.java.net  Thu Oct  7 15:17:15 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 7 Oct 2021 15:17:15 GMT
Subject: Integrated: 8273826: Correct Manifest file name and NPE checks
In-Reply-To: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
References: <F0pSu5YzLoMl9hcg0MAN_cGY9CMYJ5I9CcN7FTDiHaA=.0bf7ec63-c3dd-4d7e-83c6-aebc8b2fec03@github.com>
Message-ID: <Myr5Cft2VCTYpKc3MSwNvXnOFuDZQr6Msukqb59icLM=.2375b8c1-a7de-4691-8a8b-044fb7e2cecb@github.com>

On Wed, 6 Oct 2021 16:58:51 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Use correct manifest file name in the Manifest verifier checks. 
> Also - extra null check
> 
> The test doesn't reproduce the exact issue reported but should prevent future regressions in this area.

This pull request has now been integrated.

Changeset: 03a8d342
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03a8d342b86e720d3cba08d540182b4ab161fba3
Stats:     139 lines in 5 files changed: 128 ins; 2 del; 9 mod

8273826: Correct Manifest file name and NPE checks

Reviewed-by: weijun, hchao, mullan

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

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

From naoto at openjdk.java.net  Thu Oct  7 16:52:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Oct 2021 16:52:13 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

src/java.base/share/classes/java/lang/Character.java line 123:

> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
> 123:  * in the {@code String} and {@code StringBuilder} classes. In

Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.

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

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

From amaembo at gmail.com  Thu Oct  7 03:29:58 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 7 Oct 2021 10:29:58 +0700
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
 <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>
Message-ID: <CAE+3fjZfERs6k-ETuoO3t68f1yz46L0kC9prUSFSyeKz6cLjeA@mail.gmail.com>

On Thu, Oct 7, 2021 at 12:15 AM Joe Darcy <darcy at openjdk.java.net> wrote:

> Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis.

Yes, our analysis is written independently of Javac (mostly by Anna
Kozlova) and we had a long history of false-positives/false-negatives
in this inspection, so it was tuned many times. It's not nearly
simple. For now, it's turned on for the whole IntelliJ IDEA Ultimate
repository (a warning causes the CI build to fail). I've found only
five explicit suppressions in our codebase. Not sure if all of them
are still necessary.

>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5454

From github.com+18036229+chengjin01 at openjdk.java.net  Fri Oct  8 04:53:10 2021
From: github.com+18036229+chengjin01 at openjdk.java.net (Cheng Jin)
Date: Fri, 8 Oct 2021 04:53:10 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries
In-Reply-To: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
Message-ID: <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>

On Wed, 2 Jun 2021 20:13:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>> 
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added:
>> 
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified.
>> 
>> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set.
>
>> _Mailing list message from [Chapman Flack](mailto:chap at anastigmatix.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
>> 
>> On 06/02/21 13:30, Maurizio Cimadamore wrote:
>> 
>> > This patch replaces `LibraryLookup` with a simpler `SymbolLookup`
>> > abstraction, a functional interface. Crucially, `SymbolLookup` does not
>> > concern with library loading, only symbol lookup. For this reason, two
>> > factories are added:
>> 
>> Hi,
>> 
>> While I am thinking about this, what will be the behavior when the JVM
>> itself has been dynamically loaded into an embedding application, and
>> launched with the JNI invocation API?
>> 
>> Will there be a *Lookup flavor that is able to find any exported symbol
>> known in the embedding environment the JVM was loaded into? (This is the
>> sort of condition the Mac OS linker checks when given the -bundle_loader
>> option.)
>> 
>> Regards,
>> Chapman Flack (maintainer of a project that happens to work that way)
> 
> Hi,
> at the moment we don't have plans to add such a lookup, but I believe it should be possible to build such a lookup using `dlopen` and the linker API. I have provided an example elsewhere of how easy it easy to build a wrapper lookup around dlopen/dlsym:
> 
> https://gist.github.com/mcimadamore/0883ea6f4836ae0c1d2a31c48197da1a
> 
> Perhaps something like that could be useful in the use case you mention?

Hi @mcimadamore,

As you mentioned at https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system lookup is supported by the underlying `NativeLibraries` which also works on OpenJDK16 to support `LibraryLookup::ofDefault`.

But my finding is that it `LibraryLookup::ofDefault` works good on AIX (with `libc.a`) in OpenJDK16 but `CLinker.systemLookup()` ended up with  `NoSuchElementException` after changing the code in `SystemLookup.java` and `CABI.java` as follows:

    private static final SymbolLookup syslookup = switch (CABI.current()) {
        case SysV, LinuxAArch64, MacOsAArch64, AIX -> libLookup(libs -> libs.loadLibrary("syslookup"));
        case Win64 -> makeWindowsLookup(); // out of line to workaround javac crash
    };

with a simple test & output:

import jdk.incubator.foreign.CLinker;
import static jdk.incubator.foreign.CLinker.*;
import jdk.incubator.foreign.SymbolLookup;
import jdk.incubator.foreign.Addressable;

public class Test {
        private static CLinker clinker = CLinker.getInstance();
        private static final SymbolLookup defaultLibLookup = CLinker.systemLookup();

        public static void main(String args[]) throws Throwable {
                Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get();
        }
}

bin/java  --enable-native-access=ALL-UNNAMED  --add-modules jdk.incubator.foreign -Dforeign.restricted=permit Test
WARNING: Using incubator modules: jdk.incubator.foreign
Exception in thread "main" java.util.NoSuchElementException: No value present <-----
        at java.base/java.util.Optional.get(Optional.java:143)
        at Test.main(Test.java:11)


So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc).  Thanks.

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

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

From weijun at openjdk.java.net  Fri Oct  8 07:29:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 8 Oct 2021 07:29:27 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <2wrfMoUmLw_xar7QqdTGlx3lRRn5ezXWZI3F6MIJoVo=.9e0d608d-6cf2-47ad-ae11-134f5d77bffe@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

security-related change looks fine.

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

Marked as reviewed by weijun (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 07:29:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 07:29:27 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in
 java.base
Message-ID: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>

String.contains was introduced in Java 5.
Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
I propose to migrate such usages. Makes code shorter and easier to read.

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

Commit messages:
 - [PATCH] Use String.contains() instead of String.indexOf() in java.base
 - [PATCH] Use String.contains() instead of String.indexOf() in java.base

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

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

From dfuchs at openjdk.java.net  Fri Oct  8 09:38:04 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Oct 2021 09:38:04 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Changes to java.net look OK. Did you run tier1, tier2?

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

Marked as reviewed by dfuchs (Reviewer).

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

From vtewari at openjdk.java.net  Fri Oct  8 10:15:07 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 8 Oct 2021 10:15:07 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <IK_jmGQWQ0HohqSRE-kTgY-Xcjab4WNHUbkO3ITkDp4=.2c7d07c2-150b-4752-a429-f81da53621cb@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

java.net changes look OK to me.

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

Marked as reviewed by vtewari (Committer).

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

From lancea at openjdk.java.net  Fri Oct  8 10:20:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 8 Oct 2021 10:20:09 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <w0KXXui1E0dtoghdpDHBut8BcBEesJdxM8-0O-DvEB4=.0ff06e02-50e2-4eb8-baa3-53d80db03e27@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Marked as reviewed by lancea (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 14:01:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 14:01:10 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
 <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>
Message-ID: <w_TDnyfEJSM2qLXD2W0TGC5jlTDA1UFo3fyR2gySq5U=.b26a16ce-69f8-44b7-b1d8-069fd7c1ce31@github.com>

On Fri, 8 Oct 2021 09:35:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>Did you run tier1, tier2?

I did run tier2. (tier1 is automatically checked by GithubActions).
No new tests failed. Only _usual_ tests, which always fail on my machine, were failed.

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

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

From mcimadamore at openjdk.java.net  Fri Oct  8 21:32:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 8 Oct 2021 21:32:12 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries
In-Reply-To: <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
 <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>
Message-ID: <kcW8bZe4gTmKlL4QkjeoRJX6awRdF0BVleHcj9XzlNA=.a4bfd5f2-67e3-45a0-bf3e-d98ffc3a50cd@github.com>

On Fri, 8 Oct 2021 04:43:08 GMT, Cheng Jin <github.com+18036229+ChengJin01 at openjdk.org> wrote:

> So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc). Thanks.

In 17, SystemLookup loads a specific library that is generated at build time - which contains all the c stdlib symbols. That's what the Lib.gmk changes are for. What I suspect is that the library is not generated at all, or not correctly on AIX, which then causes the system lookup to misbehave.

I would start by double checking that you have a file like this:

<JDK_ROOT>/lib/libsyslookup.so

And then, if the library exists, check that it has the right dependency; on my linux it's an empty library, but which depends on libc, libm and libdl:


ldd lib/libsyslookup.so  
	linux-vdso.so.1 (0x00007fff2bdf7000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35f1def000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f35f1ca0000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35f1c9a000)

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

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

From github.com+18036229+chengjin01 at openjdk.java.net  Fri Oct  8 21:49:10 2021
From: github.com+18036229+chengjin01 at openjdk.java.net (Cheng Jin)
Date: Fri, 8 Oct 2021 21:49:10 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries
In-Reply-To: <kcW8bZe4gTmKlL4QkjeoRJX6awRdF0BVleHcj9XzlNA=.a4bfd5f2-67e3-45a0-bf3e-d98ffc3a50cd@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
 <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>
 <kcW8bZe4gTmKlL4QkjeoRJX6awRdF0BVleHcj9XzlNA=.a4bfd5f2-67e3-45a0-bf3e-d98ffc3a50cd@github.com>
Message-ID: <v22GPlok5sqaB0OAYqw2xACrT8vWhlz-D5xov_GYQDo=.fb7c87f4-cde7-4d2a-9cf3-13530d27a874@github.com>

On Fri, 8 Oct 2021 21:29:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi @mcimadamore,
>> 
>> As you mentioned at https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system lookup is supported by the underlying `NativeLibraries` which also works on OpenJDK16 to support `LibraryLookup::ofDefault`.
>> 
>> But my finding is that it `LibraryLookup::ofDefault` works good on AIX (with `libc.a`) in OpenJDK16 but `CLinker.systemLookup()` ended up with  `NoSuchElementException` after changing the code in `SystemLookup.java` and `CABI.java` as follows:
>> 
>>     private static final SymbolLookup syslookup = switch (CABI.current()) {
>>         case SysV, LinuxAArch64, MacOsAArch64, AIX -> libLookup(libs -> libs.loadLibrary("syslookup"));
>>         case Win64 -> makeWindowsLookup(); // out of line to workaround javac crash
>>     };
>> 
>> with a simple test & output:
>> 
>> import jdk.incubator.foreign.CLinker;
>> import static jdk.incubator.foreign.CLinker.*;
>> import jdk.incubator.foreign.SymbolLookup;
>> import jdk.incubator.foreign.Addressable;
>> 
>> public class Test {
>>         private static CLinker clinker = CLinker.getInstance();
>>         private static final SymbolLookup defaultLibLookup = CLinker.systemLookup();
>> 
>>         public static void main(String args[]) throws Throwable {
>>                 Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get();
>>         }
>> }
>> 
>> bin/java  --enable-native-access=ALL-UNNAMED  --add-modules jdk.incubator.foreign -Dforeign.restricted=permit Test
>> WARNING: Using incubator modules: jdk.incubator.foreign
>> Exception in thread "main" java.util.NoSuchElementException: No value present <-----
>>         at java.base/java.util.Optional.get(Optional.java:143)
>>         at Test.main(Test.java:11)
>> 
>> 
>> So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc).  Thanks.
>
>> So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc). Thanks.
> 
> In 17, SystemLookup loads a specific library that is generated at build time - which contains all the c stdlib symbols. That's what the Lib.gmk changes are for. What I suspect is that the library is not generated at all, or not correctly on AIX, which then causes the system lookup to misbehave.
> 
> I would start by double checking that you have a file like this:
> 
> <JDK_ROOT>/lib/libsyslookup.so
> 
> And then, if the library exists, check that it has the right dependency; on my linux it's an empty library, but which depends on libc, libm and libdl:
> 
> 
> ldd lib/libsyslookup.so  
> 	linux-vdso.so.1 (0x00007fff2bdf7000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35f1def000)
> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f35f1ca0000)
> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35f1c9a000)

Hi @mcimadamore,

Here's output of `libsyslookup.so` on AIX:

$ ldd  ./lib/libsyslookup.so
./lib/libsyslookup.so needs:  <--- nothing here

$ whereis libc
libc: /usr/lib/libc.a /usr/lib/libc128.a /usr/ccs/lib/libc.a

So it is high likely that there were no dependencies in this generated library.

> perhaps on AIX something similar to what we did for Windows [1] would be better.

That's what I thought to be the only way around but might need to figure out the specifics on AIX.

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

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

From github.com+6776231+talden at openjdk.java.net  Sat Oct  9 03:19:09 2021
From: github.com+6776231+talden at openjdk.java.net (Talden)
Date: Sat, 9 Oct 2021 03:19:09 GMT
Subject: RFR: 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: <lfLOA91bDU_sDxofXBYaZYFvou6nQmFs34MpE8t9_aA=.2d8f4c4f-7e58-45ad-9c48-3ddf23fb82e9@github.com>

On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov <github.com+741251+turbanoff 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

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

> 4133:                 if (date != null) {
> 4134:                     if (date.matches("\\d\\d\\d\\d\\/\\d\\d\\/\\d\\d")) {
> 4135:                         c.set(Integer.parseInt(date.substring(0, 4)),

Could this, and several of the other cases identified in this PR, be replaced with a call to the `Integer.parseInt(CharSequence, int, int, int)` method to also avoid the String allocation?

Though there are enough other places in the JDK where this opportunity seems valuable that maybe it warrants a tracking issue of its own.

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

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

From darcy at openjdk.java.net  Sat Oct  9 19:51:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 9 Oct 2021 19:51:18 GMT
Subject: RFR: 8275003: Suppress warnings on non-serializable non-transient
 instance fields in windows mscapi
Message-ID: <eIHieUl8AW6VJlGr6UTukOsLJAny4myd752iz2ghIrU=.d89917cc-7678-4e82-8384-c3e41f994354@github.com>

Analogous to other recent cleanups like JDK-8274393, suppress warnings for serialization-related issues in the windows mscapi code.

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

Commit messages:
 - Applease jcheck.
 - 8275003: Suppress warnings on non-serializable non-transient instance fields in windows mscapi

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

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

From kustos at gmx.net  Sun Oct 10 17:09:20 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Sun, 10 Oct 2021 19:09:20 +0200
Subject: Different way to solve 8241047
In-Reply-To: <09c69566-b8ea-9101-ff07-570922098a3e@oracle.com>
References: <f14c2150-0130-baad-187a-3a08e4397e51@gmx.net>
 <09c69566-b8ea-9101-ff07-570922098a3e@oracle.com>
Message-ID: <076bbb59-39f2-6e5c-9373-ac18b48cca16@gmx.net>



On 05.10.21 16:27, Sean Mullan wrote:
> Hi Philippe,
>
> ...
>
> The method in question has not been removed from 17 so their code should
> continue to work as long as the deprecated methods continue to be
> overridden. It's unfortunate that the 3rd party library cannot be
> changed - is it active?

It's the client library of a widely deployed middleware from a well
known vendor. The client library does not implement SSLSession but ends
up calling #getPeerCertificateChain through the default socket factory.

Sometimes it would be fun to to back to uni and write a software that
scans the whole of Maven Central for callers of particular methods.

> The SSLSession.getPeerCertificateChain() has
> been deprecated since Java 9 and marked for removal since Java 13, and
> there has been a replacement API available
> SSLSession.getPeerCertificates() since Java 1.4. That's a lot of time to
> migrate.

It wasn't enough time for this particular vendor.

> ...
>
> It is an interesting suggestion and I can see your point. I don't think
> there is any fundamental reason we could not change the default
> implementation of the SSLSession.getPeerCertificateChain() method, but
> since it would be a change to the specification, it could not be
> backported to 17.

That's more or less what I expected but I thought I had to ask. I think
we should be able to work around it by making the client library use a
custom socket factory.

> Also, these methods are marked for removal, so
> changing the default implementation at this point probably doesn't add
> much value.

It would allow people who rely on third party dependencies that call
#getPeerCertificateChain to migrate to JDK 21, assuming it won't be
removed until then. If the types and package are removed by JDK 21 then
indeed it wouldn't add much value.

Cheers
Philippe

From cancomert at gmail.com  Mon Oct 11 11:58:28 2021
From: cancomert at gmail.com (can comert)
Date: Mon, 11 Oct 2021 13:58:28 +0200
Subject: JDK-8274471/Incident Report 9166550 : Verification of OCSP
 Response signed with RSASSA-PSS fails
In-Reply-To: <DM5PR1001MB23630E2044FF02C9C6886E23CEB49@DM5PR1001MB2363.namprd10.prod.outlook.com>
References: <DM5PR1001MB23630E2044FF02C9C6886E23CEB49@DM5PR1001MB2363.namprd10.prod.outlook.com>
Message-ID: <CAPnQxbam9K4d8RCVc0hvEo=JmAw8OUMXoxONms4CyCzopdzbAw@mail.gmail.com>

Hello Andrew,

Yes I tested it and I can verify that it works with Java 18 JDK as expected.
Thank you very much for your effort.
Here is the output of my example program with debug flags enabled:

C:\work\java\jdk-18\bin\java.exe -Djava.security.auth.debug=certpath,ocsp
start program
...
certpath: Verified signature of OCSP Response
certpath: OCSP response validity interval is from Mon Oct 11 13:49:56 CEST
2021 until Mon Oct 11 14:49:56 CEST 2021
certpath: Checking validity of OCSP response on Mon Oct 11 13:49:56 CEST
2021 with allowed interval between Mon Oct 11 13:34:56 CEST 2021 and Mon
Oct 11 14:04:56 CEST 2021
certpath: -checker7 validation succeeded
certpath:
cert1 validation succeeded.
certpath: Cert path validation succeeded. (PKIX validation algorithm)
certpath: --------------------------------------------------------------
...
success
end program

Best regards,
Can

Andrew Wang <tong-kai.wang at oracle.com>, 10 Eki 2021 Paz, 08:27 tarihinde
?unu yazd?:

> Hi Mehmet,
>
>
>
> We have fixed the issue.  Can you kindly verify the fix by downloading the
> latest version of JDK 18 from https://jdk.java.net/18/ and let us know
> the results?
>
>
>
> Thanks and regards,
>
>
>
> Andrew
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211011/367effe6/attachment.htm>

From cancomert at gmail.com  Mon Oct 11 15:35:14 2021
From: cancomert at gmail.com (can comert)
Date: Mon, 11 Oct 2021 17:35:14 +0200
Subject: Integrated: 8274471: Verification of OCSP Response signed with
 RSASSA-PSS fails
In-Reply-To: <FD037ADF-40C6-49E8-B71B-E57F16C8686C@oracle.com>
References: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@github.com>
 <5_DfeMsAEWMWC8OC1I0K3f17Fbos6D2q2dEYZmZz8hA=.3c2f2516-2130-4efc-a5b2-5ac530051b5a@github.com>
 <CAPnQxbbw1gYFE_xt1wQBWM8Y1QSeG+me5qAGR=EKDUSz0ey1qg@mail.gmail.com>
 <FD037ADF-40C6-49E8-B71B-E57F16C8686C@oracle.com>
Message-ID: <CAPnQxbakPVndXuVw4PfwDdAFkLM2z8w=pEjOUfyOwPSWxAV59Q@mail.gmail.com>

Thank you very much!

Regards,
Can

Wei-Jun Wang <weijun.wang at oracle.com>, 5 Eki 2021 Sal, 22:05 tarihinde ?unu
yazd?:

> I think it's worth backporting to older LTS releases. Will ask sustaining
> on it.
>
> Thanks,
> Weijun
>
> > On Oct 5, 2021, at 2:36 PM, can comert <cancomert at gmail.com> wrote:
> >
> >
> > Is there any backporting for a LTS version planned?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211011/1d94eabb/attachment.htm>

From duke at openjdk.java.net  Mon Oct 11 20:47:14 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 20:47:14 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in java.net.http
Message-ID: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>

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

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

Commit messages:
 - 8275079: Remove unnecessary conversion to String in java.net.http
 - [PATCH] Remove unnecessary conversion to String

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

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

From weijun at openjdk.java.net  Mon Oct 11 20:47:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 11 Oct 2021 20:47:14 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
Message-ID: <87fb8y4-vNQNzTfuT7k29GdH0VHrOQsJEoCvec5TpCk=.d4dce725-fbd0-4661-b560-e3e90d251c4f@github.com>

On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

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

Some small comments.

src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 738:

> 736:             if (flowTag != null) {
> 737:                 dbgTag = tag = "Http1AsyncReceiver("+ flowTag + ")";
> 738:             } else {

If the only use of `flowTag` is `flow` in string, it looks like `flow` is enough. i.e.


if (flow != null) {
    dbgTag = tag = "Http1AsyncReceiver("+ flow + ")";
}

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 831:

> 829:         @Override
> 830:         public String toString() {
> 831:             return super.toString() + "/parser=" + parser;

Can we use `super` instead of `super.toString()`?

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

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

From duke at openjdk.java.net  Mon Oct 11 20:47:15 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 20:47:15 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <87fb8y4-vNQNzTfuT7k29GdH0VHrOQsJEoCvec5TpCk=.d4dce725-fbd0-4661-b560-e3e90d251c4f@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
 <87fb8y4-vNQNzTfuT7k29GdH0VHrOQsJEoCvec5TpCk=.d4dce725-fbd0-4661-b560-e3e90d251c4f@github.com>
Message-ID: <ZqH3n14HyD2YZrm3ybrPDseFPRZ19oE5pwx1rXOR07k=.7050978e-1b99-4a4b-b895-371c4ca6c132@github.com>

On Mon, 4 Oct 2021 13:39:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 738:
> 
>> 736:             if (flowTag != null) {
>> 737:                 dbgTag = tag = "Http1AsyncReceiver("+ flowTag + ")";
>> 738:             } else {
> 
> If the only use of `flowTag` is `flow` in string, it looks like `flow` is enough. i.e.
> 
> 
> if (flow != null) {
>     dbgTag = tag = "Http1AsyncReceiver("+ flow + ")";
> }

Good idea. Improved.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 831:
> 
>> 829:         @Override
>> 830:         public String toString() {
>> 831:             return super.toString() + "/parser=" + parser;
> 
> Can we use `super` instead of `super.toString()`?

Nope. `super` is not a valid java expression.

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

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

From duke at openjdk.java.net  Mon Oct 11 21:08:49 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 21:08:49 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes
In-Reply-To: <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
Message-ID: <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>

On Thu, 7 Oct 2021 16:48:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.
>
> src/java.base/share/classes/java/lang/Character.java line 123:
> 
>> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
> 
> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.

reverted changes in this spec.

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

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

From valeriep at openjdk.java.net  Mon Oct 11 23:32:26 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 11 Oct 2021 23:32:26 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider [v2]
In-Reply-To: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
Message-ID: <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>

> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
> 
> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
> 
> The rest are minor code refactoring and updates for the PKCS11 Exception class.
> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
> 
> Thanks,
> Valerie

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

  Minor update for review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5569/files
  - new: https://git.openjdk.java.net/jdk/pull/5569/files/4268589e..a79c2fd0

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

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

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

From ascarpino at openjdk.java.net  Tue Oct 12 03:56:49 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 12 Oct 2021 03:56:49 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider [v2]
In-Reply-To: <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>
Message-ID: <-XqxxpPEkebnEhmbGjdbmYbEk8ht-0O0jcblQdS3L8s=.fb61af05-aadd-4445-8ab9-9de3fea202f8@github.com>

On Mon, 11 Oct 2021 23:32:26 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update for review comments.

The changes look good

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

Marked as reviewed by ascarpino (Reviewer).

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

From serb at openjdk.java.net  Tue Oct 12 07:10:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 07:10:48 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
Message-ID: <AygLHuLKyHmMPVhiXXWNEhGgSOqezXqwtrpxoC6fvsE=.5cc824e8-ab5a-40d9-8f32-5146e5a4c45d@github.com>

On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by serb (Reviewer).

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

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

From dfuchs at openjdk.java.net  Tue Oct 12 11:07:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 12 Oct 2021 11:07:52 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
Message-ID: <5FSqzpEvZGf9ySa94vZxYUWWMUmzXNovK-IH_FAgYwY=.fe97f522-7a64-46a4-a673-bdf6378d8052@github.com>

On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

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

LGTM

Hi Andrey - I will sponsor this change.

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

Marked as reviewed by dfuchs (Reviewer).

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

From mcimadamore at openjdk.java.net  Tue Oct 12 15:07:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Oct 2021 15:07:55 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries
In-Reply-To: <v22GPlok5sqaB0OAYqw2xACrT8vWhlz-D5xov_GYQDo=.fb7c87f4-cde7-4d2a-9cf3-13530d27a874@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
 <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>
 <kcW8bZe4gTmKlL4QkjeoRJX6awRdF0BVleHcj9XzlNA=.a4bfd5f2-67e3-45a0-bf3e-d98ffc3a50cd@github.com>
 <v22GPlok5sqaB0OAYqw2xACrT8vWhlz-D5xov_GYQDo=.fb7c87f4-cde7-4d2a-9cf3-13530d27a874@github.com>
Message-ID: <RUTCPJ2dvaLtXOrYRvBqj7i1WC92klxCALPLkwuKvoc=.65cca1cd-b2b4-4f18-90fd-5af66c28393b@github.com>

On Fri, 8 Oct 2021 21:45:21 GMT, Cheng Jin <duke at openjdk.java.net> wrote:

> That's what I thought to be the only way around but might need to figure out the specifics on AIX.

Is `libc.a` loadable on AIX (e.g. with System.loadLibrary) ? (Sorry I don't have a machine to test readily available). If so, we might just load `libc` and `libm` and drop the shim library generation on AIX.

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

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

From duke at openjdk.java.net  Tue Oct 12 15:27:55 2021
From: duke at openjdk.java.net (Cheng Jin)
Date: Tue, 12 Oct 2021 15:27:55 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries
In-Reply-To: <RUTCPJ2dvaLtXOrYRvBqj7i1WC92klxCALPLkwuKvoc=.65cca1cd-b2b4-4f18-90fd-5af66c28393b@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
 <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>
 <kcW8bZe4gTmKlL4QkjeoRJX6awRdF0BVleHcj9XzlNA=.a4bfd5f2-67e3-45a0-bf3e-d98ffc3a50cd@github.com>
 <v22GPlok5sqaB0OAYqw2xACrT8vWhlz-D5xov_GYQDo=.fb7c87f4-cde7-4d2a-9cf3-13530d27a874@github.com>
 <RUTCPJ2dvaLtXOrYRvBqj7i1WC92klxCALPLkwuKvoc=.65cca1cd-b2b4-4f18-90fd-5af66c28393b@github.com>
Message-ID: <wILsCBaJJ0NftF4Tf9SFNbWp_nzsBDng74xw-o3J3F0=.1b58a749-87c6-4485-94b2-ddeb8c95b698@github.com>

On Tue, 12 Oct 2021 15:04:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Is libc.a loadable on AIX (e.g. with System.loadLibrary) ?

I tried to load `libc.a` and `libc` this way but neither of them works on AIX.
e.g.

public class StdLibTest {
        private static CLinker clinker = CLinker.getInstance();
        static {
                System.loadLibrary("libc.a"); <-----
        }
        private static final SymbolLookup defaultLibLookup = SymbolLookup.loaderLookup();

        public static void main(String args[]) throws Throwable {
                Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get();
        }
}

$ ./bin/java  --enable-native-access=ALL-UNNAMED  --add-modules jdk.incubator.foreign 
-Dforeign.restricted=permit --enable-native-access=ALL-UNNAMED  StdLibTest
WARNING: Using incubator modules: jdk.incubator.foreign
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load libc.a <-------
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822)
        at java.base/java.lang.System.loadLibrary(System.java:694)
        at StdLibTest.<clinit>(StdLibTest.java:23)

and 

public class StdLibTest {
        private static CLinker clinker = CLinker.getInstance();
        static {
                System.loadLibrary("libc"); <-------
        }
        private static final SymbolLookup defaultLibLookup = SymbolLookup.loaderLookup();

        public static void main(String args[]) throws Throwable {
                Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get();
        }
}

$ ./bin/java  --enable-native-access=ALL-UNNAMED  --add-modules jdk.incubator.foreign
-Dforeign.restricted=permit --enable-native-access=ALL-UNNAMED  StdLibTest
WARNING: Using incubator modules: jdk.incubator.foreign
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load libc <------
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822)
        at java.base/java.lang.System.loadLibrary(System.java:694)
        at StdLibTest.<clinit>(StdLibTest.java:23)

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

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

From aefimov at openjdk.java.net  Tue Oct 12 15:43:24 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 12 Oct 2021 15:43:24 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

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

 - Add @since tags to new API classes
 - Add checks and test for empty stream resolver results

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/41717fc7..d302a49a

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

  Stats: 150 lines in 6 files changed: 146 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

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

From mcimadamore at openjdk.java.net  Tue Oct 12 16:37:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Oct 2021 16:37:57 GMT
Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator)
Message-ID: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>

This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.

[1] - https://openjdk.java.net/jeps/419

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

Commit messages:
 - Fix issues with Aarch64 VaList implementation
 - Drop argument type profiling for removed `MemoryAccess` class
 - Add missing files
 - Tweak javadoc for MemeorySegment/MemoryAddress::setUtf8String
 - Initial push from panama/foreign

Changes: https://git.openjdk.java.net/jdk/pull/5907/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275063
  Stats: 14262 lines in 186 files changed: 6583 ins; 5144 del; 2535 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

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

From mcimadamore at openjdk.java.net  Tue Oct 12 16:37:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Oct 2021 16:37:57 GMT
Subject: RFR: 8275063: Implementation of Memory Access API (Second
 incubator)
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <-PiXRcdXSgem16bbZeDqOiJpOJu7FT_FaB8nFYHoGig=.91ba78cb-66d9-4ed3-82e9-184ab4b2616c@github.com>

On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

This PR contains mainly API changes. We have tried to simplify the API, by removing redundant classes and moving functionalities where they belong. Below we list the main changes introduced in this PR. A big thanks to all who helped along the way: @briangoetz, @ChrisHegarty, @FrauBoes, @iwanowww, @JornVernee, @PaulSandoz, @sundararajana and @rose00.

### Value layouts and carriers

This is perhaps the biggest change in the API, which has a knock-on effect in other areas as well. In the past, a value layout used to be a fairly *neutral* description of a piece of memory containing a scalar value. A value layout has a size, alignment and endianness. Since a value layout contains no information on *how* the value is to be dereferenced by Java clients, said clients have to specify a *carrier* when obtaining a var handle from a value layout.

In this iteration, we have decided to attach carrier types to value layouts - so, in addition to size, alignment and endianness, all value layouts now have a `carrier` accessor, which returns a `j.l.Class`. You will find several hand-specialized version of `ValueLayout`, one for each main carrier type (e.g. `ValueLayout.OfInt` for the `int` carrier).

Attaching carrier information to layouts simplifies the API in many ways:

* When obtaining a var handle from a layout, it is no longer necessary to provide a carrier; the layout in fact contains all the necessary information for the dereference operation to occur.
* Similarly, when linking downcall method handles, the `MethodType` parameter is no longer necessary, as now carrier information can be inferred from the provided `FunctionDescriptor`.
* We can express dereference operations in a more general fashion - e.g. `get(ValueLayout.OfInt)` instead of `getInt(ByteOrder)`. Note how the new form is more *complete*.

This iteration also adds support for `boolean` and `MemoryAddress` carriers in memory access var handles.

### Layout attributes

To help the `CLinker` distinguish between a 32-bit layout modelling to a C `int` and a similar layout modelling a C `float` we have in the past resorted to *layout attributes* - that is, we injected custom classification information in layouts, and then required clients working with the `CLinker` API to only work with such augmented layouts.

Because of the changes described above, this is no longer necessary: a layout is always associated with a Java carrier, so the `CLinker` can always disambiguate between `ValueLayout.OfInt` and `ValueLayout.OfFloat` even though they have the same size. For this reason, API support for custom layout attributes has been dropped in this iteration.

Similarly, platform-dependent layout constants in `CLinker` have been removed; clients interacting with the foreign linker can simply use the basic layout constants defined in `ValueLayout` (e.g. `JAVA_INT`, `JAVA_FLOAT`, ...) - which is not too different from using the JNI types `jint` and `jfloat`. Of course tools (such as `jextract`) are free to define *custom* layouts which model C type for a specific platform.

### Memory dereference

Previous iterations of the API provided ready-made dereference operations as static methods in the `MemoryAccess` class. This class is now removed, and all the dereference operations have been moved to `MemorySegment` and `MemoryAddress`. As mentioned before, the new dereference operations have a new form. Instead of:


MemorySegment segment = ...
MemoryAccess.getIntAtOffset(segment, /*offset */ 100, /* endianness */ ByteOrder.nativeOrder());


The new API works as follows:


MemorySegment segment = ...
int val  = segment.get(JAVA_INT, /*offset */ 100);

Note that the new dereference method is not static, and that parameters such as endianness are now omitted, since clients can just specify the value layout they want to work with. Also, since the new dereference methods are not static, we no longer need the workaround to enable VM argument type profiling (this was necessary to make static methods in `MemoryAccess` class perform reasonably well in the face of profile pollution). 

The same dereference operations are also available in `MemoryAddress`; when working with native code it might be necessary to dereference a raw pointer. In Java 17, to write a basic comparator function for qsort, the following code is needed:


static int qsortCompare(MemoryAddress addr1, MemoryAddress addr2) {
             return MemoryAccess.getIntAtOffset(MemorySegment.globalNativeSegment(), addr1.toRawLongValue()) -
                       MemoryAccess.getIntAtOffset(MemorySegment.globalNativeSegment(), addr2.toRawLongValue());

With the proposed changes, the above code simplifies to:

static int qsortCompare(MemoryAddress addr1, MemoryAddress addr2) {
    return addr1.get(C_INT, 0) - addr2.get(C_INT, 0);
}

Which is far more readable. Note that dereferencing a memory address is still a potentially unsafe operation, as an address has no spatia/temporall bounds. For this reason, dereference operation on `MemoryAddress` are marked as *restricted*.

### Memory copy

This iteration adds more support for copying Java arrays to and from memory segments. In Java 17, it is possible to copy a Java array into a memory segment, as follows:


int[] array = ....
MemorySegment segment = ...
MemorySegment heapView = MemorySegment.ofArray(array);
segment.asSlice(startSegmentOffset, nelems * 4)
              .copyFrom(heapView.asSlice(startArrayOffset * 4, nelems * 4))


This code snippet is suboptimal for several reasons:

* three temporary segments have to be created: the heap view, plus the two slices
* note how the code has to carefully slice the source/target segment to make sure that only the desired elements are copied, and at the desired target offset in the segment.
* offset in arrays is expressed in elements, whereas offset in segments is expressed in bytes - which calls for potential mistakes.
* it is not possible to specify custom endianness/alignment for the copy operation

With the changes in this PR, the above code becomes:


int[] array = ....
MemorySegment segment = ...
MemorySegment.copy(array, startArrayOffset, segment, JAVA_INT, startSegmentOffset, nelems);


The above code is much simpler, with less potential for mistakes. Also, the extra value layout allows client to inject additional alignment constraints and endianness (if required).

### Role of `MemoryAddress`

In Java 17, `MemoryAddress` has a scope accessor. This is useful when reasoning about an address obtained from a memory segment, but is far less useful when thinking about an address received from a native call. While it is possible to model the latter as an address associated with the *global scope*, `MemoryAddress` supports several operations which allow clients to attach spatial and temporal bounds to an address, turning it into a `MemorySegment`. If the address already has a scope, the semantics of some of these operation becomes confusing.

For this reason, in this iteration `MemoryAddress` is only used to model raw native addresses. There is no scope associated with a memory address - dereferencing a raw address is always unsafe. This change brings more clarity to API, as `MemoryAddress` is nothing but a simple wrapper around a `long` value. This also means that obtaining a `MemoryAddress` from a heap segment is no longer a possibility; in other words, clients that don't care about native interop should probably just use `MemorySegment` and forget about `MemoryAddress`.

### Downcall method handle safety

In Java 17, by-reference parameters to downcall method handles are passed as `MemoryAddress` arguments. This means that e.g. passing a segment by-reference requires a conversion (from segment to memory address, using `MemorySegment::address`). This conversion is lossy, as we lose information about the original memory segment (spatial and temporal bounds). As a result, passing parameter by-reference to downcall method handle is less safe.

The changes described in this PR introduce stronger safety guarantees for by-reference parameters. The `CLinker` will now map any such parameter to the `Addressable` type - a common super interface of all things that can be passed by reference. This means clients can pass a memory segment *directly* to a downcall method handle, no conversion required. Because of that, the `CLinker` runtime can make sure that e.g. arguments passed by reference are kept alive for the entire duration of the native call.

### Native symbols

In Java 17, looking up a symbol on a native library is done using the `SymbolLookup` interface. This interface used to return a plain `MemoryAddress` (the address of the native function). Given the changes described above, `MemoryAddress` is no longer a great choice:

* a `MemoryAddress` now models a raw native memory address, and has no scope
* a `MemoryAddress` can be easily dereferenced* 

For this reason, a new abstraction is added, namely `NativeSymbol`, which is used to model the entry point of a symbol (a function or a global variable) in a native library. A native symbol is `Addressable`, has a name and a resource scope. Since native symbols have a scope, the `CLinker` runtime can make sure that the scope of the native symbol corresponding to the native function being executed cannot be closed prematurely. This effectively allows clients to support safe library loading abstractions which support [deterministic library unloading](https://github.com/sundararajana/panama-jextract-samples/blob/master/dlopen/Dlopen.java).

Additionally, we have tweaked the `CLinker::upcallStub` method to also return an *anonymous* `NativeSymbol`, rather than a raw `MemoryAddress`.

### Resource scope tweaks

This PR removes the distinction between *implicit* and *explicit* scopes. Now all scopes (except for the *global scope*) are closeable, and can be associated with a `Cleaner`, if required.

Another change in the resource scope API is in how temporal scope dependencies are handled. In Java 17 scopes could be acquired and released:


MemorySegment segment = ...
ResourceScope.Handle segmentHandle = segment.scope().acquire();
try {
   <critical operation on segment>
} finally {
   segment.scope().release(segmentHandle);
}

This PR removes the `ResourceScope::acquire` and `ResourceScope::release` methods, and allows instead to capture dependencies between scopes in a more explicit fashion:


MemorySegment segment = ...
try (ResourceScope criticalScope = ResourceScope.newConfinedScope()) {
    criticalScope.keepAlive(segment.scope());
    <critical operation on segment>
}

API javadoc:
http://cr.openjdk.java.net/~mcimadamore/8275064/javadoc/jdk/incubator/foreign/package-summary.html

Specdiff:
http://cr.openjdk.java.net/~mcimadamore/8275064/specdiff_out/overview-summary.html

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

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

From erikj at openjdk.java.net  Tue Oct 12 17:03:52 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 12 Oct 2021 17:03:52 GMT
Subject: RFR: 8275063: Implementation of Memory Access API (Second
 incubator)
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <JbQkK3F-eLg3mQKc4kZTZUVPwEVqGn_m7Eqtoynoj7o=.7cfd42e5-eeed-4dce-b1f6-c14ef80fecf7@github.com>

On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From fguallini at openjdk.java.net  Tue Oct 12 17:12:09 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Tue, 12 Oct 2021 17:12:09 GMT
Subject: RFR: 8272908: Missing coverage for certain classes in
 com.sun.org.apache.xml.internal.security
Message-ID: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>

This patch improves code coverage on the following classes:
- com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac
- com.sun.org.apache.xml.internal.security.utils.ElementProxy
- com.sun.org.apache.xml.internal.security.keys.KeyInfo

The new tests exercise code blocks that are not currently covered by other tests.

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

Commit messages:
 - add code coverage to KeyInfo and IntegrityHmac

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

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

From mcimadamore at openjdk.java.net  Tue Oct 12 17:30:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Oct 2021 17:30:53 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries
In-Reply-To: <wILsCBaJJ0NftF4Tf9SFNbWp_nzsBDng74xw-o3J3F0=.1b58a749-87c6-4485-94b2-ddeb8c95b698@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com>
 <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com>
 <kcW8bZe4gTmKlL4QkjeoRJX6awRdF0BVleHcj9XzlNA=.a4bfd5f2-67e3-45a0-bf3e-d98ffc3a50cd@github.com>
 <v22GPlok5sqaB0OAYqw2xACrT8vWhlz-D5xov_GYQDo=.fb7c87f4-cde7-4d2a-9cf3-13530d27a874@github.com>
 <RUTCPJ2dvaLtXOrYRvBqj7i1WC92klxCALPLkwuKvoc=.65cca1cd-b2b4-4f18-90fd-5af66c28393b@github.com>
 <wILsCBaJJ0NftF4Tf9SFNbWp_nzsBDng74xw-o3J3F0=.1b58a749-87c6-4485-94b2-ddeb8c95b698@github.com>
Message-ID: <IkgUvXWNcx6mputMRMj0QSJm6fhs3QYckDcG63c6uqU=.db0333a7-81c8-43d7-810c-623835706054@github.com>

On Tue, 12 Oct 2021 15:24:41 GMT, Cheng Jin <duke at openjdk.java.net> wrote:

> I tried to load `libc.a` and `libc` this way but neither of them works on AIX.

Sorry - what I meant is - `System::load`, which accepts a full path and extension. E.g.


System.load("/usr/lib/libc.a");

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

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

From duke at openjdk.java.net  Tue Oct 12 18:14:54 2021
From: duke at openjdk.java.net (Cheng Jin)
Date: Tue, 12 Oct 2021 18:14:54 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries [v7]
In-Reply-To: <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
Message-ID: <vvUlcl5LY6dbSjF_AEi7eKK-vWBvpv4WAXmzyw6khPU=.ff75165a-74f4-4219-9093-df6f10543edc@github.com>

On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>> 
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added:
>> 
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified.
>> 
>> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments on shim lib makefile

Just tried with `System.load()` but still ended up with pretty much the same failure given both of them eventually invokes `ClassLoader.loadLibrary` to load the library in which case there is no big difference at this point.

        static {
                System.load("/usr/lib/libc.a");
        }

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load /usr/lib/libc.a <----
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1793)
        at java.base/java.lang.System.load(System.java:672)
        at StdLibTest.<clinit>(StdLibTest.java:24)

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

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

From valeriep at openjdk.java.net  Tue Oct 12 19:06:47 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 12 Oct 2021 19:06:47 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider [v2]
In-Reply-To: <-XqxxpPEkebnEhmbGjdbmYbEk8ht-0O0jcblQdS3L8s=.fb61af05-aadd-4445-8ab9-9de3fea202f8@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>
 <-XqxxpPEkebnEhmbGjdbmYbEk8ht-0O0jcblQdS3L8s=.fb61af05-aadd-4445-8ab9-9de3fea202f8@github.com>
Message-ID: <TKX49tKli6kDXGiTRD74PgUK6p4zB5jN-rDrbRLdIgo=.4b9d41de-b607-4fda-8a7e-7ed211e0f40d@github.com>

On Tue, 12 Oct 2021 03:54:14 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> 
> 
> The changes look good

Thanks much for review! Could you please also review the CSR as well https://bugs.openjdk.java.net/browse/JDK-8274174?

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

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

From duke at openjdk.java.net  Tue Oct 12 19:16:52 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 12 Oct 2021 19:16:52 GMT
Subject: Integrated: 8268764: Use Long.hashCode() instead of int-cast where
 applicable
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <QfvXFKWNAo7KMigQy6uuthHhLPLGjb03brzhQ2rKtMg=.81e62395-3e8b-4bbe-bb7e-52b426ff07e2@github.com>

On Tue, 15 Jun 2021 12:15:11 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

This pull request has now been integrated.

Changeset: 124f8237
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/124f82377ba93359bc59118ee315ba194080fa92
Stats:     21 lines in 9 files changed: 6 ins; 0 del; 15 mod

8268764: Use Long.hashCode() instead of int-cast where applicable

Reviewed-by: kevinw, prr, kizune, serb

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

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

From duke at openjdk.java.net  Tue Oct 12 20:39:13 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 20:39:13 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

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

  8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
  revert changes in spec to avoid CSR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5432/files
  - new: https://git.openjdk.java.net/jdk/pull/5432/files/14005d1d..c8d68c2a

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

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

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

From naoto at openjdk.java.net  Tue Oct 12 20:39:14 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Oct 2021 20:39:14 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
 <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
Message-ID: <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>

On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 123:
>> 
>>> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
>>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
>> 
>> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.
>
> reverted changes in this spec.

Did you modify the PR? I am unable to locate the revert.

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

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

From duke at openjdk.java.net  Tue Oct 12 20:39:14 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 20:39:14 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
 <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
 <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>
Message-ID: <J1wtQXATnYkW26m1PpnmlmQyjMgzGRdP4OtATWagep0=.796bb462-c2c3-4bcb-ad4c-a0525681f470@github.com>

On Tue, 12 Oct 2021 20:33:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> reverted changes in this spec.
>
> Did you modify the PR? I am unable to locate the revert.

Oops. Forgot to push

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

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

From mcimadamore at openjdk.java.net  Tue Oct 12 20:41:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Oct 2021 20:41:00 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries [v7]
In-Reply-To: <vvUlcl5LY6dbSjF_AEi7eKK-vWBvpv4WAXmzyw6khPU=.ff75165a-74f4-4219-9093-df6f10543edc@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
 <vvUlcl5LY6dbSjF_AEi7eKK-vWBvpv4WAXmzyw6khPU=.ff75165a-74f4-4219-9093-df6f10543edc@github.com>
Message-ID: <7hT9Tr0x6g2JNV1_rqMhinm1FDaIiYtsVYtvR8__RkA=.45963198-0705-490e-86e1-486b6e140a12@github.com>

On Tue, 12 Oct 2021 18:11:56 GMT, Cheng Jin <duke at openjdk.java.net> wrote:

> Just tried with `System.load()` but still ended up with pretty much the same failure given both of them eventually invokes `ClassLoader.loadLibrary` to load the library in which case there is no big difference at this point.

Yes and no. System::loadLibrary wants a library name (no extension). It will add a library prefix (e.g. `lib` on linux) and a library suffix (e.g. `.so` on linux). So, if you do:


System.loadLibrary("c")


You will end up with `libc.so`. The `System::loadLibrary` logic will then try to find that file in any of the known library paths.

`System.load` avoids this by accepting the full path of the library. So there's no guessing the path, nor guessing of prefix/suffix. But it seems like loading still fails, likely because we try to load this library with `dlopen` but this is a static library, so for `dlopen` it just doesn't make sense.

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

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

From naoto at openjdk.java.net  Tue Oct 12 20:46:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Oct 2021 20:46:50 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>
Message-ID: <R-tgDRJ5SKkQATM35Q4ApUdtppXYZQqEw0vhC96tvuM=.907d5018-af76-4a7d-add7-d79238d30741@github.com>

On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
>   revert changes in spec to avoid CSR

Marked as reviewed by naoto (Reviewer).

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

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

From duke at openjdk.java.net  Tue Oct 12 20:49:56 2021
From: duke at openjdk.java.net (Cheng Jin)
Date: Tue, 12 Oct 2021 20:49:56 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries [v7]
In-Reply-To: <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
Message-ID: <mFxSMCcv-0-mVHldbJVpNya1uXnD-ibVdz-Nio0_Gmc=.2cea84ac-3a1a-4f22-819f-1103fb1ae0ba@github.com>

On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>> 
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added:
>> 
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified.
>> 
>> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments on shim lib makefile

If so,  I am wondering whether there is anything else left (inherited from JDK16) in JDK17 we can leverage to support `libc.a` on AIX except the way similar to Windows.

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

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

From mcimadamore at openjdk.java.net  Tue Oct 12 20:51:02 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Oct 2021 20:51:02 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v2]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <jJH35ZubiJpq_ozmwZAj2z8BY3j9nFy6YMeaCihatBM=.ae352c56-ed27-4a65-980c-1d79fa03c7a9@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

  Fix TestLinkToNativeRBP test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/be0dd36e..23f69054

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

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

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

From jvernee at openjdk.java.net  Tue Oct 12 21:30:53 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 12 Oct 2021 21:30:53 GMT
Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded
 libraries [v7]
In-Reply-To: <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
References: <ipMQ0ppvRSPyC_GsKGIpNBaDW4dpoX_flmOKV1wkLe4=.cf8375ec-e4eb-4b92-932c-c2658d0b57df@github.com>
 <s6Q6ColAuIcmtS4tmI18YqFxzO0rhHlWoTgjFYZqrmM=.74a93ded-0275-4c73-beb7-3ee8dad35b5f@github.com>
Message-ID: <TZvbP8d_Qo0ismoN3DqElGhWoxaiQ-ebMY_Sa5fpPaE=.c1dd23f3-5482-47d9-84dd-f55091c2d06f@github.com>

On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>> 
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added:
>> 
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified.
>> 
>> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments on shim lib makefile

I think the reason it worked in JDK 16 is because all the symbols in the JVM were visible through the system lookup, and the JVM statically links the standard library (AFAIU). So, just because the VM code depended on something, it could be loaded by the system lookup. But, that would mean that not all symbols in the standard library were visible... and also, being able to find _any_ symbol in the JVM was a bug.

I think the only solution here - assuming that libc is not available as a dynamic library on typical AIX systems - is to figure out how to repackage these static libraries as a dynamic library, retaining all the symbols, and then bundle that dynamic library with the JDK.

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

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

From psandoz at openjdk.java.net  Wed Oct 13 00:06:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 13 Oct 2021 00:06:03 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v2]
In-Reply-To: <jJH35ZubiJpq_ozmwZAj2z8BY3j9nFy6YMeaCihatBM=.ae352c56-ed27-4a65-980c-1d79fa03c7a9@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <jJH35ZubiJpq_ozmwZAj2z8BY3j9nFy6YMeaCihatBM=.ae352c56-ed27-4a65-980c-1d79fa03c7a9@github.com>
Message-ID: <CDgHtDihEFbyoZFOgb9RmM8b9zZwZn0y-KS7VG0_BQs=.7c4cc41f-a780-42f3-b966-1d177131e21b@github.com>

On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestLinkToNativeRBP test

Like with previous reviews of code for Panama JEPs there are not many comments on this PR, since prior reviews occurred for PRs in the panama-foreign repo.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 77:

> 75:  * Furthermore, if the function descriptor's return layout is a group layout, the resulting downcall method handle accepts
> 76:  * an extra parameter of type {@link SegmentAllocator}, which is used by the linker runtime to allocate the
> 77:  * memory region associated with the struct returned by  the downcall method handle.

Suggestion:

 * memory region associated with the struct returned by the downcall method handle.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 88:

> 86:  * in which the specialized signature of a given variable arity callsite is described in full. Alternatively,
> 87:  * if the foreign library allows it, clients might also be able to interact with variable arity methods
> 88:  * using by passing a trailing parameter of type {@link VaList}.

Suggestion:

 * by passing a trailing parameter of type {@link VaList}.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 145:

> 143:      * Lookup a symbol in the standard libraries associated with this linker.
> 144:      * The set of symbols available for lookup is unspecified, as it depends on the platform and on the operating system.
> 145:      * @return a linker-specific library lookup which is suitable to find symbols in the standard libraries associated with this linker.

Suggestion:

     * @return a symbol in the standard libraries associated with this linker.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 93:

> 91:         Objects.requireNonNull(argLayouts);
> 92:         Arrays.stream(argLayouts).forEach(Objects::requireNonNull);
> 93:         return new FunctionDescriptor(null, argLayouts);

We need to clone `argLayouts`, otherwise the user can modify the contents. Internally, using `List.of` is useful, since it does the cloning and null checks, and that is the type that is returned. Also `argumentLayouts` uses `Arrays.asList` which supports modification of the contents.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 394:

> 392:      * <p>
> 393:      * The returned allocator might throw an {@link OutOfMemoryError} if the total memory allocated with this allocator
> 394:      * exceeds the arena size, or the system capacity. Furthermore, the returned allocator is not thread safe, and all

The "the returned allocator is not thread safe" contradicts the prior sentence "An allocator associated with a <em>shared</em> resource scope is thread-safe and allocation requests may be performed concurrently".

Perhaps just say:
"
<p>
The returned allocator is not thread safe if the given scope is a shared scope. Concurrent allocation needs to be guarded with synchronization primitives. 
"

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 260:

> 258: 
> 259:     @Override
> 260:     public final MemorySegment asOverlappingSlice(MemorySegment other) {

Please ignore these comments if you wish.

Adding `max() // exclusive` to complement `min()` might be useful.

In these cases i find it easier to sort the segments e.g. `var a = this; var b = other; if (a.min() > b.min()) { // swap a and b }` then the subsequent logic tends to get simpler e.g. overlap test is `if (b.min() < a.max())`, `segmentOffset` is always +ve.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 100:

> 98:             do {
> 99:                 value = (int)ASYNC_RELEASE_COUNT.getVolatile(this);
> 100:             } while (!ASYNC_RELEASE_COUNT.compareAndSet(this, value, value + 1));

Use `getAndAdd` (and ignore the return value).

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

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

From jpai at openjdk.java.net  Wed Oct 13 10:56:57 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 13 Oct 2021 10:56:57 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:"
Message-ID: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>

The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.

The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.

Looking at the output attached in that JBS issue, there's this:


command: main LogParameters
reason: Assumed action based on file name: run main LogParameters
Mode: agentvm 

which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.

The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.

P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.

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

Commit messages:
 - 8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:"

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

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

From mcimadamore at openjdk.java.net  Wed Oct 13 12:07:58 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 13 Oct 2021 12:07:58 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v3]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <BSiDjLx_nNyU3QMibl-XcFErBWhFFXeCzzNiaZQloSo=.3d3d481a-d1eb-49dd-a7c3-64fa6444e9d0@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

  Apply suggestions from code review
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/23f69054..d6bf27ff

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

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

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

From mcimadamore at openjdk.java.net  Wed Oct 13 12:48:06 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 13 Oct 2021 12:48:06 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v4]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <qvWeMm1SEdF358nYUBzvvJfkpGORscRO121atAnUwD0=.7f084e8d-e811-47b0-bde2-8e447fe8911e@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/d6bf27ff..27e71ee7

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

  Stats: 35 lines in 4 files changed: 8 ins; 11 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

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

From mullan at openjdk.java.net  Wed Oct 13 13:50:13 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 13 Oct 2021 13:50:13 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception when
 it rejects the signer key
Message-ID: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>

This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:

- The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.

- The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.

- AlgorithmDecomposer now stores the canonical algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

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

Commit messages:
 - Remove trailing whitespace.
 - 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key

Changes: https://git.openjdk.java.net/jdk/pull/5928/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5928&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243585
  Stats: 175 lines in 8 files changed: 66 ins; 57 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5928/head:pull/5928

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

From weijun at openjdk.java.net  Wed Oct 13 14:03:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 13 Oct 2021 14:03:49 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:"
In-Reply-To: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
Message-ID: <rTJUuUJmkzcGP4pypNIn35P1phkGo66IuMPCh1F3fXs=.588d75d6-c996-4bec-88bd-230aa5694fee@github.com>

On Wed, 13 Oct 2021 10:49:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
> 
> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
> 
> Looking at the output attached in that JBS issue, there's this:
> 
> 
> command: main LogParameters
> reason: Assumed action based on file name: run main LogParameters
> Mode: agentvm 
> 
> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
> 
> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
> 
> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.

Thanks for looking into this bug. The test was written by me and I have always wondering why it could fail again and again. Your explanation might be the reason so let's give it a try. Approved.

test/jdk/javax/xml/crypto/dsig/LogParameters.java line 2:

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

It should be "2020, 2021,".

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

Marked as reviewed by weijun (Reviewer).

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

From jpai at openjdk.java.net  Wed Oct 13 14:22:16 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 13 Oct 2021 14:22:16 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
Message-ID: <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>

> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
> 
> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
> 
> Looking at the output attached in that JBS issue, there's this:
> 
> 
> command: main LogParameters
> reason: Assumed action based on file name: run main LogParameters
> Mode: agentvm 
> 
> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
> 
> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
> 
> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.

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

  fix copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5927/files
  - new: https://git.openjdk.java.net/jdk/pull/5927/files/856c361a..2213629b

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

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

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

From jpai at openjdk.java.net  Wed Oct 13 14:22:17 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 13 Oct 2021 14:22:17 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <rTJUuUJmkzcGP4pypNIn35P1phkGo66IuMPCh1F3fXs=.588d75d6-c996-4bec-88bd-230aa5694fee@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <rTJUuUJmkzcGP4pypNIn35P1phkGo66IuMPCh1F3fXs=.588d75d6-c996-4bec-88bd-230aa5694fee@github.com>
Message-ID: <I1a1HHMTvWdQ6YHj8EiIBAuB3O7MEDDDZiIYTbhUahs=.740db852-4824-4477-9620-08dfbd30a23c@github.com>

On Wed, 13 Oct 2021 14:00:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix copyright year
>
> test/jdk/javax/xml/crypto/dsig/LogParameters.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> It should be "2020, 2021,".

Indeed. Updated the PR to fix this now.

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

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

From rhalade at openjdk.java.net  Wed Oct 13 16:20:48 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Wed, 13 Oct 2021 16:20:48 GMT
Subject: RFR: 8272908: Missing coverage for certain classes in
 com.sun.org.apache.xml.internal.security
In-Reply-To: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
References: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
Message-ID: <bTjv_cw9gZg2LNn8ABHg3pIx9p9s_lnn9V9qUelqWb8=.588298c0-c533-4686-b776-8905576c4037@github.com>

On Tue, 12 Oct 2021 17:04:27 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This patch improves code coverage on the following classes:
> - com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac
> - com.sun.org.apache.xml.internal.security.utils.ElementProxy
> - com.sun.org.apache.xml.internal.security.keys.KeyInfo
> 
> The new tests exercise code blocks that are not currently covered by other tests.

test/jdk/com/sun/org/apache/xml/internal/security/SignatureKeyInfo.java line 117:

> 115:                 doc.getElementsByTagNameNS(NS, "Signature");
> 116:         if (nl.getLength() == 0) {
> 117:             throw new Exception("Could not find signature Element");

update this to RuntimeException

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

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

From rhalade at openjdk.java.net  Wed Oct 13 16:28:51 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Wed, 13 Oct 2021 16:28:51 GMT
Subject: RFR: 8272908: Missing coverage for certain classes in
 com.sun.org.apache.xml.internal.security
In-Reply-To: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
References: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
Message-ID: <GxXJ6mLzN0mRoWg7Oi8qxAir16WGAIbphNpuU89vUhg=.2b12e041-4c0e-4a01-ac07-8981bc99b80b@github.com>

On Tue, 12 Oct 2021 17:04:27 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This patch improves code coverage on the following classes:
> - com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac
> - com.sun.org.apache.xml.internal.security.utils.ElementProxy
> - com.sun.org.apache.xml.internal.security.keys.KeyInfo
> 
> The new tests exercise code blocks that are not currently covered by other tests.

Marked as reviewed by rhalade (Reviewer).

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

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

From dfuchs at openjdk.java.net  Wed Oct 13 17:12:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 13 Oct 2021 17:12:53 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
Message-ID: <djeqSFt3JdiN0iDWg21wZTq1fMJiLcb3i8sMuqO3KPc=.d38610e1-6bbc-4c38-922e-438a95becfd5@github.com>

On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year

Wait! I believe the issue is elsewhere...

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

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

From dfuchs at openjdk.java.net  Wed Oct 13 17:20:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 13 Oct 2021 17:20:49 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
Message-ID: <yINUYoUlSI4TQMVOWsFfNezDVsSISLfHNifK6FGpE1Q=.d70f8f1f-5338-4185-8c03-6139d9a61c1e@github.com>

On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year

You need to stick the logger returned by `Logger.getLogger(String.class.getName())` into a static variable to prevent it from being garbage collected.
Indeed, if you don't do that, there will be only weak references to that logger, and the next call to `Logger.getLogger(String.class.getName())` might return a brand new instance.
Another possibility is to stick it in a local `logger` variable and call Reference.reachabilityFence(logger)  at the end of main() in order to prevent its garbage collection before main() exits...

Aside note: why `String.class.getName()`? is the logged message generated by java.lang.String? that would be dangerous - as strings are used all over the place in java.util.logging...

Oh - the issue is elsewhere, but since you are modifying the configuration of loggers you do need to run in /othervm too - so don't undo that change...

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

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

From ascarpino at openjdk.java.net  Wed Oct 13 17:38:58 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 13 Oct 2021 17:38:58 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider [v2]
In-Reply-To: <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>
Message-ID: <RaafdWNOSCVN6ClmvZtRQo1CafPORXlondQoNNJZLMs=.390e8390-abbe-4e1c-916f-dc7abb27e41d@github.com>

On Mon, 11 Oct 2021 23:32:26 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
>> 
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
>> 
>> The rest are minor code refactoring and updates for the PKCS11 Exception class.
>> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update for review comments.

I have marked the CSR as reviewed

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

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

From weijun at openjdk.java.net  Wed Oct 13 18:54:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 13 Oct 2021 18:54:51 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
Message-ID: <uM76VrpiFIOUlTdNSWZl9X8G58heF4dSAxZ6FynwT9g=.c95cfe4d-84e2-4537-b3fc-83697d088de2@github.com>

On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year

I can confirm that inside JDK all returned value of this `getLogger()` method are stored in a static field, **except for** the one in this test.

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

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

From duke at openjdk.java.net  Wed Oct 13 22:13:19 2021
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 13 Oct 2021 22:13:19 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on
 sun.net.www.MessageHeader and some other internal APIs
Message-ID: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>

?t.www.MessageHeader and some other internal APIs

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

Commit messages:
 - JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs

Changes: https://git.openjdk.java.net/jdk/pull/5937/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8061729
  Stats: 167 lines in 10 files changed: 111 ins; 15 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

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

From valeriep at openjdk.java.net  Wed Oct 13 22:47:48 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 13 Oct 2021 22:47:48 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider [v2]
In-Reply-To: <RaafdWNOSCVN6ClmvZtRQo1CafPORXlondQoNNJZLMs=.390e8390-abbe-4e1c-916f-dc7abb27e41d@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
 <BR3g_Yq5BUTpws0TQyyVhLBIPah2Or-9KIrC7bYP8fc=.765d7d1b-3287-4141-b1d0-574e8cac1499@github.com>
 <RaafdWNOSCVN6ClmvZtRQo1CafPORXlondQoNNJZLMs=.390e8390-abbe-4e1c-916f-dc7abb27e41d@github.com>
Message-ID: <Lcna2JlPK0N91NqaXUM6zlKFFjDoP1_Yyf5nOw4Vz6g=.a369513d-d29a-48bc-bbc3-76343cc2f61f@github.com>

On Wed, 13 Oct 2021 17:36:24 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> 
> 
> I have marked the CSR as reviewed

Thanks!

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

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

From jpai at openjdk.java.net  Thu Oct 14 03:25:07 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 14 Oct 2021 03:25:07 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v3]
In-Reply-To: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
Message-ID: <2iD1KHwmsS3nxk0ShQjpdLZRrDcc4Nee4PaqG7NPKIM=.1ededdb4-a5b5-4764-bcdf-4314592cfdef@github.com>

> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
> 
> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
> 
> Looking at the output attached in that JBS issue, there's this:
> 
> 
> command: main LogParameters
> reason: Assumed action based on file name: run main LogParameters
> Mode: agentvm 
> 
> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
> 
> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
> 
> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.

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

 - add a summary to the test as well as use a different logger than String.class to avoid any confusion
 - hold on to the logger instance

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5927/files
  - new: https://git.openjdk.java.net/jdk/pull/5927/files/2213629b..c4371826

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

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

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

From jpai at openjdk.java.net  Thu Oct 14 03:25:07 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 14 Oct 2021 03:25:07 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
Message-ID: <JO5k4RiKJiYKEG7MQDmqnlnnL0PCywQrYtwtuL4KrLQ=.527a879d-e1b8-45c8-8d29-16430778dd1b@github.com>

On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year

Hello Daniel,

> You need to stick the logger returned by `Logger.getLogger(String.class.getName())` into a static variable to prevent it from being garbage collected. Indeed, if you don't do that, there will be only weak references to that logger, and the next call to `Logger.getLogger(String.class.getName())` might return a brand new instance. 

You are right. Good catch. I hadn't thought of that aspect at all. I've now updated the PR to create the logger instance in a static field.

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

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

From jpai at openjdk.java.net  Thu Oct 14 03:34:45 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 14 Oct 2021 03:34:45 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <yINUYoUlSI4TQMVOWsFfNezDVsSISLfHNifK6FGpE1Q=.d70f8f1f-5338-4185-8c03-6139d9a61c1e@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
 <yINUYoUlSI4TQMVOWsFfNezDVsSISLfHNifK6FGpE1Q=.d70f8f1f-5338-4185-8c03-6139d9a61c1e@github.com>
Message-ID: <HI3AibLM8-wArkm0YbU8zqjFXZVI18eOkei8RkcGWRw=.fa41f5aa-41cc-4853-864f-c33770201ce3@github.com>

On Wed, 13 Oct 2021 17:15:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Aside note: why `String.class.getName()`? is the logged message generated by java.lang.String? that would be dangerous - as strings are used all over the place in java.util.logging...

I had a look at the original issue for which this test was introduced https://bugs.openjdk.java.net/browse/JDK-8247907. As Max notes in that JBS issue, the bug was in log messages which are parameterized. Internally, the implementation of `com.sun.org.slf4j.internal.Logger` just delegates the calls to a `java.util.logging.Logger` and the fix was to properly transform the parameterization placeholders before passing on the calls to the `java.util.logging.Logger`[1]. So from what I understand, this `LogParameters` testcase is just there to test a parameterized log message through the `com.sun.org.slf4j.internal.Logger` and as such it doesn't matter what logger name (or class) is passed to create the logger instance. To avoid any confusion about the `String.class` usage for the logger instance, I have now updated the PR to use a different logger name (and class) while constructing the `java.util.logging.Logger` and `com.sun.org.slf4j.internal.Logger` instances. Additionally, I've added 
 some code comments in the test and also added a `@summary` to explain what this test does.

The test continues to pass with these changes.

[1] https://hg.openjdk.java.net/jdk/jdk/rev/216c6baa0564#l2.119

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

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

From dfuchs at openjdk.java.net  Thu Oct 14 09:42:50 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 14 Oct 2021 09:42:50 GMT
Subject: RFR: 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: <s67a3OybwQZo1EZtAorTo9-pkxCO9cJ9omwcNMdsLAE=.646bfac0-8c85-4448-9187-3c687efefed7@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

It may be that the new library HttpHeaderParser works for the small use cases in which it is used, but its parsing of header fields is approximative. I am a bit uncomfortable by replacing a well tested parser (MessageHeader) with something that obviously doesn't implement the spec correctly - even though it's possible that the cases where it would give back a wrong answer do not occur in the scenario where it is used.

What is the underlying rationale for wanting to stop using MessageHeader in tests?

test/jdk/sun/net/www/protocol/http/NTLMTest.java line 163:

> 161: 
> 162:             for (int i=start; i<end; i++) {
> 163:                 MessageHeader header = new MessageHeader (s.getInputStream());

This change introduces a subtle behaviour difference in the test that may result in spurious "Connection Reset" exception. I would prefer if the existing logic was kept - and the test continued parsing the request headers before writing to the output.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 47:

> 45:             while(true) {
> 46:                 headerString = br.readLine();
> 47:                 if(headerString == null || headerString.isBlank()) {

This is not completely correct, a blank line would be an error, I think, or possibly an empty continuation line. isBlank() should be replaced by isEmpty().

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 54:

> 52:                     List <String> values = new ArrayList<>();
> 53:                     String headerValue = headerString.substring(headerString.indexOf(": ") + 2);
> 54:                     String [] valueArray = headerValue.split(",");

This is not right either - at least that's not how MessageHeader (or the HttpClient or HttpServer header parsers work). Multi-valued header correspond to header fields whose name appear on several lines.


foo: bar, baz

   => single value "bar, baz"


foo: bar
foo: baz


multiple values => "bar", "baz"

Usually - analyzing the value - and possibly splitting it around `,` or `;` is done in the second step at a higher level.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 62:

> 60:                 } else {
> 61:                     requestDetails = headerString.trim();
> 62:                 }

This is not right: the request line - or status line - is the first line which is read - not just any line that doesn't contain `:`
FWIW, a request line may contain the full URL and therefore may contain `:`

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 63:

> 61:                     requestDetails = headerString.trim();
> 62:                 }
> 63:             }

You should also take into account continuation lines (lines that begin with a space) - and IIRC a continuation would be \r followed by a space - so I'm not 100% sure that using readline() is completely appropriate as it will consume \r, \n, or \r\n equally.

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

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

From fguallini at openjdk.java.net  Thu Oct 14 10:16:16 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 14 Oct 2021 10:16:16 GMT
Subject: RFR: 8272908: Missing coverage for certain classes in
 com.sun.org.apache.xml.internal.security [v2]
In-Reply-To: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
References: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
Message-ID: <5zOMGuR5UlZtZZm22eOF2GeHNOkUMYMLJWJdx8riChE=.570647f0-ebc4-4e79-b972-c4daf4b1dc90@github.com>

> This patch improves code coverage on the following classes:
> - com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac
> - com.sun.org.apache.xml.internal.security.utils.ElementProxy
> - com.sun.org.apache.xml.internal.security.keys.KeyInfo
> 
> The new tests exercise code blocks that are not currently covered by other tests.

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

  throw RuntimeException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5913/files
  - new: https://git.openjdk.java.net/jdk/pull/5913/files/4d8c0c89..4916ebad

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

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

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

From fguallini at openjdk.java.net  Thu Oct 14 10:16:17 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 14 Oct 2021 10:16:17 GMT
Subject: RFR: 8272908: Missing coverage for certain classes in
 com.sun.org.apache.xml.internal.security [v2]
In-Reply-To: <bTjv_cw9gZg2LNn8ABHg3pIx9p9s_lnn9V9qUelqWb8=.588298c0-c533-4686-b776-8905576c4037@github.com>
References: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
 <bTjv_cw9gZg2LNn8ABHg3pIx9p9s_lnn9V9qUelqWb8=.588298c0-c533-4686-b776-8905576c4037@github.com>
Message-ID: <Z7oQSh9LnMjhSBnGsww-smnYddY4JK3gOD6991K-f_Y=.f092397d-ff18-480a-92da-4c5654296233@github.com>

On Wed, 13 Oct 2021 16:17:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   throw RuntimeException
>
> test/jdk/com/sun/org/apache/xml/internal/security/SignatureKeyInfo.java line 117:
> 
>> 115:                 doc.getElementsByTagNameNS(NS, "Signature");
>> 116:         if (nl.getLength() == 0) {
>> 117:             throw new Exception("Could not find signature Element");
> 
> update this to RuntimeException

done

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

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

From dfuchs at openjdk.java.net  Thu Oct 14 10:51:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 14 Oct 2021 10:51:52 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v3]
In-Reply-To: <2iD1KHwmsS3nxk0ShQjpdLZRrDcc4Nee4PaqG7NPKIM=.1ededdb4-a5b5-4764-bcdf-4314592cfdef@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <2iD1KHwmsS3nxk0ShQjpdLZRrDcc4Nee4PaqG7NPKIM=.1ededdb4-a5b5-4764-bcdf-4314592cfdef@github.com>
Message-ID: <fFbqOTfPGEkIpe4vPuerTSZ72HWdtEB5PeSw9tPpNg0=.16e64dab-64ee-4da0-a6fa-f2850b0d244e@github.com>

On Thu, 14 Oct 2021 03:25:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a summary to the test as well as use a different logger than String.class to avoid any confusion
>  - hold on to the logger instance

Thanks Jaikiran. LGTM!

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

Marked as reviewed by dfuchs (Reviewer).

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

From weijun at openjdk.java.net  Thu Oct 14 13:15:56 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 13:15:56 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v2]
In-Reply-To: <HI3AibLM8-wArkm0YbU8zqjFXZVI18eOkei8RkcGWRw=.fa41f5aa-41cc-4853-864f-c33770201ce3@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <I0SG73RM7uIm-FPeiqLc7EgFRIYzuK6oRis5Kpc1f_s=.010d4f54-5185-436b-9d68-3e6764423ef1@github.com>
 <yINUYoUlSI4TQMVOWsFfNezDVsSISLfHNifK6FGpE1Q=.d70f8f1f-5338-4185-8c03-6139d9a61c1e@github.com>
 <HI3AibLM8-wArkm0YbU8zqjFXZVI18eOkei8RkcGWRw=.fa41f5aa-41cc-4853-864f-c33770201ce3@github.com>
Message-ID: <t0hS8GnS5M4oI0yvFpAy-a15uo4VEhpLzp5QCcXKevI=.df6fc737-7598-4149-9a1b-58f8f364b28c@github.com>

On Thu, 14 Oct 2021 03:32:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So from what I understand, this `LogParameters` testcase is just there to

Absolutely correct.

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

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

From weijun at openjdk.java.net  Thu Oct 14 13:44:00 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 13:44:00 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
Message-ID: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>

The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

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

Commit messages:
 - 8275252: Migrate cacerts from JKS to password-less PKCS12

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

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

From erikj at openjdk.java.net  Thu Oct 14 13:57:49 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Oct 2021 13:57:49 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <r03wHNI_PssfLK2Ni7UP8AHK-s0mpLwXn58SzO4eHq8=.4504753d-8b6e-4d45-a9cf-678a01887482@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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

From jpai at openjdk.java.net  Thu Oct 14 14:41:58 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 14 Oct 2021 14:41:58 GMT
Subject: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with
 "RuntimeException: Unexpected log output:" [v3]
In-Reply-To: <2iD1KHwmsS3nxk0ShQjpdLZRrDcc4Nee4PaqG7NPKIM=.1ededdb4-a5b5-4764-bcdf-4314592cfdef@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
 <2iD1KHwmsS3nxk0ShQjpdLZRrDcc4Nee4PaqG7NPKIM=.1ededdb4-a5b5-4764-bcdf-4314592cfdef@github.com>
Message-ID: <tnyiJMBSef6hpzdHcPlPfxRuyOljrna5-zaYotAmDgc=.73e04e3f-9631-4fce-89b8-d66b4ebeef77@github.com>

On Thu, 14 Oct 2021 03:25:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a summary to the test as well as use a different logger than String.class to avoid any confusion
>  - hold on to the logger instance

Thank you Max and Daniel for the reviews.

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

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

From jpai at openjdk.java.net  Thu Oct 14 14:41:59 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 14 Oct 2021 14:41:59 GMT
Subject: Integrated: 8254267: javax/xml/crypto/dsig/LogParameters.java failed
 with "RuntimeException: Unexpected log output:"
In-Reply-To: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
References: <9cVLLUA43Is2mOdOhmCk2w5-Ih600NiRd6yPtTxZIEc=.a848e303-8c82-4264-8d15-be55821209b1@github.com>
Message-ID: <C00sHJAoyb5IheIs-lHhb7Gh-YD_7tQ08DIxNomwbKM=.b0a68a87-df4e-43b2-8f73-acaa47b3cb6b@github.com>

On Wed, 13 Oct 2021 10:49:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
> 
> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
> 
> Looking at the output attached in that JBS issue, there's this:
> 
> 
> command: main LogParameters
> reason: Assumed action based on file name: run main LogParameters
> Mode: agentvm 
> 
> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
> 
> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
> 
> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.

This pull request has now been integrated.

Changeset: 40d69f0c
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40d69f0c41c8550605c3a1e6e572aecd3a8cf138
Stats:     15 lines in 1 file changed: 10 ins; 0 del; 5 mod

8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:"

Reviewed-by: weijun, dfuchs

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

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

From weijun at openjdk.java.net  Thu Oct 14 14:53:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 14:53:11 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore
Message-ID: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>

You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.

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

Commit messages:
 - 8231107: Storing PKCS12 keystore without integrity protection and no enc certs not easy

Changes: https://git.openjdk.java.net/jdk/pull/5950/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231107
  Stats: 59 lines in 2 files changed: 29 ins; 16 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5950.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5950/head:pull/5950

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

From duke at openjdk.java.net  Thu Oct 14 15:45:50 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 14 Oct 2021 15:45:50 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <5kwYGe1i7vi-xErsqesfSObRYkyV_7GvjrfHyxyARnY=.a1fc7c37-6f07-4ab8-81f5-674e83ba8fa1@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

I don't understand how this can work at all. I wrote a custom `CertDownloader` for our company use where I wanted to migrate to PKCS#12. Suddenly all of my applications started to fail on OpenJDK8u until I have figured out that PKCS#12 was not designed to be passwordless and due to the missing ecryption the trusted CA aren't visible. This bug is known as:
* https://bugs.openjdk.java.net/browse/JDK-8231107
* https://bugs.openjdk.java.net/browse/JDK-8194702

I had to revert to JKS for now. Unless those drizzle down to 8u, 11u, 17u this is going to be hard.

I still would love to see a trust store (not key store) which either reads OpenSSL's [`CAfile` or `CApath`](https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_load_verify_locations.html). This would greatly improve compat between Java and the OS default store on may OS, e.g., Debian, FreeBSD, RHEL, etc.

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

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

From hchao at openjdk.java.net  Thu Oct 14 16:13:10 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 14 Oct 2021 16:13:10 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner
Message-ID: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>

It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.

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

Commit messages:
 - 8272163: Add -version option to keytool and jarsigner

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

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

From weijun at openjdk.java.net  Thu Oct 14 17:34:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 17:34:50 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <xDKN_PUpYElmacRlr4NeKCLPfkSWlKPz9iebxOU_PAY=.a8d4e5d2-966b-43ee-9e14-392ec28a91aa@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

If you look into the code change for `make/ToolsJdk.gmk`, you can see 2 system properties used while generating the new cacerts file. With them, the new file becomes password-less.

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

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

From fguallini at openjdk.java.net  Thu Oct 14 18:29:55 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 14 Oct 2021 18:29:55 GMT
Subject: Integrated: 8272908: Missing coverage for certain classes in
 com.sun.org.apache.xml.internal.security
In-Reply-To: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
References: <dpTsXqyUOI-8VnhE_YI71x0Qt4AS0A9CPjfqdIey23M=.47477970-98f4-431e-895f-177771022431@github.com>
Message-ID: <M9cFeQRmdEgdhIv0RViKUCmpK33USEOhWgLrvkfi9Fc=.d52b0018-4f9c-4d3f-8965-485ee081e2ef@github.com>

On Tue, 12 Oct 2021 17:04:27 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This patch improves code coverage on the following classes:
> - com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac
> - com.sun.org.apache.xml.internal.security.utils.ElementProxy
> - com.sun.org.apache.xml.internal.security.keys.KeyInfo
> 
> The new tests exercise code blocks that are not currently covered by other tests.

This pull request has now been integrated.

Changeset: a16f2d0a
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a16f2d0a3c326dd8b3b2133a9c170d998b7aa631
Stats:     253 lines in 3 files changed: 246 ins; 0 del; 7 mod

8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security

Reviewed-by: rhalade

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

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

From duke at openjdk.java.net  Thu Oct 14 19:10:50 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 14 Oct 2021 19:10:50 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <xDKN_PUpYElmacRlr4NeKCLPfkSWlKPz9iebxOU_PAY=.a8d4e5d2-966b-43ee-9e14-392ec28a91aa@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <xDKN_PUpYElmacRlr4NeKCLPfkSWlKPz9iebxOU_PAY=.a8d4e5d2-966b-43ee-9e14-392ec28a91aa@github.com>
Message-ID: <oMyGlIoGB-XzVw0BVTpMawWpq58NKqNLp4JkugMnl5A=.34d6559c-848a-402e-89e5-fedad2aba8df@github.com>

On Thu, 14 Oct 2021 17:31:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 
> 
> If you look into the code change for `make/ToolsJdk.gmk`, you can see 2 system properties used while generating the new cacerts file. With them, the new file becomes password-less.

This I have seen, but what about:
* Generating this trust store with Java code like I do?
* Will this solve the two mentioned tickets?

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

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

From weijun at openjdk.java.net  Thu Oct 14 19:26:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 19:26:47 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <oMyGlIoGB-XzVw0BVTpMawWpq58NKqNLp4JkugMnl5A=.34d6559c-848a-402e-89e5-fedad2aba8df@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <xDKN_PUpYElmacRlr4NeKCLPfkSWlKPz9iebxOU_PAY=.a8d4e5d2-966b-43ee-9e14-392ec28a91aa@github.com>
 <oMyGlIoGB-XzVw0BVTpMawWpq58NKqNLp4JkugMnl5A=.34d6559c-848a-402e-89e5-fedad2aba8df@github.com>
Message-ID: <ybfqzhFduoDMR_31H1joPugT5ATLcUzM9g6dI1uo62o=.e6936b29-65d4-4a3f-ae65-472f5e562a2b@github.com>

On Thu, 14 Oct 2021 19:07:55 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

> Generating this trust store with Java code like I do?

What do you mean "like you do"? If you accept the proposed format in this PR, then just follow what `GenerateCACerts.java` is doing and how it's called. If you are thinking about reading the openssl trust store, that's not what this PR is for. This PR intends to find a modern format that is 100% interoperable with older JDK releases.

As for the other two tickets, they are related. If JDK-8231107 is resolved, then there's no need to set the 2 system properties. JDK-8194702 is not fixable because the certificates are already encrypted. Instead, https://bugs.openjdk.java.net/browse/JDK-8274913 was proposed, but only newly generated keystores after it will get the benefit.

Still, this PR does not depend on the other two tickets. This PR is about one single keystore -- cacerts -- which can be treated special.

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

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

From duke at openjdk.java.net  Thu Oct 14 19:40:51 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 14 Oct 2021 19:40:51 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <eHFLBxFqX5rrkgZVrAH6g-IsIHpOtrwY_KgdgveQAzo=.819df507-ab0b-44a9-9955-c9b88c5d0259@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

Let me summarize/rephrase your last message: To trick in the Makefile and the changed Java code (same way as I do in my code) produce a password-less truststore. Now since JDK-8231107 depicts that loading with a null password does not work the same way as with JKS this means that JDK-8231107 must also be applied to all supported JDK versions to make the output of this PR usable. Doesn't it? Note: JDK-8274913 is not publically available and I don't have a JBS account also I do report issues with Apache projects to Rory O'Donnell sometimes.

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

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

From weijun at openjdk.java.net  Thu Oct 14 19:53:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 19:53:50 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <GyWiluJtGrHM0tSYngJvkNTyiFp8fUPsYxGfvMZkwiI=.76256b8e-0804-4540-805a-e60d0a9ad94a@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

No, this PR is totally independent. Once a password-less pkcs12 file is generated, it can be read by any JDK since JDK 7u with a null password and the certs are visible. The other 2 tickets are all about storing, storing with a null password, storing with a default algorithm.

I've made JDK-8274913 public. It's just an idea and not proposed to any release.

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

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

From duke at openjdk.java.net  Thu Oct 14 20:01:47 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 14 Oct 2021 20:01:47 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <GyWiluJtGrHM0tSYngJvkNTyiFp8fUPsYxGfvMZkwiI=.76256b8e-0804-4540-805a-e60d0a9ad94a@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <GyWiluJtGrHM0tSYngJvkNTyiFp8fUPsYxGfvMZkwiI=.76256b8e-0804-4540-805a-e60d0a9ad94a@github.com>
Message-ID: <qEsB4SkkXJtRO_VTRxU6RxVdBG19g_90j-p4T0X589E=.c5e2b6f5-07f6-4096-995e-f21fc1464fa8@github.com>

On Thu, 14 Oct 2021 19:50:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 
> 
> No, this PR is totally independent. Once a password-less pkcs12 file is generated, it can be read by any JDK since JDK 7u with a null password and the certs are visible. The other 2 tickets are all about storing, storing with a null password, storing with a default algorithm.
> 
> I've made JDK-8274913 public. It's just an idea and not proposed to any release.

OK, now I see. This makes sense now. Storing is a different and as I see in your code somewhere `NONE` needs to be provided and it is not obvious apparently. Storing will remain a pain in all JDK versions unless JDK-8274913 is implemented which will solve JDK-8231107.

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

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

From duke at openjdk.java.net  Thu Oct 14 20:06:50 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 14 Oct 2021 20:06:50 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <MUL40-ULOaZ4Ba5G4_z4vlIUontDLYSVw64juJ5EUv0=.3ea27bff-954f-47d5-a8fb-fdbfb2e83080@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <MUL40-ULOaZ4Ba5G4_z4vlIUontDLYSVw64juJ5EUv0=.3ea27bff-954f-47d5-a8fb-fdbfb2e83080@github.com>
Message-ID: <ulJ51ZcACTwU6Wr1ZFAPxz2Hp33JIg02Q9YmAjS0y0s=.e8aae8a1-f1c8-4054-ab13-0dab2dc9475b@github.com>

On Thu, 14 Oct 2021 20:02:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 
> 
> For password-less pksc12, JDK-8231107 is more relevant. JDK-8274913 still has MacData, which is quite useless for cacerts, and leaving a well-known password there is awkward.

Agree, makes sense.

BTW: https://github.com/ctron/pem-keystore#reading-a-ca-bundle

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

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

From weijun at openjdk.java.net  Thu Oct 14 20:06:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 20:06:49 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <MUL40-ULOaZ4Ba5G4_z4vlIUontDLYSVw64juJ5EUv0=.3ea27bff-954f-47d5-a8fb-fdbfb2e83080@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

For password-less pksc12, JDK-8231107 is more relevant. JDK-8274913 still has MacData, which is quite useless for cacerts, and leaving a well-known password there is awkward.

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

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

From weijun at openjdk.java.net  Thu Oct 14 23:02:06 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Oct 2021 23:02:06 GMT
Subject: RFR: 8049520: FileCredentialsCache loads cache once and is never
 refreshed
Message-ID: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>

Just re-load the CredentialsCache like we did on non-Windows non-macOS systems.

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

Commit messages:
 - 8049520: FileCredentialsCache loads cache once and is never refreshed

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

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

From duke at openjdk.java.net  Fri Oct 15 02:05:54 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 15 Oct 2021 02:05:54 GMT
Subject: Withdrawn: 8271566: DSA signature length value is not accurate in
 P11Signature
In-Reply-To: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
Message-ID: <7z49Eb-Ys_cfqCm7hp_YAM7y0b_h-InEQpo9Bg1L-Rc=.5cc95a7f-dfec-4320-9a05-9042250a7979@github.com>

On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.
> 
> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.
> 
> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Fri Oct 15 12:38:14 2021
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 15 Oct 2021 12:38:14 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v2]
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: <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>

> 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

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

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5937/files
  - new: https://git.openjdk.java.net/jdk/pull/5937/files/47f7ba24..6d9f17f4

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

  Stats: 20 lines in 2 files changed: 12 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

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

From mullan at openjdk.java.net  Fri Oct 15 12:59:49 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 15 Oct 2021 12:59:49 GMT
Subject: RFR: 8049520: FileCredentialsCache loads cache once and is never
 refreshed
In-Reply-To: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
References: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
Message-ID: <Kd2pQtprYCpatPSmanpKtx1ufJ5-MW895fkslNdXLzU=.fc65408c-1992-407d-8f27-78e098c737ae@github.com>

On Thu, 14 Oct 2021 22:53:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Just re-load the CredentialsCache like we did on non-Windows non-macOS systems.

test/jdk/sun/security/krb5/ccache/Refresh.java line 2:

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

Year should be 2021?

test/jdk/sun/security/krb5/ccache/Refresh.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8028780

Wrong bug number/summary. Is this test from somewhere else originally?

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

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

From dfuchs at openjdk.java.net  Fri Oct 15 12:59:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 12:59:52 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v2]
In-Reply-To: <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
Message-ID: <SEyCfaQYUFfYJGsn2vGgq_g7SYyrJbE3yvh2wpTqNik=.a3ba5970-05db-4369-9cd9-73c3da9298ea@github.com>

On Fri, 15 Oct 2021 12:38:14 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
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 45:

> 43:         String headerString = "";
> 44:             BufferedReader br = new BufferedReader(new InputStreamReader(this.is));
> 45:             //First line is either request line or status line

Alignment issue? Could you fix the formatting?

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 46:

> 44:             BufferedReader br = new BufferedReader(new InputStreamReader(this.is));
> 45:             //First line is either request line or status line
> 46:             requestOrStatusLine = br.readLine().strip();

Stripping the line could hide errors, as a status/request line is not supposed to start with a whitespace, for instance

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 62:

> 60:                     }
> 61:                     if(!headerMap.containsKey(key.strip())) {
> 62:                         headerMap.put(key.strip(), values);

It may not be a good idea to remove whitespace in a header key as it should not contain any whitespace. Doing so could hide protocol errors.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 69:

> 67:                 }
> 68:             }
> 69:     }

Still missing code to handle continuation lines.

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

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

From dfuchs at openjdk.java.net  Fri Oct 15 13:11:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 13:11:48 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v2]
In-Reply-To: <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
Message-ID: <NDae6WRlrhKA6fcUt0WrKIVCsKIH1iSx_Ew9fzhP5bs=.7fd04dc0-e86c-48ae-a898-8c91f906f94f@github.com>

On Fri, 15 Oct 2021 12:38:14 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
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

It would be good to have a separate test to test the behavior of the new library `HttpHeaderParser` class.
As an example, here [1] is the test we have written for the HttpClient Http1HeaderParser. You will see that it defines a numbers of test cases (response headers) - both positive and negative - and verifies that `sun.net.www.MessageHeader` and `Http1HeaderParser` give the same results in the positive case. It would be good to have something similar for `HttpHeaderParser` as it would give more confidence that the parsing is correct. You would need of course to add in your test new test cases that contain a request line - the Http1HeaderParser only parses status line since it's only used on the client side.

[1] https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/Http1HeaderParserTest.java

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

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

From mullan at openjdk.java.net  Fri Oct 15 13:24:52 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 15 Oct 2021 13:24:52 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <nkFQU1RTIMR_JEDEMlROLUms8XPxayPyrSIyayfy1Jo=.51513b7f-8e0e-43f4-accc-2356356c16c2@github.com>

On Thu, 14 Oct 2021 16:04:08 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

This will also need a CSR so I added the csr label.

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

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

From weijun at openjdk.java.net  Fri Oct 15 13:29:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 15 Oct 2021 13:29:19 GMT
Subject: RFR: 8049520: FileCredentialsCache loads cache once and is never
 refreshed [v2]
In-Reply-To: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
References: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
Message-ID: <_6zwmOucaZyQB9zr-4YE0lXAQqJvKJ1OH6vVJ6OdxZY=.44c165e6-8978-476f-97bb-112ed3561a1b@github.com>

> Just re-load the CredentialsCache like we did on non-Windows non-macOS systems.

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

  test info

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5960/files
  - new: https://git.openjdk.java.net/jdk/pull/5960/files/dbfd4f66..8cd6de4d

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

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

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

From weijun at openjdk.java.net  Fri Oct 15 13:29:24 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 15 Oct 2021 13:29:24 GMT
Subject: RFR: 8049520: FileCredentialsCache loads cache once and is never
 refreshed [v2]
In-Reply-To: <Kd2pQtprYCpatPSmanpKtx1ufJ5-MW895fkslNdXLzU=.fc65408c-1992-407d-8f27-78e098c737ae@github.com>
References: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
 <Kd2pQtprYCpatPSmanpKtx1ufJ5-MW895fkslNdXLzU=.fc65408c-1992-407d-8f27-78e098c737ae@github.com>
Message-ID: <Qe-L8Z7Cyr7PkTI_CWVtA5KsrswY1L88HCk41AhmN-k=.9dc17d97-6882-4b3c-907b-fa195f7ea1c7@github.com>

On Fri, 15 Oct 2021 12:54:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test info
>
> test/jdk/sun/security/krb5/ccache/Refresh.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8028780
> 
> Wrong bug number/summary. Is this test from somewhere else originally?

On no. I copied from a nearby test and forgot to update these fields. New commit pushed.

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

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

From mullan at openjdk.java.net  Fri Oct 15 13:35:49 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 15 Oct 2021 13:35:49 GMT
Subject: RFR: 8049520: FileCredentialsCache loads cache once and is never
 refreshed [v2]
In-Reply-To: <_6zwmOucaZyQB9zr-4YE0lXAQqJvKJ1OH6vVJ6OdxZY=.44c165e6-8978-476f-97bb-112ed3561a1b@github.com>
References: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
 <_6zwmOucaZyQB9zr-4YE0lXAQqJvKJ1OH6vVJ6OdxZY=.44c165e6-8978-476f-97bb-112ed3561a1b@github.com>
Message-ID: <By6dc0byJCTXE53mrDDTjvXvqKFbJeiwUiX3q8jmh9I=.685a0eba-bb4a-4d70-9b0b-cd8837462425@github.com>

On Fri, 15 Oct 2021 13:29:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Just re-load the CredentialsCache like we did on non-Windows non-macOS systems.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test info

Marked as reviewed by mullan (Reviewer).

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

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

From weijun at openjdk.java.net  Fri Oct 15 13:52:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 15 Oct 2021 13:52:52 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <bP6o6CaDJ6qElBaJAyUSBOvxHoyg5Tmy2qhnt0TAj2w=.d5427318-5425-4c68-ad33-fed477de0193@github.com>

On Thu, 14 Oct 2021 16:04:08 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

For the CSR, is it necessary to list the `-help` output change?

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

> 346:             }
> 347:             doPrintVersion();
> 348:         }

What happens if `-version` appears elsewhere?

I tried some other commands. When both `-version` and other arguments are provided, `java` ignores the others and prints out version info. `javac` prints out the version info and compiles as well.

It's possible that user writes a script or alias that always run the tool with some options (Ex: `-keystore`, `-storepass`, `-verbose`). Maybe we should not fail if `-version` is used with other options (no matter at the beginning or the end).

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

> 598:     }
> 599: 
> 600:     static void usageTooManyArg() {

Since the method is only for `-version` and the printed message also mentions "version", maybe it's better to choose a specific name.

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

> 600:     static void usageTooManyArg() {
> 601:         System.out.println(rb.getString(
> 602:                 "Option.should.not.be.specified.for.version"));

Neither arguments not options should be specified here.

test/jdk/sun/security/tools/jarsigner/VersionTest.java line 40:

> 38:                 .shouldHaveExitValue(0);
> 39: 
> 40:         SecurityTools.jarsigner("-version -extraopt")

You might want to use some legal arguments here, for example, `-version -help`. Otherwise, the error might be because the extra option is not supported. Or, you can check if an expected error message is printed out.

test/jdk/sun/security/tools/keytool/VersionTest.java line 40:

> 38:                 .shouldHaveExitValue(0);
> 39: 
> 40:         SecurityTools.keytool("-version -extraopt")

Same comment as above.

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

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

From weijun at openjdk.java.net  Fri Oct 15 13:55:00 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 15 Oct 2021 13:55:00 GMT
Subject: Integrated: 8049520: FileCredentialsCache loads cache once and is
 never refreshed
In-Reply-To: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
References: <PYijm9_92Sk0Jikklk-YkgnGYLbJlLtm6SD_glR4E-o=.6f8a194c-eec1-4a48-ad36-a8ffc1fa3442@github.com>
Message-ID: <vDg1GqyB8VsyHCYVC6SuY-4AIDILrpHGXMZdysTeG00=.4b3ffb86-4dc0-4506-96a0-4f25fc0bd6e7@github.com>

On Thu, 14 Oct 2021 22:53:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Just re-load the CredentialsCache like we did on non-Windows non-macOS systems.

This pull request has now been integrated.

Changeset: 8e020642
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e02064288a5954ab71b306fc31978a47012ef50
Stats:     73 lines in 2 files changed: 65 ins; 6 del; 2 mod

8049520: FileCredentialsCache loads cache once and is never refreshed

Reviewed-by: mullan

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

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

From mullan at openjdk.java.net  Fri Oct 15 14:04:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 15 Oct 2021 14:04:48 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <sFfh2w6M9do6gB_zQs2kV2AJMRoSnl7Zloa7XBKQkY8=.3402925f-41ab-49a8-b0a2-51c004daec19@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 74:

> 72:                 cert = (X509Certificate) cf.generateCertificate(fis);
> 73:             }
> 74:             ks.setCertificateEntry(alias, cert);

In the previous code, we always used a fixed date (cert's notBefore) for the creation date. Now, it seems it will be always different and based on when it was created. I'm not really sure if this is an issue in practice, but I think it is worth thinking about a bit more - do you have any thoughts on this?

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

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

From ihse at openjdk.java.net  Fri Oct 15 14:15:52 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 15 Oct 2021 14:15:52 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <sFfh2w6M9do6gB_zQs2kV2AJMRoSnl7Zloa7XBKQkY8=.3402925f-41ab-49a8-b0a2-51c004daec19@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <sFfh2w6M9do6gB_zQs2kV2AJMRoSnl7Zloa7XBKQkY8=.3402925f-41ab-49a8-b0a2-51c004daec19@github.com>
Message-ID: <cQWb6yqAeUydhpcTcHsPi7yZPrxWQXgCJKxJr_l6KnY=.0a4bbe69-a6ce-4d1c-8446-805255bbdfaf@github.com>

On Fri, 15 Oct 2021 14:02:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.
>
> make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 74:
> 
>> 72:                 cert = (X509Certificate) cf.generateCertificate(fis);
>> 73:             }
>> 74:             ks.setCertificateEntry(alias, cert);
> 
> In the previous code, we always used a fixed date (cert's notBefore) for the creation date. Now, it seems it will be always different and based on when it was created. I'm not really sure if this is an issue in practice, but I think it is worth thinking about a bit more - do you have any thoughts on this?

If that means the build will become non-reproducible, then *I* certainly have thoughts about it! ;-)

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

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

From weijun at openjdk.java.net  Fri Oct 15 15:00:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 15 Oct 2021 15:00:50 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <cQWb6yqAeUydhpcTcHsPi7yZPrxWQXgCJKxJr_l6KnY=.0a4bbe69-a6ce-4d1c-8446-805255bbdfaf@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <sFfh2w6M9do6gB_zQs2kV2AJMRoSnl7Zloa7XBKQkY8=.3402925f-41ab-49a8-b0a2-51c004daec19@github.com>
 <cQWb6yqAeUydhpcTcHsPi7yZPrxWQXgCJKxJr_l6KnY=.0a4bbe69-a6ce-4d1c-8446-805255bbdfaf@github.com>
Message-ID: <6yXAA76EWqiG9yTID2x0gyUYFy4EsM4Veo1QHgRtzFQ=.4397d5c5-fcae-4649-9042-d0670ef0ec94@github.com>

On Fri, 15 Oct 2021 14:12:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 74:
>> 
>>> 72:                 cert = (X509Certificate) cf.generateCertificate(fis);
>>> 73:             }
>>> 74:             ks.setCertificateEntry(alias, cert);
>> 
>> In the previous code, we always used a fixed date (cert's notBefore) for the creation date. Now, it seems it will be always different and based on when it was created. I'm not really sure if this is an issue in practice, but I think it is worth thinking about a bit more - do you have any thoughts on this?
>
> If that means the build will become non-reproducible, then *I* certainly have thoughts about it! ;-)

The certificate stored in a PKCS12 file has no date associated. Whenever you load a keystore, the creation time is set to the load time.

In fact, the `VerifyCACerts.java` maintains a SHA-256 hash of the keystore and it will not change unless the certs themselves are changed.

Here is the actual bytes for one certificate entry inside:

0000:1AD48  [] SEQUENCE
0005:0659  [0]     SEQUENCE
0009:000D  [00]         OID 1.2.840.113549.1.12.10.1.3 (CertBag)
0016:05DB  [01]         cont [0]
001A:05D7  [010]             SEQUENCE
001E:000C  [0100]                 OID 1.2.840.113549.1.9.22.1 (CertTypeX509)
002A:05C7  [0101]                 cont [0]
002E:05C3  [01010]                     OCTET STRING  (1729119956)
                                      0000: 30 82 05 BB 30 82 03 A3   A0 03 02 01 02 02 08 57  0...0..........W
                                      0010: 0A 11 97 42 C4 E3 CC 30   0D 06 09 2A 86 48 86 F7  ...B...0...*.H..
                                      0020: 0D 01 01 0B 05 00 30 6B   31 0B 30 09 06 03 55 04  ......0k1.0...U. (1471 bytes)
05F1:006D  [02]         SET
05F3:0053  [020]             SEQUENCE
05F5:000B  [0200]                 OID 1.2.840.113549.1.9.20 (FriendlyName)
0600:0046  [0201]                 SET
0602:0044  [02010]                     STRING "actalisauthenticationrootca [jdk]"
0646:0018  [021]             SEQUENCE
0648:000E  [0210]                 OID 2.16.840.1.113894.746875.1.1 (ORACLE_TrustedKeyUsage)
0656:0008  [0211]                 SET
0658:0006  [02110]                     OID 2.5.29.37.0 (anyExtendedKeyUsage)

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

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

From dfuchs at openjdk.java.net  Fri Oct 15 15:31:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 15:31:53 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

src/java.base/share/classes/java/net/InetAddress.java line 231:

> 229:  *      The first provider found will be used to instantiate the {@link InetAddressResolver InetAddressResolver}
> 230:  *      by invoking the {@link InetAddressResolverProvider#get(InetAddressResolverProvider.Configuration)}
> 231:  *      method. The instantiated {@code InetAddressResolver} will be installed as the system-wide

Maybe "... method. The **returned** {@code InetAddressResolver} will be installed ..."

src/java.base/share/classes/java/net/InetAddress.java line 486:

> 484:                 return cns;
> 485:             } finally {
> 486:                 bootstrapResolver = null;

This is incorrect. This will set bootstrapResolver to null in the case where you return it at line 468 - which means that a second call will then find it null. I believe you want to set it to null in the finally clause only if you reached line 470. You could achieve this by declaring a local variable - e.g `InetAddressResolver tempResolver = null;` before entering the try-finally then set that variable at line 470 `return tempResolver = bootstrapResolver;` and in finally do `if (tempResolver == null) bootsrapResolver = null;`

To test this you could try to call e.g. `InetAddress.getByName` twice in succession in your test: I believe it will fail with the code as it stands, but will succeed with my proposed changes...

src/java.base/share/classes/java/net/InetAddress.java line 860:

> 858:                 return host;
> 859:             }
> 860:         } catch (RuntimeException | UnknownHostException e) {

This may deserve a comment: resolver.lookUpHostName and InetAddress.getAllbyName0 delegate to the system-wide resolver, which could be custom, and we treat any unexpected RuntimeException thrown by the provider at that point as we would treat an UnknownHostException or an unmatched host name.

src/java.base/share/classes/java/net/InetAddress.java line 1063:

> 1061:         public Stream<InetAddress> lookupAddresses(String host, LookupPolicy policy)
> 1062:                 throws UnknownHostException {
> 1063:             Objects.requireNonNull(host);

Should we also double check that `policy` is not null? Or maybe assert it?

src/java.base/share/classes/java/net/InetAddress.java line 1203:

> 1201:                         + " as hosts file " + hostsFile + " not found ");
> 1202:             }
> 1203:             // Check number of found addresses:

I wonder if the logic here could be simplified by first checking whether only IPv4 addresses are requested, and then if only IPv6 addresses are requested. 

That is - evacuate the simple cases first and then only deal with the more complex case where you have to combine the two lists...

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

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

From mcimadamore at openjdk.java.net  Fri Oct 15 16:54:58 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 15 Oct 2021 16:54:58 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v5]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <xm7o86XcgVwfnpG50rBEHmkOyZm4wuH1f72Sv9vj4og=.a33e4e92-37cb-4de1-9ddd-2c3c56da5cc0@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

  * Fix javadoc issue in VaList
  * Fix bug in concurrent logic for shared scope acquire

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/27e71ee7..5ed94c30

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

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

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

From mcimadamore at openjdk.java.net  Fri Oct 15 16:56:08 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 15 Oct 2021 16:56:08 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v5]
In-Reply-To: <xm7o86XcgVwfnpG50rBEHmkOyZm4wuH1f72Sv9vj4og=.a33e4e92-37cb-4de1-9ddd-2c3c56da5cc0@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <xm7o86XcgVwfnpG50rBEHmkOyZm4wuH1f72Sv9vj4og=.a33e4e92-37cb-4de1-9ddd-2c3c56da5cc0@github.com>
Message-ID: <AdrqLjU1TOiqXp_Epxcwudb9XMESu4GVZSzPESMySt0=.3c3aea93-c522-468e-8c38-90f91d965e08@github.com>

On Fri, 15 Oct 2021 16:54:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Fix javadoc issue in VaList
>   * Fix bug in concurrent logic for shared scope acquire

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 138:

> 136:                 ResourceCleanup prev = (ResourceCleanup) FST.getAcquire(this);
> 137:                 cleanup.next = prev;
> 138:                 ResourceCleanup newSegment = (ResourceCleanup) FST.compareAndExchangeRelease(this, prev, cleanup);

In this place we can actually overwrite CLOSED_LIST (if getAcquired has seen such value). While this particular add will fail later on (since we check witness), another concurrent add might then pass, since it sees a value other than CLOSED_LIST (which is supposed to be a terminal state).

Also, after consulting with @DougLea  and @shipilev  - it seems like using volatile semantics is the way to go here.

This should fix a spurious (and very rare) failure on TestResourceScope on arm64.

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

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

From dfuchs at openjdk.java.net  Fri Oct 15 17:24:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 17:24:53 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38:

> 36:         String localHostName;
> 37:         try {
> 38:             localHostName = InetAddress.getLocalHost().getHostName();

Try to call InetAddress.getLocalHost().getHostName(); twice here.

test/lib/jdk/test/lib/net/IPSupport.java line 88:

> 86:             } catch (SocketException se2) {
> 87:                 return false;
> 88:             }

The implementation of this method now conflicts with its name. Maybe we should pass a `Class<? extends InetAddress>`  as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here.

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

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

From msheppar at openjdk.java.net  Sat Oct 16 10:51:48 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sat, 16 Oct 2021 10:51:48 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

What?s in a name?
I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space
one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup
to resolve an IP address to a hostname (or names) associated with it.

For the method names lookupHostname, and lookupAddresses,
and the semantics conveyed in those names, 
I would expect lookupHostname to resolve a hostname, that is, take a hostname as parameter and
the return value the addresses, while lookupAddresses I would expect to resolve an address to its hostname,
that is, take an address and return a hostname.
However, the current pair of methods names convey the opposite, lookupHostname resolves an address and
lookupAddresses resolves a hostname.

I would proffer a method name change to use lookup and reverseLookup
OR to use resolvesHostname and resolveAddress, to resolve a hostname and address
respectively.

Thus, lookupHostname should be renamed to reverseLookup and
lookupAddresses to lookup OR
lookupHostname renamed to resolveAddress and lookupAddresses renamed to resolveHostname.

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

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

From mcimadamore at openjdk.java.net  Sat Oct 16 11:11:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Sat, 16 Oct 2021 11:11:59 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v6]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <duQC157aL1XUf9C8J8Q-vNMTHwP6A3fEjkV2xrxVwbg=.dc7740e2-a51f-4431-82b8-41b91dee66ec@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

 - * use `invokeWithArguments` to simplify new test
 - Add test for liveness check with high-aririty downcalls
   (make sure that if an exception occurs in a downcall because of liveness,
   ref count of other resources are left intact).

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/5ed94c30..a4db81fe

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

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

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

From msheppar at openjdk.java.net  Sat Oct 16 12:33:52 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sat, 16 Oct 2021 12:33:52 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

Refactor remove Configuration and simplify interface:

In the InetAddressResolver a Configuration abstraction is defined, and this is supplied to
a get method of the InetAddressResolverProvider.

The objective is to ?inject? some platform configuration into an InetAddressResolver. This
consistents of two pieces of platform configuration detail, a builtin resolver reference and the hostname.
Why not provide them as parameters to the provider get method and dispense with the Configuration
abstraction? Thus simplifying the interface. The hostname is being supplied by the getLocalHostName
of an InetAddressImpl. This is essentially a wrapper to the library call gethostname. This
could be provided as a static method in InetAddressImpl, called once during loadResolver to 
provide the hostname parameter String. The hostname is a static piece of system configuration, which
requires a system restart if it were to be changed - so need to provide a lambda.

So Suggestion is refector remove Configuration to simplify the interface and provide the
BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method

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

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

From aefimov at openjdk.java.net  Sun Oct 17 15:58:54 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Sun, 17 Oct 2021 15:58:54 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
Message-ID: <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>

On Sat, 16 Oct 2021 12:30:44 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method

During work on this JEP we've examined the approach suggested above, and there are few issues with it:
- `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items.
- local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`.

It's been also discussed in the CSR comments [here](https://bugs.openjdk.java.net/browse/JDK-8274558)

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

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

From aefimov at openjdk.java.net  Sun Oct 17 16:36:51 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Sun, 17 Oct 2021 16:36:51 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
Message-ID: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>

On Sat, 16 Oct 2021 10:48:32 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it.

I'm not sure that I see an ambiguity here:
Interface has two methods, both are for lookup operations. That is why `lookup` word is used in both names. Then we put a description of a returned result after operation name: `Addresses` and `HostName` are the results. In cases when we want to highlight a parameter type in a method name we can use ?by?/?with? prepositions: for instance, `InetAddress.getByName` `InetAddress.getByAddress` `ScheduledExecutorService.scheduleWithFixedDelay`.

We can try and apply this approach to the description of DNS operations above:
> lookup to resolve a hostname to its associated addresses 

operation: `lookup` result: `addresses` -> methodName: `lookupAddresses`

> reverse lookup to resolve an IP address to a hostname

operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName`

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

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

From alanb at openjdk.java.net  Sun Oct 17 18:35:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Oct 2021 18:35:57 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
 <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
Message-ID: <qqJiU7O4rdC9vMWsbNXI5GTsa8BOgKvAxlJ_OS3tD9Y=.5f235e7a-4736-458a-b0a8-5cabcd7b7577@github.com>

On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> * `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items.
> * local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`.

Right, I think we've ended up with a good model here that supports the common case, stacking, and can be extended in the future to add new configuration if required. Also if good use-cases come up when Configuration can be changed to be non-sealed.

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

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

From msheppar at openjdk.java.net  Sun Oct 17 21:06:51 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sun, 17 Oct 2021 21:06:51 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
 <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>
Message-ID: <ChUmaIjYE61OE80QGJyqes8hnzErFw9IlgrSUlRtnNo=.a34cd6da-cc08-4e84-8fa2-c8f93f258268@github.com>

On Sun, 17 Oct 2021 16:33:57 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> > What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it.
> 
> I'm not sure that I see an ambiguity here: Interface has two methods, both are for lookup operations. That is why `lookup` word is used in both names. Then we put a description of a returned result after operation name: `Addresses` and `HostName` are the results. In cases when we want to highlight a parameter type in a method name we can use ?by?/?with? prepositions: for instance, `InetAddress.getByName` `InetAddress.getByAddress` `ScheduledExecutorService.scheduleWithFixedDelay`.
> 
> We can try and apply this approach to the description of DNS operations above:
> 
> > lookup to resolve a hostname to its associated addresses
> 
> operation: `lookup` result: `addresses` -> methodName: `lookupAddresses`
> 
> > reverse lookup to resolve an IP address to a hostname
> 
> operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName`

Yes, ambiguity wasn?t quite the word I was looking for. Maybe contradictory or oxymoron might do !!
Let me try and clarify the rational behind the suggestion.

To re-iterate, the parlance of the DNS domain in context of address resolution is lookup for hostname to IP address resolution and reverse lookup for address to hostname mapping. For me, the natural verb to method translation is lookup and **reverseLookup OR resolveHostname and resolveAddress. The latter names are pretty definitive and unambiguous. It clear and obvious without the need to pursue the full signature of the method, what the semantics of the methods should be.

At the java InetAddress API level there is getByName(String host) and getByAddress(byte[] addr).
At the native OS level there is gethostbyname, gethostbyaddr and the evolved api getnameinfo and getaddrinfo.

getByName requires a hostname lookup and getByAdress requires (eventually - I know the docs says there?s no reverse lookup) an address reverse lookup. Thus, a logical mapping is getByName ?> lookupHostname, and getByAddr ?> lookupAddress, but the opposite will occur getByName --> lookupAddresses and getByAddress --> lookupHostname.  Therfore  I proffer maps neatly to rename methods to resolveHostname and resolveAddress such that the mapping are getByName --> resolveHostname and getByAddress --> resolveAddress.

I will concede that it can be reasonable argued that the native library functions getnameinfo and getaddrinfo may better abstract to lookupHostname and lookupAddresses respectively. But, I have always found these two library calls a bit contorted and the legacy gethostbyname and gethostbyaddress were more logical.

In you proposition above:

> operation: `lookup` result: `addresses` -> methodName: `lookupAddresses`

> operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName`

You are generating the name from the result of the action. I?m arguing that it should be based on the operation on the subject i.e. the parameter being passed.
If this was hashmap lookup, then it is an operation of mapping hostname to addresses mapHostnameToAddresses, i.e. looking up a hostname, and mapping an address to a hostname mapAddressToHostname i.e. looking up an address.

Of course, it is possible to just **overload**  a lookup method, one taking Sting and t?other taking byte adder in the method?s parameters, respectively. Then, you don?t have to concede too much in this argument.
But, for me as an ordinary developer, resolveAddress and resolveHostname are crystal clear and unambiguous.

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

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

From msheppar at openjdk.java.net  Sun Oct 17 21:41:49 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sun, 17 Oct 2021 21:41:49 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
 <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
Message-ID: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com>

On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> > So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method
> 
> During work on this JEP we've examined the approach suggested above, and there are few issues with it:
> 
>     * `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items.
> 
>     * local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`.
> 
> 
> It's been also discussed in the CSR comments [here](https://bugs.openjdk.java.net/browse/JDK-8274558)

OK grand ... I didn't see the CSR discussion :-(

WRT hostname being dynamic and requires a lambda ... is it really dynamic?
 I know it can be changed, but IIRC most (unix and windows) if not all systems require a restart for such a change change to take effect, and usually requires a dns cache flush also, in which case an application will be restarting also.

 In the case of working over VPN, VPN software usually changes the hostname dynamically, but that name change is only valid for the duration of the VPN session, and when you exit the VPN, it reverts back to the original hostname. In such cases an application will need to be restarted. There's no seemless working from VPN to non VPN.

I think that a hostname is constant while a host is up, but  it can be changed, and when changed a host restart is required. I don't think it is quite as dynamic as has been suggested, but I open to correction.

 It is something that can be investigated.

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

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

From ihse at openjdk.java.net  Mon Oct 18 09:36:48 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 18 Oct 2021 09:36:48 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <PIxipEq7h4GjjkASCX_Zax5a4Ht6mZbazQV3I3kSasU=.d8036d73-8278-4ef2-ba8e-7fec95774a84@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

Marked as reviewed by ihse (Reviewer).

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

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

From ihse at openjdk.java.net  Mon Oct 18 09:36:49 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 18 Oct 2021 09:36:49 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <6yXAA76EWqiG9yTID2x0gyUYFy4EsM4Veo1QHgRtzFQ=.4397d5c5-fcae-4649-9042-d0670ef0ec94@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <sFfh2w6M9do6gB_zQs2kV2AJMRoSnl7Zloa7XBKQkY8=.3402925f-41ab-49a8-b0a2-51c004daec19@github.com>
 <cQWb6yqAeUydhpcTcHsPi7yZPrxWQXgCJKxJr_l6KnY=.0a4bbe69-a6ce-4d1c-8446-805255bbdfaf@github.com>
 <6yXAA76EWqiG9yTID2x0gyUYFy4EsM4Veo1QHgRtzFQ=.4397d5c5-fcae-4649-9042-d0670ef0ec94@github.com>
Message-ID: <MrMVtK0bwvyiDdBZZ3O3K3wSnirW2vIXPKwXCBUBjI4=.098c99aa-b80d-40a2-a5ef-e12d0d12b3f6@github.com>

On Fri, 15 Oct 2021 14:56:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> If that means the build will become non-reproducible, then *I* certainly have thoughts about it! ;-)
>
> The certificate stored in a PKCS12 file has no date associated. Whenever you load a keystore, the creation time is set to the load time.
> 
> In fact, the `VerifyCACerts.java` maintains a SHA-256 hash of the keystore and it will not change unless the certs themselves are changed.
> 
> Here is the actual bytes for one certificate entry inside:
> 
> 0000:1AD48  [] SEQUENCE
> 0005:0659  [0]     SEQUENCE
> 0009:000D  [00]         OID 1.2.840.113549.1.12.10.1.3 (CertBag)
> 0016:05DB  [01]         cont [0]
> 001A:05D7  [010]             SEQUENCE
> 001E:000C  [0100]                 OID 1.2.840.113549.1.9.22.1 (CertTypeX509)
> 002A:05C7  [0101]                 cont [0]
> 002E:05C3  [01010]                     OCTET STRING  (1729119956)
>                                       0000: 30 82 05 BB 30 82 03 A3   A0 03 02 01 02 02 08 57  0...0..........W
>                                       0010: 0A 11 97 42 C4 E3 CC 30   0D 06 09 2A 86 48 86 F7  ...B...0...*.H..
>                                       0020: 0D 01 01 0B 05 00 30 6B   31 0B 30 09 06 03 55 04  ......0k1.0...U. (1471 bytes)
> 05F1:006D  [02]         SET
> 05F3:0053  [020]             SEQUENCE
> 05F5:000B  [0200]                 OID 1.2.840.113549.1.9.20 (FriendlyName)
> 0600:0046  [0201]                 SET
> 0602:0044  [02010]                     STRING "actalisauthenticationrootca [jdk]"
> 0646:0018  [021]             SEQUENCE
> 0648:000E  [0210]                 OID 2.16.840.1.113894.746875.1.1 (ORACLE_TrustedKeyUsage)
> 0656:0008  [0211]                 SET
> 0658:0006  [02110]                     OID 2.5.29.37.0 (anyExtendedKeyUsage)

As long as the file content is not date dependent, I'm happy :)

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

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

From mullan at openjdk.java.net  Mon Oct 18 13:19:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 18 Oct 2021 13:19:48 GMT
Subject: RFR: 8274721: UnixSystem fails to provide uid,
 gid or groups if no username is available
In-Reply-To: <EN23sCuUiAI8twxMH6vHcWKIECfGHrY9gclRZ9-D-58=.81bebba6-d08b-4719-bb62-6e2b55cad57d@github.com>
References: <EN23sCuUiAI8twxMH6vHcWKIECfGHrY9gclRZ9-D-58=.81bebba6-d08b-4719-bb62-6e2b55cad57d@github.com>
Message-ID: <z-fE_xpfjbMTqDCkZZFHQzykVQIi_kIlHhQX2reS6xg=.4c63bcc9-f58e-4c39-959d-b0c36c4a8f43@github.com>

On Mon, 4 Oct 2021 17:40:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two changes:
> 
> 1. Calculation of groups is put in a separate block.
> 2. Add fallback for uid and gid
> 
> No regression test. Hard to reproduce bud reporter's environment in jtreg.

Marked as reviewed by mullan (Reviewer).

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

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

From weijun at openjdk.java.net  Mon Oct 18 13:28:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 18 Oct 2021 13:28:58 GMT
Subject: Integrated: 8274721: UnixSystem fails to provide uid,
 gid or groups if no username is available
In-Reply-To: <EN23sCuUiAI8twxMH6vHcWKIECfGHrY9gclRZ9-D-58=.81bebba6-d08b-4719-bb62-6e2b55cad57d@github.com>
References: <EN23sCuUiAI8twxMH6vHcWKIECfGHrY9gclRZ9-D-58=.81bebba6-d08b-4719-bb62-6e2b55cad57d@github.com>
Message-ID: <aqoQhd2ZEvn5b0lByF3MHLNwwzT0xLQuHc-pw2aJXvs=.291da3b7-9994-4999-8555-be7f5f7b4a4f@github.com>

On Mon, 4 Oct 2021 17:40:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two changes:
> 
> 1. Calculation of groups is put in a separate block.
> 2. Add fallback for uid and gid
> 
> No regression test. Hard to reproduce bud reporter's environment in jtreg.

This pull request has now been integrated.

Changeset: a619f890
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a619f8909bb074712db22746e785f7485795a8f5
Stats:     47 lines in 1 file changed: 15 ins; 6 del; 26 mod

8274721: UnixSystem fails to provide uid, gid or groups if no username is available

Reviewed-by: mullan

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

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

From hchao at openjdk.java.net  Tue Oct 19 01:09:26 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 01:09:26 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v2]
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <HZIPeKdaX2iTldsvSKGushYGRkaQlnEl1h7sehdw3k8=.ac5b40c7-d31f-4a10-8562-c4b75023991a@github.com>

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

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

  Fix -version in jarsigner and update tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5954/files
  - new: https://git.openjdk.java.net/jdk/pull/5954/files/1d43fe2f..4593b7a8

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

  Stats: 117 lines in 4 files changed: 99 ins; 16 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5954.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5954/head:pull/5954

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

From hchao at openjdk.java.net  Tue Oct 19 01:09:37 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 01:09:37 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v2]
In-Reply-To: <bP6o6CaDJ6qElBaJAyUSBOvxHoyg5Tmy2qhnt0TAj2w=.d5427318-5425-4c68-ad33-fed477de0193@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <bP6o6CaDJ6qElBaJAyUSBOvxHoyg5Tmy2qhnt0TAj2w=.d5427318-5425-4c68-ad33-fed477de0193@github.com>
Message-ID: <GzXlaD9_HIuBrTLMA1rRN7ET5gJO3s7goByRSXBCkfI=.de14c191-83b0-4e8a-a537-0134581254ab@github.com>

On Fri, 15 Oct 2021 13:34:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix -version in jarsigner and update tests
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 348:
> 
>> 346:             }
>> 347:             doPrintVersion();
>> 348:         }
> 
> What happens if `-version` appears elsewhere?
> 
> I tried some other commands. When both `-version` and other arguments are provided, `java` ignores the others and prints out version info. `javac` prints out the version info and compiles as well.
> 
> It's possible that user writes a script or alias that always run the tool with some options (Ex: `-keystore`, `-storepass`, `-verbose`). Maybe we should not fail if `-version` is used with other options (no matter at the beginning or the end).

Fixed so `-version` can be used with other options in jarsigner.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 600:
> 
>> 598:     }
>> 599: 
>> 600:     static void usageTooManyArg() {
> 
> Since the method is only for `-version` and the printed message also mentions "version", maybe it's better to choose a specific name.

Removed this method after the change for the comment as above.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 602:
> 
>> 600:     static void usageTooManyArg() {
>> 601:         System.out.println(rb.getString(
>> 602:                 "Option.should.not.be.specified.for.version"));
> 
> Neither arguments not options should be specified here.

Method was removed.

> test/jdk/sun/security/tools/jarsigner/VersionTest.java line 40:
> 
>> 38:                 .shouldHaveExitValue(0);
>> 39: 
>> 40:         SecurityTools.jarsigner("-version -extraopt")
> 
> You might want to use some legal arguments here, for example, `-version -help`. Otherwise, the error might be because the extra option is not supported. Or, you can check if an expected error message is printed out.

Updated the test as suggested.

> test/jdk/sun/security/tools/keytool/VersionTest.java line 40:
> 
>> 38:                 .shouldHaveExitValue(0);
>> 39: 
>> 40:         SecurityTools.keytool("-version -extraopt")
> 
> Same comment as above.

Done.

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

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

From hchao at openjdk.java.net  Tue Oct 19 01:15:50 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 01:15:50 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner
In-Reply-To: <bP6o6CaDJ6qElBaJAyUSBOvxHoyg5Tmy2qhnt0TAj2w=.d5427318-5425-4c68-ad33-fed477de0193@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <bP6o6CaDJ6qElBaJAyUSBOvxHoyg5Tmy2qhnt0TAj2w=.d5427318-5425-4c68-ad33-fed477de0193@github.com>
Message-ID: <_oY75ropGVymMKy59ztW82A-oE9kIBrtJyJoeUoSGak=.d124f20f-d38e-4149-a16b-06095519cbf6@github.com>

On Fri, 15 Oct 2021 13:49:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
>> 
>> CSR review:
>> https://bugs.openjdk.java.net/browse/JDK-8275174
>
> For the CSR, is it necessary to list the `-help` output change?

@wangweij Thanks for your review! Regarding your CSR comment if it is necessary to list the `-help` output change, as the current keytool manage lists its commands [1], and then I?ve added an entry for `-version` at the end of the list in the CSR. The jarsigner manpage lists the options [2], and I also added an entry for `-version` to its list. Are you suggesting we should add a new output for `-help` in keytool and jarsigner manpages?
[1] https://docs.oracle.com/en/java/javase/17/docs/specs/man/keytool.html#synopsis
[2] https://docs.oracle.com/en/java/javase/17/docs/specs/man/jarsigner.html#synopsis

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

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

From dholmes at openjdk.java.net  Tue Oct 19 02:27:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 19 Oct 2021 02:27:48 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v6]
In-Reply-To: <duQC157aL1XUf9C8J8Q-vNMTHwP6A3fEjkV2xrxVwbg=.dc7740e2-a51f-4431-82b8-41b91dee66ec@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
 <duQC157aL1XUf9C8J8Q-vNMTHwP6A3fEjkV2xrxVwbg=.dc7740e2-a51f-4431-82b8-41b91dee66ec@github.com>
Message-ID: <W__XEfI7Wf_i4EIO--ZF0E8bGFQV1YPRk8OCe9ixLzI=.bad12eed-ac6f-40ca-bfa0-7fcc32ecbd24@github.com>

On Sat, 16 Oct 2021 11:11:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * use `invokeWithArguments` to simplify new test
>  - Add test for liveness check with high-aririty downcalls
>    (make sure that if an exception occurs in a downcall because of liveness,
>    ref count of other resources are left intact).

Hotspot changes seem fine.

Thanks,
David

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

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

From weijun at openjdk.java.net  Tue Oct 19 03:43:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 03:43:50 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v2]
In-Reply-To: <HZIPeKdaX2iTldsvSKGushYGRkaQlnEl1h7sehdw3k8=.ac5b40c7-d31f-4a10-8562-c4b75023991a@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <HZIPeKdaX2iTldsvSKGushYGRkaQlnEl1h7sehdw3k8=.ac5b40c7-d31f-4a10-8562-c4b75023991a@github.com>
Message-ID: <SAkDWDYODJbopclKGmp6kIwuShCCfaLnVbiFvqoXYN0=.d1e7b8f0-bf0a-46ed-99ef-f141b89e4354@github.com>

On Tue, 19 Oct 2021 01:09:26 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
>> 
>> CSR review:
>> https://bugs.openjdk.java.net/browse/JDK-8275174
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix -version in jarsigner and update tests

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

> 312:         if (version) {
> 313:             doPrintVersion();
> 314:         }

So if both `-version` and `file.jar` are provided, jarsigner will both sign the jar and print the version. This is probably OK but I prefer the `java` style that only prints the version.

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

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

From hchao at openjdk.java.net  Tue Oct 19 06:16:20 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 06:16:20 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v3]
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <Bj47F4k55562JchWpUEpfWOxPTN5fWH6ivr1h1hF2b8=.75fdcab2-b639-48e5-9fbc-50314ff3a860@github.com>

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

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

  jarsigner only prints version and ignores other options

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5954/files
  - new: https://git.openjdk.java.net/jdk/pull/5954/files/4593b7a8..c0a71608

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

  Stats: 13 lines in 2 files changed: 4 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5954.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5954/head:pull/5954

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

From hchao at openjdk.java.net  Tue Oct 19 06:16:26 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 06:16:26 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v2]
In-Reply-To: <SAkDWDYODJbopclKGmp6kIwuShCCfaLnVbiFvqoXYN0=.d1e7b8f0-bf0a-46ed-99ef-f141b89e4354@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <HZIPeKdaX2iTldsvSKGushYGRkaQlnEl1h7sehdw3k8=.ac5b40c7-d31f-4a10-8562-c4b75023991a@github.com>
 <SAkDWDYODJbopclKGmp6kIwuShCCfaLnVbiFvqoXYN0=.d1e7b8f0-bf0a-46ed-99ef-f141b89e4354@github.com>
Message-ID: <6DCQOsqAtohBJIFQGJSJVQCfookU78FyVmcY2i-IRr0=.af62c09a-4c75-482a-9339-b554f601fa96@github.com>

On Tue, 19 Oct 2021 03:40:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix -version in jarsigner and update tests
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 314:
> 
>> 312:         if (version) {
>> 313:             doPrintVersion();
>> 314:         }
> 
> So if both `-version` and `file.jar` are provided, jarsigner will both sign the jar and print the version. This is probably OK but I prefer the `java` style that only prints the version.

Ok, change made to have jarsigner to only print the version and ignore other options.

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

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

From hchao at openjdk.java.net  Tue Oct 19 06:26:17 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 06:26:17 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v4]
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

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

  Updated comment in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5954/files
  - new: https://git.openjdk.java.net/jdk/pull/5954/files/c0a71608..e801c6a2

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

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

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

From weijun at openjdk.java.net  Tue Oct 19 13:09:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 13:09:58 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v4]
In-Reply-To: <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>
Message-ID: <YL_CFpubt6_7zm_CqFKoSkf5gAm4kZElyv3JEHd8xjs=.85aeda39-2425-4855-8a0b-1eef9abb7754@github.com>

On Tue, 19 Oct 2021 06:26:17 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
>> 
>> CSR review:
>> https://bugs.openjdk.java.net/browse/JDK-8275174
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comment in test

Marked as reviewed by weijun (Reviewer).

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

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

From weijun at openjdk.java.net  Tue Oct 19 13:12:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 13:12:52 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v4]
In-Reply-To: <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>
Message-ID: <WPIgFS4R1Ig_dVQF96Kg4gKWJLp0MTS6ueUdndFAKAA=.e9a88431-50d3-48b9-b618-1b71e3962338@github.com>

On Tue, 19 Oct 2021 06:26:17 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
>> 
>> CSR review:
>> https://bugs.openjdk.java.net/browse/JDK-8275174
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comment in test

Approved the PR. Thanks. I have a small comment on the CSR.

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

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

From aefimov at openjdk.java.net  Tue Oct 19 13:28:26 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:28:26 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v4]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <oQyboiYcm8oe4KHke029DGp4VCYD3ac00ymAECoW3aE=.6e97bcc6-444f-41ae-9f34-cdb60f0b3b03@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with four additional commits since the last revision:

 - Remove no longer used import from IPSupport
 - Rename IPSupport.hasAddress and update it to use SocketChannel.open
 - Address review comments: javadoc + code cleanup
 - Address resolver bootstraping issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/d302a49a..ac0d2184

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

  Stats: 245 lines in 5 files changed: 180 ins; 35 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

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

From aefimov at openjdk.java.net  Tue Oct 19 13:28:36 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:28:36 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com>
Message-ID: <Jqvh-luZdcfIXQOjD6xTwmC5XQpHY0MbwSfzjO_HVR4=.92574438-a305-4835-9222-f42397b43aa2@github.com>

On Fri, 15 Oct 2021 14:25:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @since tags to new API classes
>>  - Add checks and test for empty stream resolver results
>
> src/java.base/share/classes/java/net/InetAddress.java line 231:
> 
>> 229:  *      The first provider found will be used to instantiate the {@link InetAddressResolver InetAddressResolver}
>> 230:  *      by invoking the {@link InetAddressResolverProvider#get(InetAddressResolverProvider.Configuration)}
>> 231:  *      method. The instantiated {@code InetAddressResolver} will be installed as the system-wide
> 
> Maybe "... method. The **returned** {@code InetAddressResolver} will be installed ..."

Changed as suggested in 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe.

> src/java.base/share/classes/java/net/InetAddress.java line 486:
> 
>> 484:                 return cns;
>> 485:             } finally {
>> 486:                 bootstrapResolver = null;
> 
> This is incorrect. This will set bootstrapResolver to null in the case where you return it at line 468 - which means that a second call will then find it null. I believe you want to set it to null in the finally clause only if you reached line 470. You could achieve this by declaring a local variable - e.g `InetAddressResolver tempResolver = null;` before entering the try-finally then set that variable at line 470 `return tempResolver = bootstrapResolver;` and in finally do `if (tempResolver == null) bootsrapResolver = null;`
> 
> To test this you could try to call e.g. `InetAddress.getByName` twice in succession in your test: I believe it will fail with the code as it stands, but will succeed with my proposed changes...

Good catch, thank you Daniel. Added a test for that and fixed it in cd19ecd63838d3c2b713ed66d41107fe01a2d3e6. Now the `bootstrapResolver` field is set back to `null` in finally block only if a call to `InetAddress.resolver()` entered a resolver initialization part.

> src/java.base/share/classes/java/net/InetAddress.java line 860:
> 
>> 858:                 return host;
>> 859:             }
>> 860:         } catch (RuntimeException | UnknownHostException e) {
> 
> This may deserve a comment: resolver.lookUpHostName and InetAddress.getAllbyName0 delegate to the system-wide resolver, which could be custom, and we treat any unexpected RuntimeException thrown by the provider at that point as we would treat an UnknownHostException or an unmatched host name.

Agree - comment added as part of 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe.

> src/java.base/share/classes/java/net/InetAddress.java line 1063:
> 
>> 1061:         public Stream<InetAddress> lookupAddresses(String host, LookupPolicy policy)
>> 1062:                 throws UnknownHostException {
>> 1063:             Objects.requireNonNull(host);
> 
> Should we also double check that `policy` is not null? Or maybe assert it?

Yes, we should since custom resolvers might call the built-in one with `null` - added non-null check in 648e65b .

> src/java.base/share/classes/java/net/InetAddress.java line 1203:
> 
>> 1201:                         + " as hosts file " + hostsFile + " not found ");
>> 1202:             }
>> 1203:             // Check number of found addresses:
> 
> I wonder if the logic here could be simplified by first checking whether only IPv4 addresses are requested, and then if only IPv6 addresses are requested. 
> 
> That is - evacuate the simple cases first and then only deal with the more complex case where you have to combine the two lists...

Tried to simplify it in 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe

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

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

From aefimov at openjdk.java.net  Tue Oct 19 13:31:09 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:31:09 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
Message-ID: <peA62oveRsjHAOX2g6suheZBJUGhSvtCZBvaBI86tJ0=.b03e4ae1-497e-472a-8e42-1dca6f171aca@github.com>

On Fri, 15 Oct 2021 17:09:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @since tags to new API classes
>>  - Add checks and test for empty stream resolver results
>
> test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38:
> 
>> 36:         String localHostName;
>> 37:         try {
>> 38:             localHostName = InetAddress.getLocalHost().getHostName();
> 
> Try to call InetAddress.getLocalHost().getHostName(); twice here.

New `BootstrapResolverUsageTest` test is added to trigger the bootstrap resolver problem. `InetAddress.getByName` calls with unique names are used instead of `InetAddress.getLocalHost()` to avoid caching of LHN resolution results. Added in cd19ecd63838d3c2b713ed66d41107fe01a2d3e6.

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

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

From aefimov at openjdk.java.net  Tue Oct 19 13:34:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:34:50 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
Message-ID: <JqjubOFCvCAg1FTnnN1ihgTbW53CXr0nlQ2E-2vhl0U=.44cfdf67-ed8d-41ce-8c2c-d725f5b07f38@github.com>

On Fri, 15 Oct 2021 17:19:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @since tags to new API classes
>>  - Add checks and test for empty stream resolver results
>
> test/lib/jdk/test/lib/net/IPSupport.java line 88:
> 
>> 86:             } catch (SocketException se2) {
>> 87:                 return false;
>> 88:             }
> 
> The implementation of this method now conflicts with its name. Maybe we should pass a `Class<? extends InetAddress>`  as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here.

Thanks for a good suggestion: renamed to `isSupported`, changed parameter type to `Class<? extends InetAddress> addressType` and updated it to use `SocketChannel.open(ProtocolFamily pf)` [API](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/channels/SocketChannel.html#open(java.net.ProtocolFamily)) added in `15` to check if the plafrom supports addresses of specified address type. Pushed as 95a21e57fbe8be147d23e6a6901ae307e8237cbb.
All new tests (especially `LookupPolicyMappingTest`) pass in environment with `IPv6` addresses disabled.

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

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

From aefimov at openjdk.java.net  Tue Oct 19 13:56:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:56:50 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
 <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
 <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com>
Message-ID: <gqmwg7-KzqmaxKnLxgFTmvOzQQZai6mh4IIJNtCUbug=.db07e7f7-79a8-4338-b5d7-d46fbd8ae884@github.com>

On Sun, 17 Oct 2021 21:39:06 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> I think that a hostname is constant while a host is up, but it can be changed, and when changed a host restart is required. I don't think it is quite as dynamic as has been suggested, but I open to correction.

It is possible to change a host name without host restart. What has been tested:
- Checked O/S type - Linux
- `hostnamectl` cmd was used to change a host name
- In output below there is only one `jshell` instance running.


jshell> InetAddress.getLocalHost()
$1 ==> test-host-name/192.168.0.155

$ hostnamectl set-hostname 'test-host-name-changed'

# Need to sleep for 5 seconds since local host
# is cached for 5 seconds since last resolution
$ sleep 5

jshell> InetAddress.getLocalHost()
$2 ==> test-host-name-changed/192.168.0.155


I believe it proves that we need to treat a host name as dynamically changing information.

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

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

From weijun at openjdk.java.net  Tue Oct 19 14:57:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 14:57:50 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key
In-Reply-To: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
Message-ID: <MIUM9R34hnvxbR5xGslGQ7oDMVZjnw9_UhkW5HGXHY0=.a7b2d905-cbb4-47ef-89c1-b17cc066925b@github.com>

On Wed, 13 Oct 2021 13:42:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
> 
> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
> 
> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
> 
> - AlgorithmDecomposer now stores the canonical algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

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

> 46:                "SHA-384", "SHA384", "SHA-512", "SHA512", "SHA-512/224",
> 47:                "SHA512/224", "SHA-512/256", "SHA512/256");
> 48: 

Do you want to support the "SHA" -> "SHA1" mapping?

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

> 194:     static String canonicalName(String algorithm) {
> 195:         return CANONICAL_NAME.getOrDefault(algorithm, algorithm);
> 196:     }

I'm not sure if `canonicalName` is good. Normally, we say "SHA-1" is the standard name but this method changes it to "SHA1".

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

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

From mullan at openjdk.java.net  Tue Oct 19 15:52:52 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Oct 2021 15:52:52 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key
In-Reply-To: <MIUM9R34hnvxbR5xGslGQ7oDMVZjnw9_UhkW5HGXHY0=.a7b2d905-cbb4-47ef-89c1-b17cc066925b@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <MIUM9R34hnvxbR5xGslGQ7oDMVZjnw9_UhkW5HGXHY0=.a7b2d905-cbb4-47ef-89c1-b17cc066925b@github.com>
Message-ID: <CvKaNCh62_YTYA-BHDMFA5d4cgpp0Nt5e1dLKB2dSNU=.494bfa01-14ad-41cb-84f0-12e0acb46613@github.com>

On Tue, 19 Oct 2021 14:34:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
>> 
>> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
>> 
>> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
>> 
>> - AlgorithmDecomposer now stores the canonical algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.
>
> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 48:
> 
>> 46:                "SHA-384", "SHA384", "SHA-512", "SHA512", "SHA-512/224",
>> 47:                "SHA512/224", "SHA-512/256", "SHA512/256");
>> 48: 
> 
> Do you want to support the "SHA" -> "SHA1" mapping?

These should be standard digest names as specified by the disabled algorithm security property syntax. SHA is an alias.

> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 196:
> 
>> 194:     static String canonicalName(String algorithm) {
>> 195:         return CANONICAL_NAME.getOrDefault(algorithm, algorithm);
>> 196:     }
> 
> I'm not sure if `canonicalName` is good. Normally, we say "SHA-1" is the standard name but this method changes it to "SHA1".

Right, it's really just about using consistent message digest names so that it can match for example, "SHA-1" and also "SHA1withRSA". I'll change the name to something else.

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

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

From weijun at openjdk.java.net  Tue Oct 19 16:16:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 16:16:50 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key
In-Reply-To: <CvKaNCh62_YTYA-BHDMFA5d4cgpp0Nt5e1dLKB2dSNU=.494bfa01-14ad-41cb-84f0-12e0acb46613@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <MIUM9R34hnvxbR5xGslGQ7oDMVZjnw9_UhkW5HGXHY0=.a7b2d905-cbb4-47ef-89c1-b17cc066925b@github.com>
 <CvKaNCh62_YTYA-BHDMFA5d4cgpp0Nt5e1dLKB2dSNU=.494bfa01-14ad-41cb-84f0-12e0acb46613@github.com>
Message-ID: <V7EJ22JaVqp37LfmgHmi4ORksfmyq-_hDzF77ZXvo38=.28c178b4-1e00-4682-9e8e-464282d73166@github.com>

On Tue, 19 Oct 2021 15:26:52 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 48:
>> 
>>> 46:                "SHA-384", "SHA384", "SHA-512", "SHA512", "SHA-512/224",
>>> 47:                "SHA512/224", "SHA-512/256", "SHA512/256");
>>> 48: 
>> 
>> Do you want to support the "SHA" -> "SHA1" mapping?
>
> These should be standard digest names as specified by the disabled algorithm security property syntax. SHA is an alias.

OK, I saw the default in `CANONICAL_NAME.getOrDefault(algorithm, algorithm)` and thought non-standard names are also allowed.

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

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

From weijun at openjdk.java.net  Tue Oct 19 16:28:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 16:28:14 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not
 depend on Security Manager APIs
Message-ID: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>

New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.

In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.

User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).

Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

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

Commit messages:
 - deprecate doAs, use new APIs in src and test
 - Merge branch 'master' into 8267108
 - old untouched. new same as old by default, or use TL when a sys prop is set
 - multiple implementations
 - 8267108: Alternate Subject.getSubject API that does not depend on Security Manager APIs

Changes: https://git.openjdk.java.net/jdk/pull/5024/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267108
  Stats: 653 lines in 20 files changed: 452 ins; 92 del; 109 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5024.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5024/head:pull/5024

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

From mullan at openjdk.java.net  Tue Oct 19 16:28:17 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Oct 2021 16:28:17 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <xVikFKKYGoJaXXzRLOwPSdLgGehwOhWv_QctornzAqE=.e33cce50-4ff9-4cce-aa9b-bdf23a7e9a82@github.com>

On Thu, 5 Aug 2021 20:10:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

Max, I am thinking now that we don't need to make the new `Subject.callAs` method call `Subject.doAs` if an SM is not disallowed, and instead just use the TL solution. However, we still want `Subject.current` to support both the SM and TL case as that would be typically called by library code. My reasoning is that applications that are calling `doAs` and depending on the SM will need to find another solution anyway, or stay on the older releases. We probably don't want them to transition to the new `callAs` method (which is not deprecated) and then suddenly it stops working when the SM is removed.

src/java.base/share/classes/javax/security/auth/Subject.java line 334:

> 332: 
> 333:     private static enum SubjectStorage {
> 334:         ACC, THREAD_LOCAL, SCOPE_LOCAL

I would leave out SCOPE_LOCAL for now.

src/java.base/share/classes/javax/security/auth/Subject.java line 352:

> 350:             };
> 351: 
> 352:     /**

Some initial comments below. I think this will take a few iterations to refine the text.

src/java.base/share/classes/javax/security/auth/Subject.java line 353:

> 351: 
> 352:     /**
> 353:      * Return the current installed subject.

Nit. I know other accessor methods in Subject use the word "Return", but I think "Returns" is more grammatically correct and reads better when describing what this method does. Also just say "Returns the current subject."

src/java.base/share/classes/javax/security/auth/Subject.java line 355:

> 353:      * Return the current installed subject.
> 354:      * <p>
> 355:      * The current installed subject is installed by the {@link #call}

s/The current installed subject/The current subject/

I am not sure "installed" is the best term to use, as I equate that most commonly with installing software on your disk. Maybe "set" or "registered"?

src/java.base/share/classes/javax/security/auth/Subject.java line 357:

> 355:      * The current installed subject is installed by the {@link #call}
> 356:      * or {@link #run} method. When either {@code call(subject, action)} or
> 357:      * {@code run(subject, action)} is called, {@code action} is executed

Should this be `callAs` or `doAs`?

src/java.base/share/classes/javax/security/auth/Subject.java line 359:

> 357:      * {@code run(subject, action)} is called, {@code action} is executed
> 358:      * with {@code subject} as its current installed subject which can be
> 359:      * retrieved by this method. After {@code action} is finished, the current

Just say "current subject" instead of "current installed subject" throughout. Once you explain how the current subject is installed (or registered), there is no need to repeat that term.

src/java.base/share/classes/javax/security/auth/Subject.java line 361:

> 359:      * retrieved by this method. After {@code action} is finished, the current
> 360:      * installed subject is reset to its previous value. The current installed
> 361:      * subject is {@code null} before the first call of {@code call()}

It is also null if there are no active `call` or `doAs` methods, right?

src/java.base/share/classes/javax/security/auth/Subject.java line 369:

> 367:      *
> 368:      * @implNote
> 369:      * In this implementation, if a {@code SecurityManager} is allowed,

We should probably link "allowed" to the section in the `SecurityManager` API that describes the behavior. Perhaps we could see if we could add a hyperlink.

src/java.base/share/classes/javax/security/auth/Subject.java line 373:

> 371:      * {@code getSubject(AccessController.getContext())}. Otherwise, the current
> 372:      * installed subject is stored in an inheritable {@code ThreadLocal}.
> 373:      * Also, each of the various {@code doAs(subject, action)} and

It's not clear if the "Also ..." sentence is only for the non-SM case. I think you could just use one sentence here, replace "Also, each" with "and each ...".

src/java.base/share/classes/javax/security/auth/Subject.java line 482:

> 480:      * @since 18
> 481:      */
> 482:     public static <T> T getAs(final Subject subject,

Would prefer if we just have one `callAs` method. It might be less of an issue now if we don't need to support the SM case.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 406:

> 404: 
> 405:     /**
> 406:      * When a security manager is allowed. This is true if the system

Suggest rewording as: "Returns true if a security manager is allowed. This method returns true ..."

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 407:

> 405:     /**
> 406:      * When a security manager is allowed. This is true if the system
> 407:      * property java.security.manager is set to any value other than "disabled".

s/disabled/disallow/

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 408:

> 406:      * When a security manager is allowed. This is true if the system
> 407:      * property java.security.manager is set to any value other than "disabled".
> 408:      * @return

Probably don't need `@return` as it is an internal method.

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

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

From weijun at openjdk.java.net  Tue Oct 19 16:28:28 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 16:28:28 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs
In-Reply-To: <xVikFKKYGoJaXXzRLOwPSdLgGehwOhWv_QctornzAqE=.e33cce50-4ff9-4cce-aa9b-bdf23a7e9a82@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <xVikFKKYGoJaXXzRLOwPSdLgGehwOhWv_QctornzAqE=.e33cce50-4ff9-4cce-aa9b-bdf23a7e9a82@github.com>
Message-ID: <8gog1eBq00z6B4roNVe-QZEvqW0NbASJSj7RR6JLC6I=.56ada86d-e235-41ac-871f-e95b7a0f20b9@github.com>

On Wed, 18 Aug 2021 15:01:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 353:
> 
>> 351: 
>> 352:     /**
>> 353:      * Return the current installed subject.
> 
> Nit. I know other accessor methods in Subject use the word "Return", but I think "Returns" is more grammatically correct and reads better when describing what this method does. Also just say "Returns the current subject."

I'll use "returns".

> src/java.base/share/classes/javax/security/auth/Subject.java line 355:
> 
>> 353:      * Return the current installed subject.
>> 354:      * <p>
>> 355:      * The current installed subject is installed by the {@link #call}
> 
> s/The current installed subject/The current subject/
> 
> I am not sure "installed" is the best term to use, as I equate that most commonly with installing software on your disk. Maybe "set" or "registered"?

I thought about "associated" but cannot precisely describe what it it is associated to. The "install" word actually comes from "install a SecurityManager with the `System::setSecurityManager` method".

I'll use "current object".

> src/java.base/share/classes/javax/security/auth/Subject.java line 357:
> 
>> 355:      * The current installed subject is installed by the {@link #call}
>> 356:      * or {@link #run} method. When either {@code call(subject, action)} or
>> 357:      * {@code run(subject, action)} is called, {@code action} is executed
> 
> Should this be `callAs` or `doAs`?

Correct, it should be `callAs` and `getAs`.

> src/java.base/share/classes/javax/security/auth/Subject.java line 359:
> 
>> 357:      * {@code run(subject, action)} is called, {@code action} is executed
>> 358:      * with {@code subject} as its current installed subject which can be
>> 359:      * retrieved by this method. After {@code action} is finished, the current
> 
> Just say "current subject" instead of "current installed subject" throughout. Once you explain how the current subject is installed (or registered), there is no need to repeat that term.

I see what you mean, it's only "current subject", but we can use a verb to describe how it's set.

> src/java.base/share/classes/javax/security/auth/Subject.java line 361:
> 
>> 359:      * retrieved by this method. After {@code action} is finished, the current
>> 360:      * installed subject is reset to its previous value. The current installed
>> 361:      * subject is {@code null} before the first call of {@code call()}
> 
> It is also null if there are no active `call` or `doAs` methods, right?

Yes, is this implied by "reset to its previous value"?

> src/java.base/share/classes/javax/security/auth/Subject.java line 369:
> 
>> 367:      *
>> 368:      * @implNote
>> 369:      * In this implementation, if a {@code SecurityManager} is allowed,
> 
> We should probably link "allowed" to the section in the `SecurityManager` API that describes the behavior. Perhaps we could see if we could add a hyperlink.

Precisely, this "allowed" covers "-Djava.security.manager" set to "allow", "", and a class name. I should probably be more precise.

> src/java.base/share/classes/javax/security/auth/Subject.java line 373:
> 
>> 371:      * {@code getSubject(AccessController.getContext())}. Otherwise, the current
>> 372:      * installed subject is stored in an inheritable {@code ThreadLocal}.
>> 373:      * Also, each of the various {@code doAs(subject, action)} and
> 
> It's not clear if the "Also ..." sentence is only for the non-SM case. I think you could just use one sentence here, replace "Also, each" with "and each ...".

Oops, I think I made a mistake here. No matter if there's SM, `current` and `getSubject` returns the same thing. I should have said "the current subject" is stored inside "current AccessControlContext" if SM is on or a `ThreadLocal` is not. I'll rephrase.

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

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

From weijun at openjdk.java.net  Tue Oct 19 16:28:31 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 16:28:31 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <JBi98_4gYaTIgPRXMbbVc5pII_1uooylugkC8mEZ7Fw=.8bfc8350-979f-4d30-b0a3-58e8827d9447@github.com>

On Thu, 5 Aug 2021 20:10:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

test/jdk/javax/security/auth/Subject/FromACC.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Oops, no Classpath exception for this test.

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

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

From hchao at openjdk.java.net  Tue Oct 19 16:31:18 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 16:31:18 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v5]
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <LSSoUEM9kl_cwMuqtYggyfHnpBrTfmEASQYGBhXhxTs=.ed2b9c6e-4228-46f9-a2b3-9a8ad749e864@github.com>

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

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

  fullusage test change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5954/files
  - new: https://git.openjdk.java.net/jdk/pull/5954/files/e801c6a2..e6b360e7

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

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

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

From hchao at openjdk.java.net  Tue Oct 19 16:31:18 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 16:31:18 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v4]
In-Reply-To: <WPIgFS4R1Ig_dVQF96Kg4gKWJLp0MTS6ueUdndFAKAA=.e9a88431-50d3-48b9-b618-1b71e3962338@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>
 <WPIgFS4R1Ig_dVQF96Kg4gKWJLp0MTS6ueUdndFAKAA=.e9a88431-50d3-48b9-b618-1b71e3962338@github.com>
Message-ID: <8h1AyuqCxNuuVRL9VJUMsbYo4twWR2bW-llldL0aCpA=.2596d0ed-b909-4aac-bbed-7a968cc07592@github.com>

On Tue, 19 Oct 2021 13:10:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated comment in test
>
> Approved the PR. Thanks. I have a small comment on the CSR.

@wangweij Thanks for reviewing the CSR and code changes.

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

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

From hchao at openjdk.java.net  Tue Oct 19 16:49:53 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 19 Oct 2021 16:49:53 GMT
Subject: RFR: 8272163: Add -version option to keytool and jarsigner [v4]
In-Reply-To: <WPIgFS4R1Ig_dVQF96Kg4gKWJLp0MTS6ueUdndFAKAA=.e9a88431-50d3-48b9-b618-1b71e3962338@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
 <TwTo9lg5OdiklCSgipdUtY3lEs-6O9vBW_X7S65ZzT8=.56565ca8-d4ae-4d3c-97d5-b1ad14e99af9@github.com>
 <WPIgFS4R1Ig_dVQF96Kg4gKWJLp0MTS6ueUdndFAKAA=.e9a88431-50d3-48b9-b618-1b71e3962338@github.com>
Message-ID: <VW0Z1mg2u4PXCa1yHkmGsdAxCq4i0Lbh7_O94yuVClY=.e959e176-97af-4141-b9ac-6c142da414f9@github.com>

On Tue, 19 Oct 2021 13:10:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated comment in test
>
> Approved the PR. Thanks. I have a small comment on the CSR.

@wangweij Updated the CSR with your comment. Thanks!

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

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

From dfuchs at openjdk.java.net  Tue Oct 19 17:05:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 19 Oct 2021 17:05:49 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v4]
In-Reply-To: <oQyboiYcm8oe4KHke029DGp4VCYD3ac00ymAECoW3aE=.6e97bcc6-444f-41ae-9f34-cdb60f0b3b03@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <oQyboiYcm8oe4KHke029DGp4VCYD3ac00ymAECoW3aE=.6e97bcc6-444f-41ae-9f34-cdb60f0b3b03@github.com>
Message-ID: <YvnQpNAUaE2NBs0QQfFAoCk8_I8lnUq2GF8j9SD8sn0=.20d76870-6faf-4eb4-94d6-179717118428@github.com>

On Tue, 19 Oct 2021 13:28:26 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove no longer used import from IPSupport
>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>  - Address review comments: javadoc + code cleanup
>  - Address resolver bootstraping issue

Changes look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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

From ascarpino at openjdk.java.net  Tue Oct 19 17:18:55 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 19 Oct 2021 17:18:55 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key
In-Reply-To: <CvKaNCh62_YTYA-BHDMFA5d4cgpp0Nt5e1dLKB2dSNU=.494bfa01-14ad-41cb-84f0-12e0acb46613@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <MIUM9R34hnvxbR5xGslGQ7oDMVZjnw9_UhkW5HGXHY0=.a7b2d905-cbb4-47ef-89c1-b17cc066925b@github.com>
 <CvKaNCh62_YTYA-BHDMFA5d4cgpp0Nt5e1dLKB2dSNU=.494bfa01-14ad-41cb-84f0-12e0acb46613@github.com>
Message-ID: <Le_SjD5cncl05oEVnYi-YN5hm5rTqc9Nc2vNZtx7FUM=.a5bbd813-36b7-49f5-b509-88d01cc0d5aa@github.com>

On Tue, 19 Oct 2021 15:48:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 196:
>> 
>>> 194:     static String canonicalName(String algorithm) {
>>> 195:         return CANONICAL_NAME.getOrDefault(algorithm, algorithm);
>>> 196:     }
>> 
>> I'm not sure if `canonicalName` is good. Normally, we say "SHA-1" is the standard name but this method changes it to "SHA1".
>
> Right, it's really just about using consistent message digest names so that it can match for example, "SHA-1" and also "SHA1withRSA". I'll change the name to something else.

Was the reason for this change that hashName("RSASSA-PSS") was returning an RSASSAPSS?

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

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

From mullan at openjdk.java.net  Tue Oct 19 17:18:55 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Oct 2021 17:18:55 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key
In-Reply-To: <Le_SjD5cncl05oEVnYi-YN5hm5rTqc9Nc2vNZtx7FUM=.a5bbd813-36b7-49f5-b509-88d01cc0d5aa@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <MIUM9R34hnvxbR5xGslGQ7oDMVZjnw9_UhkW5HGXHY0=.a7b2d905-cbb4-47ef-89c1-b17cc066925b@github.com>
 <CvKaNCh62_YTYA-BHDMFA5d4cgpp0Nt5e1dLKB2dSNU=.494bfa01-14ad-41cb-84f0-12e0acb46613@github.com>
 <Le_SjD5cncl05oEVnYi-YN5hm5rTqc9Nc2vNZtx7FUM=.a5bbd813-36b7-49f5-b509-88d01cc0d5aa@github.com>
Message-ID: <Qbd0_v4d2xljY-Zw0RjthaiiUQmtdNvyIgBs-4uM1Zs=.f1beccbb-6400-499b-b8df-4b158d8adc25@github.com>

On Tue, 19 Oct 2021 17:15:48 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Right, it's really just about using consistent message digest names so that it can match for example, "SHA-1" and also "SHA1withRSA". I'll change the name to something else.
>
> Was the reason for this change that hashName("RSASSA-PSS") was returning an RSASSAPSS?

Yes.

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

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

From valeriep at openjdk.java.net  Tue Oct 19 20:21:01 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 19 Oct 2021 20:21:01 GMT
Subject: RFR: 8275003: Suppress warnings on non-serializable non-transient
 instance fields in windows mscapi
In-Reply-To: <eIHieUl8AW6VJlGr6UTukOsLJAny4myd752iz2ghIrU=.d89917cc-7678-4e82-8384-c3e41f994354@github.com>
References: <eIHieUl8AW6VJlGr6UTukOsLJAny4myd752iz2ghIrU=.d89917cc-7678-4e82-8384-c3e41f994354@github.com>
Message-ID: <cq-a8dcA8WzvGHT38Z-f1bkKhJlypY4F9JBC_2mBaOs=.0c6e460a-c688-4a40-b55a-6471547b419b@github.com>

On Sat, 9 Oct 2021 19:41:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Analogous to other recent cleanups like JDK-8274393, suppress warnings for serialization-related issues in the windows mscapi code.

Looks fine. Thanks!

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

Marked as reviewed by valeriep (Reviewer).

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

From weijun at openjdk.java.net  Tue Oct 19 20:20:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 20:20:49 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
 [v2]
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <NVdkwak1aTehYjpA0EbtSOeLa-pyNCF2tYz6sBMAKf8=.bc11ebe4-a6b3-4680-916e-6843fa2e688b@github.com>

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

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

  use a standard name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5948/files
  - new: https://git.openjdk.java.net/jdk/pull/5948/files/0ee2c53c..285ed1b3

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

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

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

From mullan at openjdk.java.net  Tue Oct 19 20:20:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Oct 2021 20:20:59 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
 [v2]
In-Reply-To: <NVdkwak1aTehYjpA0EbtSOeLa-pyNCF2tYz6sBMAKf8=.bc11ebe4-a6b3-4680-916e-6843fa2e688b@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <NVdkwak1aTehYjpA0EbtSOeLa-pyNCF2tYz6sBMAKf8=.bc11ebe4-a6b3-4680-916e-6843fa2e688b@github.com>
Message-ID: <UJbbUQerpjeKoTE_0EFCKlCaQaOcpOa4x4xMs0NhwxM=.999c5d23-20fc-4490-be29-7fda050bc56b@github.com>

On Tue, 19 Oct 2021 19:48:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use a standard name

Marked as reviewed by mullan (Reviewer).

make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 54:

> 52:     public static void store(String dir, OutputStream stream) throws Exception {
> 53: 
> 54:         CertificateFactory cf = CertificateFactory.getInstance("X509");

Nit: better to use the standard name here: "X.509".

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

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

From weijun at openjdk.java.net  Tue Oct 19 20:21:23 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 20:21:23 GMT
Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12
 [v2]
In-Reply-To: <UJbbUQerpjeKoTE_0EFCKlCaQaOcpOa4x4xMs0NhwxM=.999c5d23-20fc-4490-be29-7fda050bc56b@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
 <NVdkwak1aTehYjpA0EbtSOeLa-pyNCF2tYz6sBMAKf8=.bc11ebe4-a6b3-4680-916e-6843fa2e688b@github.com>
 <UJbbUQerpjeKoTE_0EFCKlCaQaOcpOa4x4xMs0NhwxM=.999c5d23-20fc-4490-be29-7fda050bc56b@github.com>
Message-ID: <of1CeLg_-I-QhOi17I6ngJUFOfnArPjANH746Q5IqqY=.feffdfd5-53dc-4ef6-82d9-b2dc6a7f258d@github.com>

On Tue, 19 Oct 2021 18:49:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use a standard name
>
> make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 54:
> 
>> 52:     public static void store(String dir, OutputStream stream) throws Exception {
>> 53: 
>> 54:         CertificateFactory cf = CertificateFactory.getInstance("X509");
> 
> Nit: better to use the standard name here: "X.509".

OK.

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

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

From mullan at openjdk.java.net  Tue Oct 19 20:32:21 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Oct 2021 20:32:21 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v2]
In-Reply-To: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
Message-ID: <X76Fq_nQbQ8qgFlA39O-rFgKxuMQjxE3w2I67mGnyUg=.d8fc032b-350d-4c25-b79a-c819ddc1af10@github.com>

> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
> 
> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
> 
> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
> 
> - AlgorithmDecomposer now stores the canonical algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

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

  - Changed names of AlgorithmDecomposer.canonicalName and decomposeOneHashName
  methods.
  - Changed other code in AlgorithmDecomposer to use DECOMPOSED_DIGEST_NAMES
  Map instead of hardcoding algorithm names.
  - Changed AlgorithmChecker.trySetTrustAnchor to set trustedPubKey field so that
  constraints on the key algorithm and size are checked in the check() method if
  the constraints are an instanceof DisabledAlgorithmConstraints.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5928/files
  - new: https://git.openjdk.java.net/jdk/pull/5928/files/27045940..cf5a4d7f

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

  Stats: 73 lines in 3 files changed: 12 ins; 32 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5928/head:pull/5928

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

From weijun at openjdk.java.net  Tue Oct 19 20:52:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 19 Oct 2021 20:52:43 GMT
Subject: Integrated: 8275252: Migrate cacerts from JKS to password-less PKCS12
In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>
Message-ID: <gke4AqNF5SV6i4zlZBfQQ2mcap43PDtxhSigDCUbgiY=.cb542435-5702-482f-a453-cd4ff5568889@github.com>

On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside.

This pull request has now been integrated.

Changeset: bd2b41dd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bd2b41dd7062c50f3aaebec2137d5fdd9546c120
Stats:     82 lines in 3 files changed: 2 ins; 69 del; 11 mod

8275252: Migrate cacerts from JKS to password-less PKCS12

Reviewed-by: erikj, ihse, mullan

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

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

From valeriep at openjdk.java.net  Tue Oct 19 20:55:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 19 Oct 2021 20:55:40 GMT
Subject: Integrated: 8264849: Add KW and KWP support to PKCS11 provider
In-Reply-To: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
References: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@github.com>
Message-ID: <UbRQHArQj1KPUtP_0MvBTT26vexRHj8AKBrPdSJCXeQ=.56f99100-ee6c-4238-bd8c-bef0a92df97c@github.com>

On Fri, 17 Sep 2021 23:22:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes support to SunPKCS11 provider?
> 
> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which is the CipherSpi impl for the native PKCS11 key wrap mechanisms. When testing against NSS library, it seems that they only support the single part enc/dec PKCS11 APIs, so have to use a new class as existing P11Cipher class relies on the multi part enc/dec PKCS11 APIs and do not support key wrapping/unwrapping.
> 
> The rest are minor code refactoring and updates for the PKCS11 Exception class.
> The new regression tests are adapted from existing key wrap regression tests for SunJCE provider.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: e63c1486
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e63c1486dc00ee64dea1a76b5a44e34f06eb144f
Stats:     2135 lines in 17 files changed: 2036 ins; 46 del; 53 mod

8264849: Add KW and KWP support to PKCS11 provider

Reviewed-by: ascarpino

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

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

From darcy at openjdk.java.net  Tue Oct 19 20:57:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 19 Oct 2021 20:57:09 GMT
Subject: Integrated: 8275003: Suppress warnings on non-serializable
 non-transient instance fields in windows mscapi
In-Reply-To: <eIHieUl8AW6VJlGr6UTukOsLJAny4myd752iz2ghIrU=.d89917cc-7678-4e82-8384-c3e41f994354@github.com>
References: <eIHieUl8AW6VJlGr6UTukOsLJAny4myd752iz2ghIrU=.d89917cc-7678-4e82-8384-c3e41f994354@github.com>
Message-ID: <z2IHuUovcgM0-HfYW9SaTWCl6zy7zKqdsqB7UxqJnC0=.33f2fe88-7f12-4cec-9687-c5c41eff88da@github.com>

On Sat, 9 Oct 2021 19:41:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Analogous to other recent cleanups like JDK-8274393, suppress warnings for serialization-related issues in the windows mscapi code.

This pull request has now been integrated.

Changeset: 926966be
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/926966be7ad91d2b4a750583c78721b2cdb26981
Stats:     5 lines in 2 files changed: 2 ins; 0 del; 3 mod

8275003: Suppress warnings on non-serializable non-transient instance fields in windows mscapi

Reviewed-by: valeriep

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

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

From weijun at openjdk.java.net  Wed Oct 20 02:16:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 20 Oct 2021 02:16:30 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
Message-ID: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>

Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.

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

Commit messages:
 - 8225181: KeyStore should have a getAttributes method

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

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

From ascarpino at openjdk.java.net  Wed Oct 20 03:28:07 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 20 Oct 2021 03:28:07 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v2]
In-Reply-To: <X76Fq_nQbQ8qgFlA39O-rFgKxuMQjxE3w2I67mGnyUg=.d8fc032b-350d-4c25-b79a-c819ddc1af10@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <X76Fq_nQbQ8qgFlA39O-rFgKxuMQjxE3w2I67mGnyUg=.d8fc032b-350d-4c25-b79a-c819ddc1af10@github.com>
Message-ID: <C2PnAI53WQsM9JobHBuj4veh8nON8TACPvGMg2DEA9E=.c32b1911-4f45-47b3-8188-eded9865ccd3@github.com>

On Tue, 19 Oct 2021 20:32:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
>> 
>> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
>> 
>> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
>> 
>> - AlgorithmDecomposer now stores the canonical algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Changed names of AlgorithmDecomposer.canonicalName and decomposeOneHashName
>   methods.
>   - Changed other code in AlgorithmDecomposer to use DECOMPOSED_DIGEST_NAMES
>   Map instead of hardcoding algorithm names.
>   - Changed AlgorithmChecker.trySetTrustAnchor to set trustedPubKey field so that
>   constraints on the key algorithm and size are checked in the check() method if
>   the constraints are an instanceof DisabledAlgorithmConstraints.

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

> 104:         // "SHA-256" and "SHA256" to make the right constraint checking.
> 105: 
> 106:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {

If you're going to change this code, you can save me a PR if you surround this by "if (algorithm.contains("SHA") {  ...  }"
Its a perf change to eliminate the unnecessary map lookups when SHA isn't in the algorithm string

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

> 156:         Set<String> elements = decomposeImpl(algorithm);
> 157: 
> 158:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {

Same "if (algorithm.contains("SHA") { ... }" comment as above

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

> 157: 
> 158:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {
> 159:             hasLoop(elements, e.getKey(), e.getValue());

I think it's worth merging the contents of hasLoop() into this for loop.  This is the only method calling hasLoop() and the extra method calls are not useful.  Your addition DECOMPOSED_DIGEST_NAMES makes a merger a more reasonable solution now than before.

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

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

From michael.osipov at siemens.com  Wed Oct 20 08:03:37 2021
From: michael.osipov at siemens.com (Osipov, Michael (LDA IT PLM))
Date: Wed, 20 Oct 2021 10:03:37 +0200
Subject: Java ignores/errors canonicalized principals (NT-PRINCIPAL) from
 Active Directory
Message-ID: <0b9c7c31-bf21-03f0-9cae-a16f27f3f29b@siemens.com>

Hi folks,

we have recently noticed the following with Java's kinit (tested with 
Zulu 8 and 13, code is identical in 18 as well):

> C:\Users\osipovmi>kinit osipovmi at ad001.siemens.net

I have intentionally written the realm in lowercase to rely on 
canonicalization of the AD KDC. krb5.conf contains "canonicalize = true" 
as well.

Wireshark shows me in the AS-REQ:
as-req/req-body/sname: name-type KRB5-NT-SRV-INST (2), sname-string (2): 
krbtgt and ad001.siemens.net

AS-REP:
as-rep/ticket/sname: name-type KRB5-NT-SRV-INST (2), sname-string (2): 
krbtgt and AD001.SIEMENS.NET

Hence, the KDC has properly canonicalized the sname. Java gives me:

> Exception: krb_error 41 Message stream modified (41) Message stream modified
> KrbException: Message stream modified (41)
>         at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:55)
>         at sun.security.krb5.KrbAsRep.decrypt(KrbAsRep.java:159)
>         at sun.security.krb5.KrbAsRep.decryptUsingPassword(KrbAsRep.java:139)
>         at sun.security.krb5.KrbAsReqBuilder.resolve(KrbAsReqBuilder.java:312)
>         at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:498)
>         at sun.security.krb5.internal.tools.Kinit.acquire(Kinit.java:248)
>         at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:134)
>         at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:96)

Referrals aren't involved here, same realm.
The failing code block is from:
* 
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/9a751dc19fae78ce58fb0eb176522070c992fb6f/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java#L58-L71
* 
https://github.com/AdoptOpenJDK/openjdk-jdk/blob/ff4997014fe5462dca2b313f3f483400ffee5b62/src/java.security.jgss/share/classes/sun/security/krb5/KrbKdcRep.java#L58-L71

>         // sname change in TGS-REP is allowed only if client
>         // sent CANONICALIZE and new sname is a referral of
>         // the form krbtgt/TO-REALM.COM at FROM-REALM.COM.
>         if (!req.reqBody.sname.equals(rep.encKDCRepPart.sname)) {
>             String[] snameStrings = rep.encKDCRepPart.sname.getNameStrings();
>             if (isAsReq || !req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) ||
>                     snameStrings == null || snameStrings.length != 2 ||
>                     !snameStrings[0].equals(PrincipalName.TGS_DEFAULT_SRV_NAME) ||
>                     !rep.encKDCRepPart.sname.getRealmString().equals(
>                             req.reqBody.sname.getRealmString())) {
>                 rep.encKDCRepPart.key.destroy();
>                 throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED);
>             }
>         }

So it either fails for
> isAsReq 
or
> !rep.encKDCRepPart.sname.getRealmString().equals(
>>                             req.reqBody.sname.getRealmString())

Here is MIT Kerberos:
> $ kinit OSIPOVMI at ad001.siemens.net
> Passwort f?r OSIPOVMI at ad001.siemens.net:
> $ klist
> Ticketzwischenspeicher: FILE:/tmp/krb5cc_722
> Standard-Principal: osipovmi at AD001.SIEMENS.NET
> 
> Valid starting       Expires              Service principal
> 20.10.2021 10:02:14  20.10.2021 20:02:14  krbtgt/AD001.SIEMENS.NET at AD001.SIEMENS.NET
>         erneuern bis 21.10.2021 10:02:10

Works as expected. Can someone explain? Shall I create a bug for this?

Michael

From mcimadamore at openjdk.java.net  Wed Oct 20 11:14:19 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 20 Oct 2021 11:14:19 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v7]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <w29xO-xzh6eoUhneozTUGI31cNrgxuy-tdnZPqnQe70=.63d9006f-8f7e-4855-a2b7-cb7e28c37bc3@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

  Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/a4db81fe..52189683

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

  Stats: 39 lines in 9 files changed: 1 ins; 10 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

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

From aefimov at openjdk.java.net  Wed Oct 20 11:52:38 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 20 Oct 2021 11:52:38 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

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

  Change InetAddressResolver method names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/ac0d2184..30226481

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

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

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

From aefimov at openjdk.java.net  Wed Oct 20 11:52:40 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 20 Oct 2021 11:52:40 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <ChUmaIjYE61OE80QGJyqes8hnzErFw9IlgrSUlRtnNo=.a34cd6da-cc08-4e84-8fa2-c8f93f258268@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
 <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>
 <ChUmaIjYE61OE80QGJyqes8hnzErFw9IlgrSUlRtnNo=.a34cd6da-cc08-4e84-8fa2-c8f93f258268@github.com>
Message-ID: <e2Z23CSIonfZiKjcUrjv5dy6GkQDF_3eiqICSvXFWV0=.12146e99-a82e-4426-87a5-e871809ec907@github.com>

On Sun, 17 Oct 2021 21:03:56 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> getByName requires a hostname lookup and getByAdress requires (eventually - I know the docs says there?s no reverse lookup) an address reverse lookup. Thus, a logical mapping is getByName ?> lookupHostname, and getByAddr ?> lookupAddress, but the opposite will occur getByName --> lookupAddresses and getByAddress --> lookupHostname. Therfore I proffer maps neatly to rename methods to resolveHostname and resolveAddress such that the mapping are getByName --> resolveHostname and getByAddress --> resolveAddress.

Thank you, Mark, for highlighting the naming contradiction in the `InetAddressResolver` interface method names. It can be solved by making these names symmetrical to `InetAddress` API.
In 302264810725f86a4569161754f7b052c78fd826 `InetAddressResolver` method names have been updated to stress input parameters type, which brings them in sync with `InetAddress` API:
- `InetAddressResolver.lookupAddresses` is renamed to `InetAddressResolver.lookupByName`
- `InetAddressResolver.lookupHostName` is renamed to `InetAddressResolver.lookupByAddress`

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

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

From mullan at openjdk.java.net  Wed Oct 20 13:42:12 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 20 Oct 2021 13:42:12 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v2]
In-Reply-To: <C2PnAI53WQsM9JobHBuj4veh8nON8TACPvGMg2DEA9E=.c32b1911-4f45-47b3-8188-eded9865ccd3@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <X76Fq_nQbQ8qgFlA39O-rFgKxuMQjxE3w2I67mGnyUg=.d8fc032b-350d-4c25-b79a-c819ddc1af10@github.com>
 <C2PnAI53WQsM9JobHBuj4veh8nON8TACPvGMg2DEA9E=.c32b1911-4f45-47b3-8188-eded9865ccd3@github.com>
Message-ID: <UKN-bsSWdTwTUbzXfBU-pIDWNnsYMWCa87vMM9ZxAn8=.b0f101a2-5a48-4458-9b8e-9a8c60335304@github.com>

On Wed, 20 Oct 2021 02:45:07 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Changed names of AlgorithmDecomposer.canonicalName and decomposeOneHashName
>>   methods.
>>   - Changed other code in AlgorithmDecomposer to use DECOMPOSED_DIGEST_NAMES
>>   Map instead of hardcoding algorithm names.
>>   - Changed AlgorithmChecker.trySetTrustAnchor to set trustedPubKey field so that
>>   constraints on the key algorithm and size are checked in the check() method if
>>   the constraints are an instanceof DisabledAlgorithmConstraints.
>
> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 106:
> 
>> 104:         // "SHA-256" and "SHA256" to make the right constraint checking.
>> 105: 
>> 106:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {
> 
> If you're going to change this code, you can save me a PR if you surround this by "if (algorithm.contains("SHA") {  ...  }"
> Its a perf change to eliminate the unnecessary map lookups when SHA isn't in the algorithm string

That's a fine suggestion, although I'll note that your suggested perf improvement also applies to the previous code which did not check the algorithm parameter first to see if it contained `SHA`.
Also, another small perf imp: I realized below that in the loop, if the first `if` block gets executed, then the 2nd `if` block will always be false, so I changed it to an if/else.

> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 158:
> 
>> 156:         Set<String> elements = decomposeImpl(algorithm);
>> 157: 
>> 158:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {
> 
> Same "if (algorithm.contains("SHA") { ... }" comment as above

Ok. Let's hope a new algorithm with "SHA" in the words never gets defined :)

> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 159:
> 
>> 157: 
>> 158:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {
>> 159:             hasLoop(elements, e.getKey(), e.getValue());
> 
> I think it's worth merging the contents of hasLoop() into this for loop.  This is the only method calling hasLoop() and the extra method calls are not useful.  Your addition DECOMPOSED_DIGEST_NAMES makes a merger a more reasonable solution now than before.

Ok. I noticed that this method is different than `decompose` in that it only adds the decomposed `SHA` name to `elements`, and removes the standard `SHA` name from `elements` if it exists, whereas `decompose` adds both. Do you think we should change `decompose` to use the same technique?

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

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

From mcimadamore at openjdk.java.net  Wed Oct 20 14:00:30 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 20 Oct 2021 14:00:30 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v8]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <GshXpAmv5JOszFS8QSrVULWaytv7334pPb7mzuwKVm0=.127402cd-35f7-41fb-a91b-201911e1a971@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

  Fix copyright header in TestArrayCopy

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/52189683..414952ad

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

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

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

From mullan at openjdk.java.net  Wed Oct 20 14:47:31 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 20 Oct 2021 14:47:31 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
Message-ID: <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>

> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
> 
> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
> 
> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
> 
> - AlgorithmDecomposer now stores the decomposed SHA algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

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

  - Skip digest alg decomposing check for algorithms that don't contain "SHA".
  - Remove hasLoop method and fold code into decomposeName method.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5928/files
  - new: https://git.openjdk.java.net/jdk/pull/5928/files/cf5a4d7f..f2031126

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

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

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

From dfuchs at openjdk.java.net  Wed Oct 20 15:45:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 15:45:08 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
Message-ID: <ivcy8D5adbsN4lpF33q7d8XpBP39fLGfgaajkerWvwA=.e0cb8f51-3de9-4698-977e-387fba7c5c31@github.com>

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change InetAddressResolver method names

Marked as reviewed by dfuchs (Reviewer).

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

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

From ascarpino at openjdk.java.net  Wed Oct 20 16:21:02 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 20 Oct 2021 16:21:02 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v2]
In-Reply-To: <UKN-bsSWdTwTUbzXfBU-pIDWNnsYMWCa87vMM9ZxAn8=.b0f101a2-5a48-4458-9b8e-9a8c60335304@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <X76Fq_nQbQ8qgFlA39O-rFgKxuMQjxE3w2I67mGnyUg=.d8fc032b-350d-4c25-b79a-c819ddc1af10@github.com>
 <C2PnAI53WQsM9JobHBuj4veh8nON8TACPvGMg2DEA9E=.c32b1911-4f45-47b3-8188-eded9865ccd3@github.com>
 <UKN-bsSWdTwTUbzXfBU-pIDWNnsYMWCa87vMM9ZxAn8=.b0f101a2-5a48-4458-9b8e-9a8c60335304@github.com>
Message-ID: <EipxC7UEjCJl2IGs5JmAvnnBqwPxug0sJqK3ky1_Jjg=.8908a680-e3ae-42fb-8e30-2182e772bac8@github.com>

On Wed, 20 Oct 2021 13:34:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line 106:
>> 
>>> 104:         // "SHA-256" and "SHA256" to make the right constraint checking.
>>> 105: 
>>> 106:         for (Map.Entry<String, String> e : DECOMPOSED_DIGEST_NAMES.entrySet()) {
>> 
>> If you're going to change this code, you can save me a PR if you surround this by "if (algorithm.contains("SHA") {  ...  }"
>> Its a perf change to eliminate the unnecessary map lookups when SHA isn't in the algorithm string
>
> That's a fine suggestion, although I'll note that your suggested perf improvement also applies to the previous code which did not check the algorithm parameter first to see if it contained `SHA`.
> Also, another small perf imp: I realized below that in the loop, if the first `if` block gets executed, then the 2nd `if` block will always be false, so I changed it to an if/else.

Yes, I was about to submit a PR to change the previous code, since you changed this code it makes more sense to ask you to do it at the same time.

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

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

From xuelei at openjdk.java.net  Wed Oct 20 17:26:06 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 20 Oct 2021 17:26:06 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key
In-Reply-To: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
Message-ID: <OS6hmucwPDNdAqlPSjkyWJlibKnnrmZNxUkaO9JXYm8=.fd395e4c-99a2-4730-8b7f-9becaec58708@github.com>

On Fri, 23 Jul 2021 10:33:14 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Hello,
> 
> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
> 
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
> If not applied, implementation can try to select signer from other providers
> 
> Regards
> Alexey

It's a good catch.  Thank you for the fix.

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 248:

> 246:                              crtKey.getCrtCoefficient().signum() == 0 ||
> 247:                              crtKey.getPublicExponent().signum() == 0 )))) ||
> 248:                 (rsaKey instanceof RSAPublicKey rsaPubKey &&

Mixing the public key and private key together in one method may be not straightforward enough to logics like this update.  What do you think it we have two isvalid() method, one for private key and one for public key?

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 250:

> 248:                 (rsaKey instanceof RSAPublicKey rsaPubKey &&
> 249:                     rsaPubKey.getPublicExponent().signum() == 0)) {
> 250:                 throw new InvalidKeyException("Invalid key attributes");

The exception description may be confusing to users.  I'm not sure if the checking could be simplified and make this exception message better matching the problems.

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 251:

> 249:                     rsaPubKey.getPublicExponent().signum() == 0)) {
> 250:                 throw new InvalidKeyException("Invalid key attributes");
> 251:             }

What's the motivation to check the signum?

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

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

From weijun at openjdk.java.net  Wed Oct 20 18:02:24 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 20 Oct 2021 18:02:24 GMT
Subject: RFR: 8185844: MSCAPI doesn't list aliases correctly
Message-ID: <ts57VYM7pGl4dRk6wFNNt9XQGsws7qGLIldkNu5yu9k=.9a4805ca-c3ba-420d-945a-47ac104e7f7c@github.com>

If a entry is overwritten by another one using the same alias, make sure the old one is removed.

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

Commit messages:
 - 8185844: MSCAPI doesn't list aliases correctly

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

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

From weijun at openjdk.java.net  Wed Oct 20 18:14:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 20 Oct 2021 18:14:27 GMT
Subject: RFR: 8251134: Unwrapping a key with a Private Key generated by
 Microsoft CNG fails
Message-ID: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>

Support Cipher operations on CNG keys.

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

Depends on: https://git.openjdk.java.net/jdk/pull/6047

Commit messages:
 - 8251134: Unwrapping a key with a Private Key generated by Microsoft CNG fails

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

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

From alanb at openjdk.java.net  Wed Oct 20 18:36:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Oct 2021 18:36:20 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
Message-ID: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change InetAddressResolver method names

src/java.base/share/classes/java/net/InetAddress.java line 340:

> 338: 
> 339:     /* Used to store the system-wide resolver */
> 340:     private static volatile InetAddressResolver resolver;

Can this be @Stable?

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 34:

> 32: 
> 33: /**
> 34:  * This interface defines operations for looking-up host names and IP addresses.

I think change "looking-up" to "looking up".

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 102:

> 100: 
> 101:         /**
> 102:          * Specifies if IPv4 addresses need to be queried during lookup.

It might be better to change this to "Characteristic value signifying ..." rather than "Specifies".

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 186:

> 184: 
> 185:         /**
> 186:          * Returns an integer value which specifies lookup operation characteristics.

I think I'd change the first line here to something like "Returns a set of characteristics of this lookup policy".

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 35:

> 33: /**
> 34:  * A resolver provider class is a factory for custom implementations of {@linkplain
> 35:  * InetAddressResolver resolvers} which define operations for looking-up (resolving) host names

This reads "custom implementations of resolvers". It might be better to start with "Service-provider class for InetAddress resolvers".

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52:

> 50:     /**
> 51:      * Initialise and return the {@link InetAddressResolver} provided by
> 52:      * this provider. This method is called by {@link InetAddress} when

"the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that.

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 88:

> 86:      *                           {@code RuntimePermission("inetAddressResolverProvider")}.
> 87:      * @implNote It is recommended that an {@code InetAddressResolverProvider} service
> 88:      * implementation does not perform any heavy initialization in its

"heavy initialization" is probably not the best phrase here. Maybe it should say that the initialisation should be as simple as possible to avoid recursive initialisation issues.

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 110:

> 108:     /**
> 109:      * A {@code Configuration} interface is supplied to the
> 110:      * {@link InetAddressResolverProvider#get(Configuration)} method when installing a

I think this should be "Configuration object" rather than "interface" here.

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

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

From alanb at openjdk.java.net  Wed Oct 20 18:50:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Oct 2021 18:50:08 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
Message-ID: <BicXXxHGQ2J_totNOUWmj1GvaMVxtJSV8TfbWQ07vFI=.d1058765-a518-4495-b089-4deafc123970@github.com>

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change InetAddressResolver method names

src/java.base/share/classes/java/net/InetAddress.java line 244:

> 242:  * @implNote
> 243:  * For any lookup operation that might occur before the VM is fully booted the <i>built-in
> 244:  * resolver</i> will be used.

I think we will need decide if InetAddress class description is the right place for this or whether some/most of it should move to InetAddressResolverProvider. It might be that we update the existing "Host Name Resolution" section with some basic/readable text to make the reader aware that there is a provider mechanism with a link to InetAddressResolverProvider with the details.

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

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

From mbalao at openjdk.java.net  Wed Oct 20 20:16:03 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Wed, 20 Oct 2021 20:16:03 GMT
Subject: RFR: 8271566: DSA signature length value is not accurate in
 P11Signature [v2]
In-Reply-To: <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>
 <FPCFus5ti9nNPUazUdnxrQZODxjRkwSWMhdD1eIuIig=.91b2df83-247b-48a0-84ff-0a78542661c4@github.com>
Message-ID: <x4dcvmjnOd-QU3efXkqoUuP3AiHG5DfIQ8816qjdBZQ=.961d5b3d-e0eb-4ea2-bcff-5a64701bc274@github.com>

On Fri, 13 Aug 2021 17:11:45 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.
>> 
>> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.
>> 
>> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   P11Key static inner classes refactorings.

Hi Valerie,

Apologies for the delay; I've intention to resume this work if you can.

I had a look at your Webrev.00 but I'm not really convinced, at least when comparing it to the Fetcher approach. I'll share my comments below:

 * Changing P11PrivateKey::getFormat to return 'PKCS#8' and not overriding this method on opaque/sensitive private key classes will be an observable change, and it does not match what's specified in Key::getFormat: 'Returns the name of the primary encoding format of this key, or null if this key does not support encoding.'. My thinking here is that an opaque key does not support encoding because its value is not even accessible.

 * P11PrivateKeyRSA and P11RSAPrivateKey class names look confusing to me (where 'RSA' is located does not say anything about the class to me at least). The 'Opaque' suffix for the one that is package-private might be a better choice. I used the suffice 'Internal' before but now I like 'Opaque' more.

 * P11PrivateKeyRSA::of duplicates the attributes retrieval logic (session.token.p11::C_GetAttributeValue call), which is there and in P11Key::fetchAttributes. Sensitive RSA keys get the attributes from one place and non-sensitive from the other. This does not look to me an advantage when compared to the Fetcher, which does the same for RSA and uses P11Key::fetchAttributes for the others. However, having all the RSA-related logic in P11RSAAttributesFetcher::doFetchValues makes it a bit easier for me to reason about the 4 different scenarios to get the data: CRT + sensitive, non-CRT + sensitive, CRT + non-sensitive and non-CRT + non-sensitive.

 * By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.

 * P11PrivateKeyRSA does not make the CRT/non-CRT distinction for sensitive keys, so the public exponent is not obtained when it could be. This is a bit less functionality than what the Fetcher provides, and would require a few changes to fit it into the design.

>From comment #Aug 17:
"(...) and you just cover it up with different wrapper classes which seems algorithm specific but yet do not contain any algorithm specific fields and the logic is all inside the corresponding Fetcher"

 * In my view, it's true that the Fetcher has the logic to get and hold the data. But the classes that use it are not just wrapper classes covering it up: they implement different interfaces and override/implement methods differently. In example, P11RSAPrivateNonCRTKey implements RSAPrivateKey and decides not to provide an implementation of methods such as getPublicExponent, getPrimeP, getPrimeQ, etc. On the other hand, having the logic for the different RSA data-availability scenarios in a single place (CRT sensitive, non-CRT sensitive, CRT non-sensitive and non-CRT non-sensitive) makes it a bit easier to reason about. Otherwise, this is scattered all over the place.

If you still want to take the non-fetcher approach and address the issues mentioned above, I can have a look.

Kind regards,
Martin.-

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

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

From ascarpino at openjdk.java.net  Wed Oct 20 20:51:04 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 20 Oct 2021 20:51:04 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
Message-ID: <4gHZE0xcs7ttK5lQWqQk6ubujej03RPL0YuC08PdHQY=.672dfa96-70a7-4170-a2b6-4d6446829717@github.com>

On Wed, 20 Oct 2021 14:47:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
>> 
>> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
>> 
>> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
>> 
>> - AlgorithmDecomposer now stores the decomposed SHA algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Skip digest alg decomposing check for algorithms that don't contain "SHA".
>   - Remove hasLoop method and fold code into decomposeName method.

looks good to me

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

Marked as reviewed by ascarpino (Reviewer).

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

From xuelei at openjdk.java.net  Wed Oct 20 21:53:07 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 20 Oct 2021 21:53:07 GMT
Subject: RFR: 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: <caYPj9021y2xkNhxfOkS-0LMquybvJ8gVAqb7XWEtss=.75ad52af-37a6-4b0b-89ec-0a9306206484@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

Changes requested by xuelei (Reviewer).

It looks like a good idea to make less computation for each handshake context.  Thanks for that.  I have some concerns for the update, and see the comments above.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 57:

> 55:     AlgorithmConstraints        userSpecifiedAlgorithmConstraints;
> 56:     List<ProtocolVersion>       enabledProtocols;
> 57:     List<CipherSuite>           enabledCipherSuites;

What's the motivation to change enabledProtocols/CipherSuites to private?

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 278:

> 276:                 this.enabledCipherSuites, this.algorithmConstraints);
> 277:         this.activeCipherSuites = getActiveCipherSuites(this.activeProtocols,
> 278:                 this.enabledCipherSuites, this.algorithmConstraints);

Maybe a lazy set of activeProtocols could be better as setSSLParameters() may be called multiple times in practice.

src/java.base/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java line 47:

> 45: 
> 46:     private final SSLContextImpl context;
> 47:     private final SSLConfiguration configuration;

Share the mutable configuration within the instances created by the factory may be not a good idea.

src/java.base/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java line 173:

> 171:     {
> 172:         return new SSLSocketImpl(context, address, port,
> 173:                 clientAddress, clientPort, configuration);

Note that the configuration is used and shared for among socket instances, which may be not the expected behavior.

src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 174:

> 172:         HandshakeHash handshakeHash = new HandshakeHash();
> 173:         this.conContext = new TransportContext(sslContext, this,
> 174:                 sslConfiguration,

Sharing the mutable sslConfiguration for individual sockets may be not a good idea.

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

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

From cverghese at openjdk.java.net  Wed Oct 20 22:12:01 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Wed, 20 Oct 2021 22:12:01 GMT
Subject: RFR: 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: <_VshJLodLgjqe4Szme5SiosJHhLQ-dFNQXIBrhJNqTE=.cc9761f3-3a93-4f17-b3f3-bdf9ae01aa39@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

Thank you for the feedback. 

Based on the feedback provided here, I am working on moving this to a cache within HandshakeContext. I will be updating the PR with that implementation soon for your feedback.

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

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

From weijun at openjdk.java.net  Thu Oct 21 02:35:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 21 Oct 2021 02:35:13 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
Message-ID: <KwSotksCRCeVJ0WEwvFLm46vuw4F0VE8nQIMtsu8rKA=.50947ee8-d9f6-431d-a6b2-90d319ba2960@github.com>

On Wed, 20 Oct 2021 14:47:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
>> 
>> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
>> 
>> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
>> 
>> - AlgorithmDecomposer now stores the decomposed SHA algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Skip digest alg decomposing check for algorithms that don't contain "SHA".
>   - Remove hasLoop method and fold code into decomposeName method.

src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 80:

> 78:     private final Date date;
> 79:     private PublicKey prevPubKey;
> 80:     private final String variant;

You can group fields to final and non-final ones.

src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 174:

> 172:     }
> 173: 
> 174:     @Override

In the `init()` method below, just write `prevPubKey = trustedPubKey` no matter if `trustedPubKey` is null or not.

src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 318:

> 316:             prevPubKey = currPubKey;
> 317:             return;
> 318:         }

I find it more natural to enclose the block below in a `if (prevPubKey != null)` block, and you only need to call one `prevPubKey = currPubKey` at the end.

src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 362:

> 360:         // Don't bother if the check has started or trust anchor has already
> 361:         // been specified.
> 362:         if (this.prevPubKey == null) {

Maybe it's cleaner to write `if (this.trustedPubKey == null)` above. Anyway, after `init()` they are the same.

src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 363:

> 361:         // been specified.
> 362:         if (this.prevPubKey == null) {
> 363:             if (anchor == null) {

This won't happen. Or, you can ignore it.

This makes it possible to call this method in the constructor.

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

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

From mullan at openjdk.java.net  Thu Oct 21 12:36:33 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 21 Oct 2021 12:36:33 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v4]
In-Reply-To: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
Message-ID: <-qG-w6Uy3e-tHNZt9ucTG4NXp_lvse9oK-2Bn2pRsDc=.56993be7-5744-4ee3-b495-3cb9cc92037c@github.com>

> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
> 
> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
> 
> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
> 
> - AlgorithmDecomposer now stores the decomposed SHA algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

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

  Address Max' comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5928/files
  - new: https://git.openjdk.java.net/jdk/pull/5928/files/f2031126..052c28f5

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

  Stats: 44 lines in 1 file changed: 4 ins; 16 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5928/head:pull/5928

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

From mullan at openjdk.java.net  Thu Oct 21 12:36:44 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 21 Oct 2021 12:36:44 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <KwSotksCRCeVJ0WEwvFLm46vuw4F0VE8nQIMtsu8rKA=.50947ee8-d9f6-431d-a6b2-90d319ba2960@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
 <KwSotksCRCeVJ0WEwvFLm46vuw4F0VE8nQIMtsu8rKA=.50947ee8-d9f6-431d-a6b2-90d319ba2960@github.com>
Message-ID: <6nMyhWHdD0FkArkzWOTQnkP553PSOPBWsOzSBBCA2pw=.6dee2c3f-bd22-48ae-ae1d-47a67c2cc1a8@github.com>

On Thu, 21 Oct 2021 02:22:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Skip digest alg decomposing check for algorithms that don't contain "SHA".
>>   - Remove hasLoop method and fold code into decomposeName method.
>
> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 80:
> 
>> 78:     private final Date date;
>> 79:     private PublicKey prevPubKey;
>> 80:     private final String variant;
> 
> You can group fields to final and non-final ones.

Ok.

> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 174:
> 
>> 172:     }
>> 173: 
>> 174:     @Override
> 
> In the `init()` method below, just write `prevPubKey = trustedPubKey` no matter if `trustedPubKey` is null or not.

Yes.

> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 318:
> 
>> 316:             prevPubKey = currPubKey;
>> 317:             return;
>> 318:         }
> 
> I find it more natural to enclose the block below in a `if (prevPubKey != null)` block, and you only need to call one `prevPubKey = currPubKey` at the end.

Ok.

> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 362:
> 
>> 360:         // Don't bother if the check has started or trust anchor has already
>> 361:         // been specified.
>> 362:         if (this.prevPubKey == null) {
> 
> Maybe it's cleaner to write `if (this.trustedPubKey == null)` above. Anyway, after `init()` they are the same.

Agree.

> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 363:
> 
>> 361:         // been specified.
>> 362:         if (this.prevPubKey == null) {
>> 363:             if (anchor == null) {
> 
> This won't happen. Or, you can ignore it.
> 
> This makes it possible to call this method in the constructor.

Ok, will remove. But I will keep this method separate since, unlike the ctor it needs to check if `trustedPubKey` is `null` before setting the `prevPubKey`.

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

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

From abakhtin at openjdk.java.net  Thu Oct 21 12:59:35 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Oct 2021 12:59:35 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v2]
In-Reply-To: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
Message-ID: <Xkn5ggfUCjp52Ih1w7HTCagEGvxbnQ8YYsCjitWjtZs=.d2b9c836-7c99-4507-baf1-8dc95a231198@github.com>

> Hello,
> 
> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
> 
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
> If not applied, implementation can try to select signer from other providers
> 
> Regards
> Alexey

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

  Refactoring isValid() for private and public keys

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4887/files
  - new: https://git.openjdk.java.net/jdk/pull/4887/files/d2b371d5..b336e36e

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

  Stats: 105 lines in 2 files changed: 68 ins; 32 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4887/head:pull/4887

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

From abakhtin at openjdk.java.net  Thu Oct 21 13:02:07 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Oct 2021 13:02:07 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v2]
In-Reply-To: <OS6hmucwPDNdAqlPSjkyWJlibKnnrmZNxUkaO9JXYm8=.fd395e4c-99a2-4730-8b7f-9becaec58708@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <OS6hmucwPDNdAqlPSjkyWJlibKnnrmZNxUkaO9JXYm8=.fd395e4c-99a2-4730-8b7f-9becaec58708@github.com>
Message-ID: <Wv6J2TrJD9M8KgKEHP5jsP2KFyxJm-grdt6Dbw4U0bI=.ecf0ebdd-dfc7-4720-9aa5-912896d6d7c8@github.com>

On Wed, 20 Oct 2021 17:22:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring isValid() for private and public keys
>
> It's a good catch.  Thank you for the fix.

Hi @XueleiFan !
Thank you for review and comments. I've used signum as it is the most lightweight method in the BigInteger. Now I have refactored the patch to reuse key verification methods from other classes.
isValid() is split out into two methods as you suggested and exception messages are updated.
sun/security/rsa tests are passed

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

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

From weijun at openjdk.java.net  Thu Oct 21 13:06:09 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 21 Oct 2021 13:06:09 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <6nMyhWHdD0FkArkzWOTQnkP553PSOPBWsOzSBBCA2pw=.6dee2c3f-bd22-48ae-ae1d-47a67c2cc1a8@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
 <KwSotksCRCeVJ0WEwvFLm46vuw4F0VE8nQIMtsu8rKA=.50947ee8-d9f6-431d-a6b2-90d319ba2960@github.com>
 <6nMyhWHdD0FkArkzWOTQnkP553PSOPBWsOzSBBCA2pw=.6dee2c3f-bd22-48ae-ae1d-47a67c2cc1a8@github.com>
Message-ID: <__1Ca6qv9LmhJdnRMrWzHl1q_TG_de60HzpNa55ggoI=.b3c9942a-02cc-4ea2-8706-cc42f66eb2ed@github.com>

On Thu, 21 Oct 2021 12:06:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 363:
>> 
>>> 361:         // been specified.
>>> 362:         if (this.prevPubKey == null) {
>>> 363:             if (anchor == null) {
>> 
>> This won't happen. Or, you can ignore it.
>> 
>> This makes it possible to call this method in the constructor.
>
> Ok, will remove. But I will keep this method separate since, unlike the ctor it needs to check if `trustedPubKey` is `null` before setting the `prevPubKey`.

OK, but in the ctor `trustedPubKey` is also null.

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

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

From mullan at openjdk.java.net  Thu Oct 21 13:50:12 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 21 Oct 2021 13:50:12 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <__1Ca6qv9LmhJdnRMrWzHl1q_TG_de60HzpNa55ggoI=.b3c9942a-02cc-4ea2-8706-cc42f66eb2ed@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
 <KwSotksCRCeVJ0WEwvFLm46vuw4F0VE8nQIMtsu8rKA=.50947ee8-d9f6-431d-a6b2-90d319ba2960@github.com>
 <6nMyhWHdD0FkArkzWOTQnkP553PSOPBWsOzSBBCA2pw=.6dee2c3f-bd22-48ae-ae1d-47a67c2cc1a8@github.com>
 <__1Ca6qv9LmhJdnRMrWzHl1q_TG_de60HzpNa55ggoI=.b3c9942a-02cc-4ea2-8706-cc42f66eb2ed@github.com>
Message-ID: <0dcepjdJepzUR0uVuf7dDfNivpTyvZ_BwwFZbeKBVvk=.f4d893c6-c20a-499b-bff0-db4ccaf44c9b@github.com>

On Thu, 21 Oct 2021 13:03:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ok, will remove. But I will keep this method separate since, unlike the ctor it needs to check if `trustedPubKey` is `null` before setting the `prevPubKey`.
>
> OK, but in the ctor `trustedPubKey` is also null.

True, but that's because none of the fields are set yet, so it feels odd for the ctor to check if the field is null when it is always true, even if it is a different method. What if I create a separate method `setTrustAnchor(TrustAnchor)` which the ctor calls, and then change `trySetTrustAnchor` to:

        if (this.trustedPubKey == null) {
            setTrustAnchor(anchor);
        }

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

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

From weijun at openjdk.java.net  Thu Oct 21 13:50:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 21 Oct 2021 13:50:12 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v3]
In-Reply-To: <0dcepjdJepzUR0uVuf7dDfNivpTyvZ_BwwFZbeKBVvk=.f4d893c6-c20a-499b-bff0-db4ccaf44c9b@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
 <qso_iVV12ymI9fx0TvRrj0A6uelc87ATUwviceQOWKo=.2b82459f-b57f-41c2-930f-40c29934c08d@github.com>
 <KwSotksCRCeVJ0WEwvFLm46vuw4F0VE8nQIMtsu8rKA=.50947ee8-d9f6-431d-a6b2-90d319ba2960@github.com>
 <6nMyhWHdD0FkArkzWOTQnkP553PSOPBWsOzSBBCA2pw=.6dee2c3f-bd22-48ae-ae1d-47a67c2cc1a8@github.com>
 <__1Ca6qv9LmhJdnRMrWzHl1q_TG_de60HzpNa55ggoI=.b3c9942a-02cc-4ea2-8706-cc42f66eb2ed@github.com>
 <0dcepjdJepzUR0uVuf7dDfNivpTyvZ_BwwFZbeKBVvk=.f4d893c6-c20a-499b-bff0-db4ccaf44c9b@github.com>
Message-ID: <cYlRngK13BvwC8_YmUd0lMOPADpbU8JD4jqC4Gh0_Qc=.7f704b2f-4ef0-46c8-89c2-97ad0c87de8a@github.com>

On Thu, 21 Oct 2021 13:43:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> OK, but in the ctor `trustedPubKey` is also null.
>
> True, but that's because none of the fields are set yet, so it feels odd for the ctor to check if the field is null when it is always true, even if it is a different method. What if I create a separate method `setTrustAnchor(TrustAnchor)` which the ctor calls, and then change `trySetTrustAnchor` to:
> 
>         if (this.trustedPubKey == null) {
>             setTrustAnchor(anchor);
>         }

Sounds good.

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

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

From weijun at openjdk.java.net  Thu Oct 21 14:08:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 21 Oct 2021 14:08:12 GMT
Subject: Integrated: 8270380: Change the default value of the
 java.security.manager system property to disallow
In-Reply-To: <A89zsUHwN1IIQ0s8MoeOSUQO8tXRmwlSN-thiw5ss0U=.fe47f215-531d-4239-95fa-3c50f3bae3eb@github.com>
References: <A89zsUHwN1IIQ0s8MoeOSUQO8tXRmwlSN-thiw5ss0U=.fe47f215-531d-4239-95fa-3c50f3bae3eb@github.com>
Message-ID: <HSyqlZ07oUTvXORsHtY6GIcba5AxtAUrZagpFoUKVJc=.8d05270f-c46b-4c3f-a86e-9267c504c312@github.com>

On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE.
> 
> This change was previously announced on the [jdk-dev alias](https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005616.html) and is documented in [JEP 411](https://openjdk.java.net/jeps/411#Description).
> 
> The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime.

This pull request has now been integrated.

Changeset: d589b664
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d589b664cc809aea39ec094e99b1898df1bf3c19
Stats:     30 lines in 6 files changed: 5 ins; 8 del; 17 mod

8270380: Change the default value of the java.security.manager system property to disallow

Reviewed-by: lancea, mullan, rriggs

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

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

From mullan at openjdk.java.net  Thu Oct 21 14:40:37 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 21 Oct 2021 14:40:37 GMT
Subject: RFR: 8243585: AlgorithmChecker::check throws confusing exception
 when it rejects the signer key [v5]
In-Reply-To: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
Message-ID: <1FhUCl3kL7qsw_VKpkqIFQUEdC87ddBiGTb99FXwAvA=.8a34ced7-26ed-438f-9c5d-a99a961b036a@github.com>

> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
> 
> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
> 
> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
> 
> - AlgorithmDecomposer now stores the decomposed SHA algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

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

  Add setTrustAnchorAndKeys method and change ctor and trySetTrustAnchor to call it.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5928/files
  - new: https://git.openjdk.java.net/jdk/pull/5928/files/052c28f5..d163b5b1

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

  Stats: 32 lines in 1 file changed: 14 ins; 15 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5928/head:pull/5928

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

From mcimadamore at openjdk.java.net  Thu Oct 21 15:20:16 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 21 Oct 2021 15:20:16 GMT
Subject: RFR: 8275063: Implementation of Foreign Function & Memory API
 (Second incubator) [v9]
In-Reply-To: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
References: <ZWqSuAbHEr4AWe4pOadf6EHbJhxk0A1ddjnRqcur0h8=.b79dad77-ed29-48db-8892-e76a82aa4cd6@github.com>
Message-ID: <uFQ75QyTNnklpwy5eVdnfTACIAeDlOD7XMKMBZNlCdo=.44a536bf-9213-4357-a0c9-3736b714f049@github.com>

> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

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

 - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
 - Merge branch 'master' into JEP-419
 - Fix copyright header in TestArrayCopy
 - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
 - * use `invokeWithArguments` to simplify new test
 - Add test for liveness check with high-aririty downcalls
   (make sure that if an exception occurs in a downcall because of liveness,
   ref count of other resources are left intact).
 - * Fix javadoc issue in VaList
   * Fix bug in concurrent logic for shared scope acquire
 - Address review comments
 - Apply suggestions from code review
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Fix TestLinkToNativeRBP test
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/aeabb3df...5c69eabf

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5907/files
  - new: https://git.openjdk.java.net/jdk/pull/5907/files/414952ad..5c69eabf

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

  Stats: 25202 lines in 587 files changed: 18962 ins; 4240 del; 2000 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

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

From xuelei at openjdk.java.net  Thu Oct 21 16:52:07 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 21 Oct 2021 16:52:07 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v2]
In-Reply-To: <Xkn5ggfUCjp52Ih1w7HTCagEGvxbnQ8YYsCjitWjtZs=.d2b9c836-7c99-4507-baf1-8dc95a231198@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <Xkn5ggfUCjp52Ih1w7HTCagEGvxbnQ8YYsCjitWjtZs=.d2b9c836-7c99-4507-baf1-8dc95a231198@github.com>
Message-ID: <7trjyOjADPF016uWdR3ROr0Ovc8YZHkPUWXEDxuyKtI=.ee339194-96b4-43f5-b429-fc6fcfa99f34@github.com>

On Thu, 21 Oct 2021 12:59:35 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring isValid() for private and public keys

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 127:

> 125:             throws InvalidKeyException {
> 126:         if (publicKey instanceof RSAPublicKey rsaPubKey) {
> 127:             this.pubKey = (RSAPublicKey) isPublicKeyValid(rsaPubKey);

Is it possible to have the isPublicKeyValid() returning RSAPublicKey, or void, so as to avoid the casting?  Same comment for the isValid() method and the isPrivateKeyValid() method.

src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 96:

> 94:             try {
> 95:                 return isValid(key);
> 96:             } catch (InvalidKeyException ikEx) {

It might be an uncommon use of the exception.  Exception creation and catching are expensive.  It is not good for performance to recover from exception.  I know there are a lot of code recovering from exception.  But if it is possible, we may want to try avoid it in new code.  Maybe, the isValid() could return a boolean value instead.

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

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

From mullan at openjdk.java.net  Thu Oct 21 17:32:15 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 21 Oct 2021 17:32:15 GMT
Subject: Integrated: 8243585: AlgorithmChecker::check throws confusing
 exception when it rejects the signer key
In-Reply-To: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
References: <XImW5pPg9aXa3wpkyrBv2kgpcqMwihptyUy64kVuYws=.165d70de-a5d1-47e7-8767-73bb4f4840a2@github.com>
Message-ID: <K1utedKP_bQa6sjkTSJL7XsQeU-V9KwJh6t_SG8ingw=.5e09beec-0f95-4db7-bc4e-cc293b6d77dc@github.com>

On Wed, 13 Oct 2021 13:42:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This fix improves the exception message to better indicate when the key (and not the signature algorithm) is restricted. This change also includes a few other improvements:
> 
> - The constraints checking in `AlgorithmChecker.check()` has been improved. If the `AlgorithmConstraints` are an instance of `DisabledAlgorithmConstraints`, the internal `permits` methods are always called; otherwise the public `permits` methods are called. This makes the code easier to understand, and fixes at least one case where duplicate checks were being done.
> 
> - The above change caused some of the exception messages to be slightly different, so some tests that checked the error messages had to be updated to reflect that.
> 
> - AlgorithmDecomposer now stores the decomposed SHA algorithm names in a Map, which fixed a bug where "RSASSA-PSS" was not being restricted properly.

This pull request has now been integrated.

Changeset: 49f9d803
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/49f9d8031e9c678e20dcfc1ba06758b511a26b07
Stats:     327 lines in 8 files changed: 103 ins; 122 del; 102 mod

8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key

Reviewed-by: ascarpino

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

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

From aefimov at openjdk.java.net  Thu Oct 21 18:21:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 21 Oct 2021 18:21:50 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v6]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <ekUjsgNgasoSOg0fh0GhZEEokmjT-Kq7PVS6PaqNOZg=.6de99e55-07ed-4b44-ba7f-68a1907ba283@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

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

  Review updates + move resolver docs to the provider class (CSR update to follow)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/30226481..2a554c91

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

  Stats: 123 lines in 3 files changed: 49 ins; 40 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

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

From aefimov at openjdk.java.net  Thu Oct 21 18:21:54 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 21 Oct 2021 18:21:54 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <BicXXxHGQ2J_totNOUWmj1GvaMVxtJSV8TfbWQ07vFI=.d1058765-a518-4495-b089-4deafc123970@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <BicXXxHGQ2J_totNOUWmj1GvaMVxtJSV8TfbWQ07vFI=.d1058765-a518-4495-b089-4deafc123970@github.com>
Message-ID: <htKsbP2LazIbd6Qd_a8ddQANeGoIFSVMXWHmir4MI2M=.a2e97aa1-d9a3-4eb1-b96e-c78f70d4877a@github.com>

On Wed, 20 Oct 2021 18:47:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change InetAddressResolver method names
>
> src/java.base/share/classes/java/net/InetAddress.java line 244:
> 
>> 242:  * @implNote
>> 243:  * For any lookup operation that might occur before the VM is fully booted the <i>built-in
>> 244:  * resolver</i> will be used.
> 
> I think we will need decide if InetAddress class description is the right place for this or whether some/most of it should move to InetAddressResolverProvider. It might be that we update the existing "Host Name Resolution" section with some basic/readable text to make the reader aware that there is a provider mechanism with a link to InetAddressResolverProvider with the details.

Thanks for a good suggestion, Alan. It looks better now (2a554c91864e3b42a0ea315b0a671782fe341927) with some basic text for provider mechanism added to `Host Name Resolution`, and `InetAddress Resolver Providers` section moved to `InetAddressResolverProvider`.

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

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

From dfuchs at openjdk.java.net  Thu Oct 21 19:12:09 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Oct 2021 19:12:09 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v6]
In-Reply-To: <ekUjsgNgasoSOg0fh0GhZEEokmjT-Kq7PVS6PaqNOZg=.6de99e55-07ed-4b44-ba7f-68a1907ba283@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <ekUjsgNgasoSOg0fh0GhZEEokmjT-Kq7PVS6PaqNOZg=.6de99e55-07ed-4b44-ba7f-68a1907ba283@github.com>
Message-ID: <CQL8ZrmzUieC0CyTq3sH8RPwj-ImDhp-kdz40dHEDkQ=.9ef4adfd-69d2-4c6f-971f-e5a0e8c9ba78@github.com>

On Thu, 21 Oct 2021 18:21:50 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review updates + move resolver docs to the provider class (CSR update to follow)

src/java.base/share/classes/java/net/InetAddress.java line 152:

> 150:  *
> 151:  * <h3> Host Name Resolution </h3>
> 152:  * Host name-to-IP address <i>resolution</i> is accomplished through the use

maybe you need a `<p> ` there even though it's the first paragaph under the header.

src/java.base/share/classes/java/net/InetAddress.java line 159:

> 157:  * by <a href="spi/InetAddressResolverProvider.html#system-wide-resolver">
> 158:  * deploying</a> an {@link InetAddressResolverProvider}.
> 159:  * <p id="built-in-resolver">The built-in resolver implementation is used by

did you double check that anchors defined with `<p id="xxx">` actually work in the generated API doc?
Also maybe leave a blank line before any opening `<p`, that makes it easier to see where the paragraphs are. 
And the convention is to leave a white space after the `<p>` tag...

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 36:

> 34:  * This interface defines operations for looking-up host names and IP addresses.
> 35:  * An instance of {@code InetAddressResolver} is
> 36:  * <a href="InetAddressResolverProvider.html#system-wide-resolver">installed</a> as a

Maybe it would be more appropriate to link _system-wide-resolver_ instead (on the next line in the same sentence).

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 37:

> 35:  *
> 36:  * <p>A resolver provider is a factory for custom implementations of {@linkplain
> 37:  * InetAddressResolver resolvers}. A resolver define operations for looking up

... a resolver define**s** ...

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

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

From abakhtin at openjdk.java.net  Thu Oct 21 19:16:34 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Oct 2021 19:16:34 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v3]
In-Reply-To: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
Message-ID: <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>

> Hello,
> 
> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
> 
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
> If not applied, implementation can try to select signer from other providers
> 
> Regards
> Alexey

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

  Change exception handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4887/files
  - new: https://git.openjdk.java.net/jdk/pull/4887/files/b336e36e..df6f212d

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

  Stats: 34 lines in 2 files changed: 9 ins; 7 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4887/head:pull/4887

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

From abakhtin at openjdk.java.net  Thu Oct 21 19:20:05 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Oct 2021 19:20:05 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v3]
In-Reply-To: <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
Message-ID: <ONSusVFZQ01jpjuO7uOnCwbtfvK_gckReAkyoqBybiY=.ee36c8d0-b0c9-4736-9291-2193e9d132d6@github.com>

On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception handling

Thank you for review.
I've changed exception handling and excluded unnecessary casting.

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

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

From weijun.wang at oracle.com  Thu Oct 21 19:38:18 2021
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Thu, 21 Oct 2021 19:38:18 +0000
Subject: Java ignores/errors canonicalized principals (NT-PRINCIPAL) from
 Active Directory
In-Reply-To: <0b9c7c31-bf21-03f0-9cae-a16f27f3f29b@siemens.com>
References: <0b9c7c31-bf21-03f0-9cae-a16f27f3f29b@siemens.com>
Message-ID: <18E063BE-8413-4DAE-9086-7FE72BB33F36@oracle.com>


 KrbKdcReq throws the exception on line 55, so it is the previous check

        if (isAsReq && !req.reqBody.cname.equals(rep.cname) &&
                ((!req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) &&
                req.reqBody.cname.getNameType() !=
                PrincipalName.KRB_NT_ENTERPRISE) ||
                 !rep.encKDCRepPart.flags.get(Krb5.TKT_OPTS_ENC_PA_REP))) {
            rep.encKDCRepPart.key.destroy();
>>>         throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED);
        }

So maybe it's the cname was changed, but I'm not sure about the flags.

Can you send me some packets? Hopefully with a key tab or password so I can look into rep.encKDCRepPart.

Thanks,
Max



> On Oct 20, 2021, at 4:03 AM, Osipov, Michael (LDA IT PLM) <michael.osipov at siemens.com> wrote:
> 
> Hi folks,
> 
> we have recently noticed the following with Java's kinit (tested with Zulu 8 and 13, code is identical in 18 as well):
> 
>> C:\Users\osipovmi>kinit osipovmi at ad001.siemens.net
> 
> I have intentionally written the realm in lowercase to rely on canonicalization of the AD KDC. krb5.conf contains "canonicalize = true" as well.
> 
> Wireshark shows me in the AS-REQ:
> as-req/req-body/sname: name-type KRB5-NT-SRV-INST (2), sname-string (2): krbtgt and ad001.siemens.net
> 
> AS-REP:
> as-rep/ticket/sname: name-type KRB5-NT-SRV-INST (2), sname-string (2): krbtgt and AD001.SIEMENS.NET
> 
> Hence, the KDC has properly canonicalized the sname. Java gives me:
> 
>> Exception: krb_error 41 Message stream modified (41) Message stream modified
>> KrbException: Message stream modified (41)
>>        at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:55)
>>        at sun.security.krb5.KrbAsRep.decrypt(KrbAsRep.java:159)
>>        at sun.security.krb5.KrbAsRep.decryptUsingPassword(KrbAsRep.java:139)
>>        at sun.security.krb5.KrbAsReqBuilder.resolve(KrbAsReqBuilder.java:312)
>>        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:498)
>>        at sun.security.krb5.internal.tools.Kinit.acquire(Kinit.java:248)
>>        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:134)
>>        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:96)
> 
> Referrals aren't involved here, same realm.
> The failing code block is from:
> * https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/9a751dc19fae78ce58fb0eb176522070c992fb6f/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java#L58-L71
> * https://github.com/AdoptOpenJDK/openjdk-jdk/blob/ff4997014fe5462dca2b313f3f483400ffee5b62/src/java.security.jgss/share/classes/sun/security/krb5/KrbKdcRep.java#L58-L71
> 
>>        // sname change in TGS-REP is allowed only if client
>>        // sent CANONICALIZE and new sname is a referral of
>>        // the form krbtgt/TO-REALM.COM at FROM-REALM.COM.
>>        if (!req.reqBody.sname.equals(rep.encKDCRepPart.sname)) {
>>            String[] snameStrings = rep.encKDCRepPart.sname.getNameStrings();
>>            if (isAsReq || !req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) ||
>>                    snameStrings == null || snameStrings.length != 2 ||
>>                    !snameStrings[0].equals(PrincipalName.TGS_DEFAULT_SRV_NAME) ||
>>                    !rep.encKDCRepPart.sname.getRealmString().equals(
>>                            req.reqBody.sname.getRealmString())) {
>>                rep.encKDCRepPart.key.destroy();
>>                throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED);
>>            }
>>        }
> 
> So it either fails for
>> isAsReq 
> or
>> !rep.encKDCRepPart.sname.getRealmString().equals(
>>>                            req.reqBody.sname.getRealmString())
> 
> Here is MIT Kerberos:
>> $ kinit OSIPOVMI at ad001.siemens.net
>> Passwort f?r OSIPOVMI at ad001.siemens.net:
>> $ klist
>> Ticketzwischenspeicher: FILE:/tmp/krb5cc_722
>> Standard-Principal: osipovmi at AD001.SIEMENS.NET
>> Valid starting       Expires              Service principal
>> 20.10.2021 10:02:14  20.10.2021 20:02:14  krbtgt/AD001.SIEMENS.NET at AD001.SIEMENS.NET
>>        erneuern bis 21.10.2021 10:02:10
> 
> Works as expected. Can someone explain? Shall I create a bug for this?
> 
> Michael


From michael.osipov at siemens.com  Fri Oct 22 07:48:06 2021
From: michael.osipov at siemens.com (Osipov, Michael (LDA IT PLM))
Date: Fri, 22 Oct 2021 09:48:06 +0200
Subject: Java ignores/errors canonicalized principals (NT-PRINCIPAL) from
 Active Directory
In-Reply-To: <18E063BE-8413-4DAE-9086-7FE72BB33F36@oracle.com>
References: <0b9c7c31-bf21-03f0-9cae-a16f27f3f29b@siemens.com>
 <18E063BE-8413-4DAE-9086-7FE72BB33F36@oracle.com>
Message-ID: <2e18449d-3609-1b6e-9dec-538cc73bbdc5@siemens.com>

Am 2021-10-21 um 21:38 schrieb Wei-Jun Wang:
> 
>   KrbKdcReq throws the exception on line 55, so it is the previous check
> 
>          if (isAsReq && !req.reqBody.cname.equals(rep.cname) &&
>                  ((!req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) &&
>                  req.reqBody.cname.getNameType() !=
>                  PrincipalName.KRB_NT_ENTERPRISE) ||
>                   !rep.encKDCRepPart.flags.get(Krb5.TKT_OPTS_ENC_PA_REP))) {
>              rep.encKDCRepPart.key.destroy();
>>>>          throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED);
>          }
> 
> So maybe it's the cname was changed, but I'm not sure about the flags.
> 
> Can you send me some packets? Hopefully with a key tab or password so I can look into rep.encKDCRepPart.


I misread the block, of course it is this one. the crealm is changing an 
I am not providing an enterprise principal.

Sent you the pcap file. If this isn't enough, will prepare with a keytab.

Michael

From aefimov at openjdk.java.net  Fri Oct 22 14:27:41 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 22 Oct 2021 14:27:41 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

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

  More javadoc updates to API classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/2a554c91..fa655be2

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

  Stats: 88 lines in 3 files changed: 22 ins; 8 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

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

From djelinski1 at gmail.com  Fri Oct 22 15:14:31 2021
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 22 Oct 2021 17:14:31 +0200
Subject: Bug / performance problem in changeCipherSuite
Message-ID: <CAMrH03LOvb5Wt4GFfuDxpBtxO3NSS+ah4HskTSWE-pXK_7kNoQ@mail.gmail.com>

Hi all,
During routine examination of thread dumps I noticed a stack trace you
may find interesting. Relevant part:

   java.lang.Thread.State: RUNNABLE
...
at java.lang.IllegalStateException.<init>(java.base at 11.0.11/Unknown Source)
at javax.crypto.Cipher.checkCipherState(java.base at 11.0.11/Unknown Source)
at javax.crypto.Cipher.doFinal(java.base at 11.0.11/Unknown Source)
at sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.dispose(java.base at 11.0.11/Unknown
Source)
at sun.security.ssl.InputRecord.changeReadCiphers(java.base at 11.0.11/Unknown
Source)
at sun.security.ssl.ChangeCipherSpec$T10ChangeCipherSpecConsumer.consume(java.base at 11.0.11/Unknown
Source)
...

All handshakes that negotiate GCM ciphers throw and catch an
exception, because the newly created cipher is disposed before use.

I believe this is caused by this line of code:
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L125

I think it should read as follows:
this.readCipher.dispose();

I can file a PR, just need help with JBS ID.
Regards,
Daniel

From aefimov at openjdk.java.net  Fri Oct 22 15:17:04 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 22 Oct 2021 15:17:04 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <ivcy8D5adbsN4lpF33q7d8XpBP39fLGfgaajkerWvwA=.e0cb8f51-3de9-4698-977e-387fba7c5c31@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <ivcy8D5adbsN4lpF33q7d8XpBP39fLGfgaajkerWvwA=.e0cb8f51-3de9-4698-977e-387fba7c5c31@github.com>
Message-ID: <j5HoGEu1-EE1wpgY-BuplYr3WYWlduMDa-_q49c0S1A=.3ec67b6c-f959-43ff-a969-c07f0eebfc1e@github.com>

On Wed, 20 Oct 2021 15:41:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change InetAddressResolver method names
>
> Marked as reviewed by dfuchs (Reviewer).

@dfuch @AlanBateman

fa655be2bb0a402b70916567d34cc29a7898f938 and 2a554c91864e3b42a0ea315b0a671782fe341927 contain reworked `InetAddress`/`InetAddressResolverProvider`/`InetAddressResolver` specs with the following changes:
- `InetAddress Resolver Providers` InetAddress section was modified and moved to `InetAddressResolverProvider`.
- `Host Name Resolution` InetAddress section was updated to reference new InetAddress resolver SPI.
- Changes for previous review comments.
- javadoc formatting clean-up

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

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

From michael.osipov at siemens.com  Fri Oct 22 16:25:31 2021
From: michael.osipov at siemens.com (Osipov, Michael (LDA IT PLM))
Date: Fri, 22 Oct 2021 18:25:31 +0200
Subject: Java ignores/errors canonicalized principals (NT-PRINCIPAL) from
 Active Directory
In-Reply-To: <0b9c7c31-bf21-03f0-9cae-a16f27f3f29b@siemens.com>
References: <0b9c7c31-bf21-03f0-9cae-a16f27f3f29b@siemens.com>
Message-ID: <613ac829-50c7-555e-244f-173c63674077@siemens.com>

Apoligies, the Java kinit run was not performed with the correct 
krb5.conf. I have now repeated with the proper one and the stacktrace 
fits the code and my analysis now:

> C:\Users\osipovmi>kinit osipovmi at ad001.siemens.net
> Picked up _JAVA_OPTIONS: -Dsun.security.krb5.debug=false -Djava.security.krb5.conf=C:\Config\Kerberos\krb5.conf
> Password for osipovmi at ad001.siemens.net:
> Exception: krb_error 41 Message stream modified (41) Message stream modified
> KrbException: Message stream modified (41)
>         at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:69)
>         at sun.security.krb5.KrbAsRep.decrypt(KrbAsRep.java:159)
>         at sun.security.krb5.KrbAsRep.decryptUsingPassword(KrbAsRep.java:139)
>         at sun.security.krb5.KrbAsReqBuilder.resolve(KrbAsReqBuilder.java:312)
>         at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:498)
>         at sun.security.krb5.internal.tools.Kinit.acquire(Kinit.java:248)
>         at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:134)
>         at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:96)

I am pretty confident that the sname realm string is the cause here.

Michael

Am 2021-10-20 um 10:03 schrieb Osipov, Michael (LDA IT PLM):
> Hi folks,
> 
> we have recently noticed the following with Java's kinit (tested with 
> Zulu 8 and 13, code is identical in 18 as well):
> 
>> C:\Users\osipovmi>kinit osipovmi at ad001.siemens.net
> 
> I have intentionally written the realm in lowercase to rely on 
> canonicalization of the AD KDC. krb5.conf contains "canonicalize = true" 
> as well.
> 
> Wireshark shows me in the AS-REQ:
> as-req/req-body/sname: name-type KRB5-NT-SRV-INST (2), sname-string (2): 
> krbtgt and ad001.siemens.net
> 
> AS-REP:
> as-rep/ticket/sname: name-type KRB5-NT-SRV-INST (2), sname-string (2): 
> krbtgt and AD001.SIEMENS.NET
> 
> Hence, the KDC has properly canonicalized the sname. Java gives me:
> 
>> Exception: krb_error 41 Message stream modified (41) Message stream 
>> modified
>> KrbException: Message stream modified (41)
>> ??????? at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:55)
>> ??????? at sun.security.krb5.KrbAsRep.decrypt(KrbAsRep.java:159)
>> ??????? at 
>> sun.security.krb5.KrbAsRep.decryptUsingPassword(KrbAsRep.java:139)
>> ??????? at 
>> sun.security.krb5.KrbAsReqBuilder.resolve(KrbAsReqBuilder.java:312)
>> ??????? at 
>> sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:498)
>> ??????? at sun.security.krb5.internal.tools.Kinit.acquire(Kinit.java:248)
>> ??????? at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:134)
>> ??????? at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:96)
> 
> Referrals aren't involved here, same realm.
> The failing code block is from:
> * 
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/9a751dc19fae78ce58fb0eb176522070c992fb6f/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java#L58-L71 
> 
> * 
> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/ff4997014fe5462dca2b313f3f483400ffee5b62/src/java.security.jgss/share/classes/sun/security/krb5/KrbKdcRep.java#L58-L71 
> 
> 
>> ??????? // sname change in TGS-REP is allowed only if client
>> ??????? // sent CANONICALIZE and new sname is a referral of
>> ??????? // the form krbtgt/TO-REALM.COM at FROM-REALM.COM.
>> ??????? if (!req.reqBody.sname.equals(rep.encKDCRepPart.sname)) {
>> ??????????? String[] snameStrings = 
>> rep.encKDCRepPart.sname.getNameStrings();
>> ??????????? if (isAsReq || 
>> !req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) ||
>> ??????????????????? snameStrings == null || snameStrings.length != 2 ||
>>                     
>> !snameStrings[0].equals(PrincipalName.TGS_DEFAULT_SRV_NAME) ||
>> ??????????????????? !rep.encKDCRepPart.sname.getRealmString().equals(
>> ??????????????????????????? req.reqBody.sname.getRealmString())) {
>> ??????????????? rep.encKDCRepPart.key.destroy();
>> ??????????????? throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED);
>> ??????????? }
>> ??????? }
> 
> So it either fails for
>> isAsReq 
> or
>> !rep.encKDCRepPart.sname.getRealmString().equals(
>>> ??????????????????????????? req.reqBody.sname.getRealmString())
> 
> Here is MIT Kerberos:
>> $ kinit OSIPOVMI at ad001.siemens.net
>> Passwort f?r OSIPOVMI at ad001.siemens.net:
>> $ klist
>> Ticketzwischenspeicher: FILE:/tmp/krb5cc_722
>> Standard-Principal: osipovmi at AD001.SIEMENS.NET
>>
>> Valid starting?????? Expires????????????? Service principal
>> 20.10.2021 10:02:14? 20.10.2021 20:02:14  
>> krbtgt/AD001.SIEMENS.NET at AD001.SIEMENS.NET
>> ??????? erneuern bis 21.10.2021 10:02:10
> 
> Works as expected. Can someone explain? Shall I create a bug for this?
> 
> Michael


From valeriep at openjdk.java.net  Fri Oct 22 17:28:09 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 22 Oct 2021 17:28:09 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v3]
In-Reply-To: <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
Message-ID: <uMSDBONhDlSvki0Sev7mekk2efATJyStN3g8Y7ujO1I=.cd030ee5-6d19-4f5e-b8fe-f543a208dc66@github.com>

On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception handling

Changes look fine. Have you run through all security regression tests besides those under sun/security/rsa?

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

Marked as reviewed by valeriep (Reviewer).

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

From xuelei.fan at oracle.com  Fri Oct 22 17:28:51 2021
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 22 Oct 2021 17:28:51 +0000
Subject: Bug / performance problem in changeCipherSuite
In-Reply-To: <CAMrH03LOvb5Wt4GFfuDxpBtxO3NSS+ah4HskTSWE-pXK_7kNoQ@mail.gmail.com>
References: <CAMrH03LOvb5Wt4GFfuDxpBtxO3NSS+ah4HskTSWE-pXK_7kNoQ@mail.gmail.com>
Message-ID: <0E7C2CA8-DF7D-4E64-BB02-7E0BA73846D4@oracle.com>

Hi Daniel,

Thank you for the nice catch!  I filed a JBS bug:
    https://bugs.openjdk.java.net/browse/JDK-8275811

It would be nice if you could also update similar issues in (DTLS)OutRecord files.

Thanks,
Xuelei

On Oct 22, 2021, at 8:14 AM, Daniel Jeli?ski <djelinski1 at gmail.com<mailto:djelinski1 at gmail.com>> wrote:

Hi all,
During routine examination of thread dumps I noticed a stack trace you
may find interesting. Relevant part:

  java.lang.Thread.State: RUNNABLE
...
at java.lang.IllegalStateException.<init>(java.base at 11.0.11/Unknown Source)
at javax.crypto.Cipher.checkCipherState(java.base at 11.0.11/Unknown Source)
at javax.crypto.Cipher.doFinal(java.base at 11.0.11/Unknown Source)
at sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.dispose(java.base at 11.0.11/Unknown
Source)
at sun.security.ssl.InputRecord.changeReadCiphers(java.base at 11.0.11/Unknown
Source)
at sun.security.ssl.ChangeCipherSpec$T10ChangeCipherSpecConsumer.consume(java.base at 11.0.11/Unknown
Source)
...

All handshakes that negotiate GCM ciphers throw and catch an
exception, because the newly created cipher is disposed before use.

I believe this is caused by this line of code:
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L125

I think it should read as follows:
this.readCipher.dispose();

I can file a PR, just need help with JBS ID.
Regards,
Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20211022/9742be5e/attachment.htm>

From mkoncek at redhat.com  Fri Oct 22 07:50:38 2021
From: mkoncek at redhat.com (=?UTF-8?B?TWFyacOhbiBLb27EjWVr?=)
Date: Fri, 22 Oct 2021 09:50:38 +0200
Subject: Openjdk build failure in slowdebug mode
Message-ID: <98b023b5-05f6-4da3-928d-9e1038299dc5@redhat.com>

I would like to point your attention to this issue
https://github.com/openjdk/jdk/pull/5123

Simple 2 compiler warnings / errors because -Werror when building 
openjdk in slowdebug mode and a simple fix.

-- 
Mari?n Kon?ek


From xuelei at openjdk.java.net  Fri Oct 22 18:01:10 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 22 Oct 2021 18:01:10 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v3]
In-Reply-To: <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
Message-ID: <KdKMSmIc-odKSR0ItS50agbGFKCq1q36vhIiL0TVr08=.c9e3e1f7-8c6e-41a3-8ada-fb0d84afa195@github.com>

On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception handling

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 212:

> 210:      */
> 211:     private void isPrivateKeyValid(RSAPrivateKey prKey)  throws InvalidKeyException {
> 212:         InvalidKeyException ikException = null;

If I read the code correct, by define a local variable, it looks like you are trying to avoid to re-throw the exception in the catch clause.  But this style adds additional effort to read the code.  Exception re-throw should be fine as if the exception has been generated and will be thrown in the end of the method.

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 220:

> 218:                             crtKey.getPublicExponent());
> 219:                 } else {
> 220:                     ikException = new InvalidKeyException(

See above comment, I will just throw the exception, rather than cache it.

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

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

From duke at openjdk.java.net  Fri Oct 22 18:39:20 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 22 Oct 2021 18:39:20 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
Message-ID: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>

The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.

DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

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

Commit messages:
 - Dispose correct cipher

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

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

From djelinski1 at gmail.com  Fri Oct 22 18:40:19 2021
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 22 Oct 2021 20:40:19 +0200
Subject: Bug / performance problem in changeCipherSuite
In-Reply-To: <0E7C2CA8-DF7D-4E64-BB02-7E0BA73846D4@oracle.com>
References: <CAMrH03LOvb5Wt4GFfuDxpBtxO3NSS+ah4HskTSWE-pXK_7kNoQ@mail.gmail.com>
 <0E7C2CA8-DF7D-4E64-BB02-7E0BA73846D4@oracle.com>
Message-ID: <CAMrH03L_Rzy9USMuW5u=TcWhKrK+6vtV9=tcjvWmBhebedFB_A@mail.gmail.com>

Thanks Xuelei for the JBS ticket and the hint. PR is on its way.
Regards,
Daniel

pt., 22 pa? 2021 o 19:28 Xuelei Fan <xuelei.fan at oracle.com> napisa?(a):
>
> Hi Daniel,
>
> Thank you for the nice catch!  I filed a JBS bug:
>     https://bugs.openjdk.java.net/browse/JDK-8275811
>
> It would be nice if you could also update similar issues in (DTLS)OutRecord files.
>
> Thanks,
> Xuelei
>
> On Oct 22, 2021, at 8:14 AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>
> Hi all,
> During routine examination of thread dumps I noticed a stack trace you
> may find interesting. Relevant part:
>
>   java.lang.Thread.State: RUNNABLE
> ...
> at java.lang.IllegalStateException.<init>(java.base at 11.0.11/Unknown Source)
> at javax.crypto.Cipher.checkCipherState(java.base at 11.0.11/Unknown Source)
> at javax.crypto.Cipher.doFinal(java.base at 11.0.11/Unknown Source)
> at sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.dispose(java.base at 11.0.11/Unknown
> Source)
> at sun.security.ssl.InputRecord.changeReadCiphers(java.base at 11.0.11/Unknown
> Source)
> at sun.security.ssl.ChangeCipherSpec$T10ChangeCipherSpecConsumer.consume(java.base at 11.0.11/Unknown
> Source)
> ...
>
> All handshakes that negotiate GCM ciphers throw and catch an
> exception, because the newly created cipher is disposed before use.
>
> I believe this is caused by this line of code:
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L125
>
> I think it should read as follows:
> this.readCipher.dispose();
>
> I can file a PR, just need help with JBS ID.
> Regards,
> Daniel
>
>

From abakhtin at openjdk.java.net  Fri Oct 22 18:45:31 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 22 Oct 2021 18:45:31 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v4]
In-Reply-To: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
Message-ID: <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>

> Hello,
> 
> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
> 
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
> If not applied, implementation can try to select signer from other providers
> 
> Regards
> Alexey

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

  Simplified isPrivateKeyValid

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4887/files
  - new: https://git.openjdk.java.net/jdk/pull/4887/files/df6f212d..ede6436f

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

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

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

From abakhtin at openjdk.java.net  Fri Oct 22 18:45:33 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 22 Oct 2021 18:45:33 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v3]
In-Reply-To: <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
Message-ID: <_28mhYijASDHGOsRZZG6xVDHuDAnGol5Dvc3wsnjKQ8=.2b49952d-6f55-41f3-847f-d0d29e756ba5@github.com>

On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception handling

Agree, It looks less readable. Just tried to avoid rethrowing the exception. Reverted back to the original version.

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

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

From xuelei at openjdk.java.net  Fri Oct 22 18:48:06 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 22 Oct 2021 18:48:06 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>

On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

Did you want to cover the update for line 222 at OutputRecord.java as well?

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

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

From xuelei at openjdk.java.net  Fri Oct 22 18:51:05 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 22 Oct 2021 18:51:05 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v4]
In-Reply-To: <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
Message-ID: <r2c2l9TjyGJYwkmi6Ep75EQQjnqR-c0GbzZUKdftXwY=.2124f38a-edae-41ac-b564-2b2f4a02168b@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified isPrivateKeyValid

It looks good to me. Please make sure to run all security regression tests.  Thank you!

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

Marked as reviewed by xuelei (Reviewer).

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

From abakhtin at openjdk.java.net  Fri Oct 22 18:51:06 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 22 Oct 2021 18:51:06 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v3]
In-Reply-To: <uMSDBONhDlSvki0Sev7mekk2efATJyStN3g8Y7ujO1I=.cd030ee5-6d19-4f5e-b8fe-f543a208dc66@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <D6dPLbA0wZpy5m983QD9FYbtjVWZW0eaZujbbioqkK4=.950f96ce-b1fc-449d-9db6-d64a721a4399@github.com>
 <uMSDBONhDlSvki0Sev7mekk2efATJyStN3g8Y7ujO1I=.cd030ee5-6d19-4f5e-b8fe-f543a208dc66@github.com>
Message-ID: <JTWDpnS69Q6FBj3mAS0U6WOCGhwfB072kXJTP0tW_mA=.f754b9d2-5104-4c61-bf10-bbdcd0ff5729@github.com>

On Fri, 22 Oct 2021 17:24:36 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Changes look fine. Have you run through all security regression tests besides those under sun/security/rsa?

Hi @valeriepeng,
Yes, I've run this code with all security tests. Passed successfully.

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

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

From duke at openjdk.java.net  Fri Oct 22 19:25:38 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 22 Oct 2021 19:25:38 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v2]
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <9OawC5SQCKWnVma0bpKEE1JO80H985cFsYgvo8mjXWg=.b2848966-63da-4429-aba4-b675f1ede751@github.com>

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

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

  Fix one more case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6084/files
  - new: https://git.openjdk.java.net/jdk/pull/6084/files/773c073c..1ee99ae4

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

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

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

From duke at openjdk.java.net  Fri Oct 22 19:25:40 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 22 Oct 2021 19:25:40 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <_7twUFuhtlhhnd-l2913fJrjMj5aynKKrEjAuCWSN8Y=.79eb255e-7f1a-4c21-9c38-9243eada0b16@github.com>

On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

Ah, missed that one. Fixed.

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

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

From xuelei at openjdk.java.net  Fri Oct 22 20:03:09 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 22 Oct 2021 20:03:09 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v2]
In-Reply-To: <9OawC5SQCKWnVma0bpKEE1JO80H985cFsYgvo8mjXWg=.b2848966-63da-4429-aba4-b675f1ede751@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <9OawC5SQCKWnVma0bpKEE1JO80H985cFsYgvo8mjXWg=.b2848966-63da-4429-aba4-b675f1ede751@github.com>
Message-ID: <TTQcQhPVxyYR5l5Mdn5IpcakcTB45p5g_nDV-343m-4=.03983e0d-26cf-462d-8dcf-441ebb014b34@github.com>

On Fri, 22 Oct 2021 19:25:38 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one more case

Looks good to me.  Thank you!

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

Marked as reviewed by xuelei (Reviewer).

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

From duke at openjdk.java.net  Fri Oct 22 20:22:06 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 22 Oct 2021 20:22:06 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
Message-ID: <VAPnB-j0OZREPa68p-TxGGUaBFxFK72BTWT_1n1IF_g=.bbc4547e-ffe7-4511-be24-450107cdbe35@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Did you want to cover the update for line 222 at OutputRecord.java as well?

Thanks @XueleiFan , but I guess this needs a bit more love. Just finished running jdk_security tests, and a few tests failed, apparently related:
javax/net/ssl/SSLEngine/NoAuthClientAuth.java
javax/net/ssl/TLSv1/TLSRehandshakeTest.java
javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java
javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java
javax/net/ssl/TLSv11/TLSRehandshakeTest.java
javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java

I'll see if I can figure this out.

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

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

From abakhtin at openjdk.java.net  Fri Oct 22 20:30:10 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 22 Oct 2021 20:30:10 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v4]
In-Reply-To: <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
Message-ID: <7pOLnQ7qUU83EhbzDOvtDZupqAsUjix3ZQkxuQk3_QQ=.8dac2c68-72a8-4a10-bb79-7d45985a7429@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified isPrivateKeyValid

Thank you all. :jdk_security tests passed without regression

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

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

From hchao at openjdk.java.net  Fri Oct 22 20:57:16 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 22 Oct 2021 20:57:16 GMT
Subject: Integrated: 8272163: Add -version option to keytool and jarsigner
In-Reply-To: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
References: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com>
Message-ID: <h8qMd2q-6wBr75ypmJTWV0b7LDdvyElfiEhp1xHciD8=.78b5ad4a-3cc7-4e0b-bad6-8207070bcd3d@github.com>

On Thu, 14 Oct 2021 16:04:08 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does.
> 
> CSR review:
> https://bugs.openjdk.java.net/browse/JDK-8275174

This pull request has now been integrated.

Changeset: fec470f2
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fec470f262d1df581f2a5fc2f0bdfea66757a8ad
Stats:     213 lines in 6 files changed: 212 ins; 0 del; 1 mod

8272163: Add -version option to keytool and jarsigner

Reviewed-by: weijun

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

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

From mullan at openjdk.java.net  Fri Oct 22 21:18:07 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 22 Oct 2021 21:18:07 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <MlfS0K_HVAObL49Kn8Wpeh88uUAMf5DjDgW1MH2i2Z4=.0f3632fc-9441-414b-a009-871d9ee7f65e@github.com>

On Thu, 5 Aug 2021 20:10:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

Still reviewing but here are some initial minor comments.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java line 67:

> 65: 
> 66:         @SuppressWarnings("removal")
> 67:         Subject accSubj = Subject.current();

Change variable name to `currentSubj` or `currSubj`?

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java line 68:

> 66:         @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
> 67: 
> 68:         // Try to get ticket from acc's Subject

Is this comment still helpful? Maybe just change it to `// Try to get ticket from current Subject`

test/jdk/java/security/AccessController/PreserveCombiner.java line 46:

> 44: 
> 45:                 // get subject from current ACC - this always worked
> 46:                 Subject doAsSubject = Subject.current();

Nit: change variable name to `callAsSubject`.

test/jdk/sun/security/krb5/auto/Context.java line 114:

> 112:                 }
> 113:             });
> 114:         } catch (CompletionException pae) {

Maybe rename the variable to `ce`. Same comment below.

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

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

From duke at openjdk.java.net  Fri Oct 22 22:10:02 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 22 Oct 2021 22:10:02 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v2]
In-Reply-To: <9OawC5SQCKWnVma0bpKEE1JO80H985cFsYgvo8mjXWg=.b2848966-63da-4429-aba4-b675f1ede751@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <9OawC5SQCKWnVma0bpKEE1JO80H985cFsYgvo8mjXWg=.b2848966-63da-4429-aba4-b675f1ede751@github.com>
Message-ID: <EhAkhW6p7ah0bSoqTfWJ3EZnraSPW1XyrfcXrpEQNhw=.32ac8357-bb75-43f0-8ab2-b53a620a903f@github.com>

On Fri, 22 Oct 2021 19:25:38 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one more case

The problem is with SSLEngine; we create the ChangeCipherSpec message in a delegated task, then encrypt it later using memoized cipher:

	at java.base/sun.security.ssl.SSLCipher$T10BlockWriteCipherGenerator$BlockWriteCipher.encrypt(SSLCipher.java:1206)
	at java.base/sun.security.ssl.OutputRecord.t10Encrypt(OutputRecord.java:441)
	at java.base/sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:345)
	at java.base/sun.security.ssl.SSLEngineOutputRecord$HandshakeFragment.acquireCiphertext(SSLEngineOutputRecord.java:518)
	at java.base/sun.security.ssl.SSLEngineOutputRecord.acquireCiphertext(SSLEngineOutputRecord.java:346)
	at java.base/sun.security.ssl.SSLEngineOutputRecord.encode(SSLEngineOutputRecord.java:198)

(line numbers may be off a bit)

If the memoized cipher is disposed, the operation produces incorrect output. This happens only when ChangeCipherSpec or KeyUpdate is encrypted and we're using SSLEngine.

Looks like we can move writeCipher disposal to the relevant OutputRecord subclasses. Will look into it.

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

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

From ascarpino at openjdk.java.net  Sat Oct 23 00:00:14 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Sat, 23 Oct 2021 00:00:14 GMT
Subject: RFR: 8158689: java.security.KeyPair should implement Destroyable
Message-ID: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>

Hi,

I need a review of this change.  It makes KeyPair implement Destroyable and implements the methods to call the underlying privateKey.  It also sets the public and private key to 'final'.

The bug includes a CSR and Release Notes
CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
RN: https://bugs.openjdk.java.net/browse/JDK-8275826

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

Commit messages:
 - initial fix

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

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

From weijun at openjdk.java.net  Sat Oct 23 00:40:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 23 Oct 2021 00:40:39 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

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

  renames

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5024/files
  - new: https://git.openjdk.java.net/jdk/pull/5024/files/7c99d9b7..2f862e02

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

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

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

From weijun at openjdk.java.net  Sat Oct 23 00:43:04 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 23 Oct 2021 00:43:04 GMT
Subject: RFR: 8158689: java.security.KeyPair should implement Destroyable
In-Reply-To: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
References: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
Message-ID: <fBs9NCgnUd-eJ-PHMFS4Z0elhQlSzekXC5zBiwvq2QE=.a9615976-1e28-484f-a10d-884f544f31ec@github.com>

On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this change.  It makes KeyPair implement Destroyable and implements the methods to call the underlying privateKey.  It also sets the public and private key to 'final'.
> 
> The bug includes a CSR and Release Notes
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
> RN: https://bugs.openjdk.java.net/browse/JDK-8275826

`KeyPair::getPrivateKey` returns the private key inside (i.e. not a clone). Why can't we just destroy it?

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

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

From ascarpino at openjdk.java.net  Sat Oct 23 00:53:59 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Sat, 23 Oct 2021 00:53:59 GMT
Subject: RFR: 8158689: java.security.KeyPair should implement Destroyable
In-Reply-To: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
References: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
Message-ID: <du6GtDSup7DKex6kg77B0OQcza9p2HIavaABD2zNSvQ=.e4d940dc-2cbd-4c42-bc09-6d5e09af2110@github.com>

On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this change.  It makes KeyPair implement Destroyable and implements the methods to call the underlying privateKey.  It also sets the public and private key to 'final'.
> 
> The bug includes a CSR and Release Notes
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
> RN: https://bugs.openjdk.java.net/browse/JDK-8275826

You can, it's just a multi-step process that should have been available from KeyPair in a single step process

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

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

From ascarpino at openjdk.java.net  Sat Oct 23 01:02:03 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Sat, 23 Oct 2021 01:02:03 GMT
Subject: RFR: 8158689: java.security.KeyPair should implement Destroyable
In-Reply-To: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
References: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
Message-ID: <-Y_uusQyoW6BGMjl79wCuYK02Qbk-KCdgrwlPUD_f5c=.153b529b-a10c-46e6-814b-70342d4144f1@github.com>

On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this change.  It makes KeyPair implement Destroyable and implements the methods to call the underlying privateKey.  It also sets the public and private key to 'final'.
> 
> The bug includes a CSR and Release Notes
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
> RN: https://bugs.openjdk.java.net/browse/JDK-8275826

Even though it has been the only option for a long time, calling `keyPair.getPrivateKey().destory()` is not clean and one should not have had to go into a class's objects to cleanup.   It's reminiscent of free memory in C.

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

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

From weijun at openjdk.java.net  Sat Oct 23 01:15:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 23 Oct 2021 01:15:05 GMT
Subject: RFR: 8158689: java.security.KeyPair should implement Destroyable
In-Reply-To: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
References: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
Message-ID: <vCKom9fgKKJ6WdREt19R0AON-ASzhY5s7evodtzto1s=.589eb3aa-3ef5-4845-9a33-25fd099e4f08@github.com>

On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this change.  It makes KeyPair implement Destroyable and implements the methods to call the underlying privateKey.  It also sets the public and private key to 'final'.
> 
> The bug includes a CSR and Release Notes
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
> RN: https://bugs.openjdk.java.net/browse/JDK-8275826

I just think this is not worth doing. Plus, there are conventions for `Destroyable` that need to be followed. For example, after one call `destroy()` on a `KeyPair`, can `getPrivateKey()` still be called? Should it throw an `IllegalStateException`?

Also, `PrivateKey` has implemented `Destroyable `for quite some time and it looks like none of its implementations inside JDK has actually implemented this method. This seems a more valuable thing to do. There are other interfaces like `KeySpec` (or some of its children) that should also implement `Destroyable`.

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

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

From duke at openjdk.java.net  Sat Oct 23 01:55:05 2021
From: duke at openjdk.java.net (Bernd)
Date: Sat, 23 Oct 2021 01:55:05 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
Message-ID: <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>

On Sat, 23 Oct 2021 00:40:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renames

Hello,

overall I think the new api is really need. Just wonder if it needs a way to restrict subject changes in called sections (to replace security manager) and also if the test cases should all run for both environment settings for SubjectTL.

src/java.base/share/classes/javax/security/auth/Subject.java line 325:

> 323: 
> 324:     // Store the current subject to a ThreadLocal when a system property is set.
> 325:     private static final boolean USE_TL = "true".equalsIgnoreCase(

Can you use GetBooleanAction.privilegedGetProperty instead?

src/java.base/share/classes/javax/security/auth/Subject.java line 349:

> 347:      * the one of its parent thread, and will not change even if
> 348:      * its parent thread's current subject is changed to another value.
> 349:      *

Should it say something about installing or unsettling the subject in a nested execution (if it can be restricted)?

src/java.base/share/classes/javax/security/auth/Subject.java line 393:

> 391:      * always be retrievable by the {@link #current} method.
> 392:      *
> 393:      * @param subject the intended current subject for {@code action}.

The ?current? could be removed to make it less complex to read? (Especially if the next parameter still uses the ?current? term.

src/java.base/share/classes/javax/security/auth/Subject.java line 475:

> 473:      *       call {@link #callAs} to perform the same work, which is based on
> 474:      *       {@link #doAs(Subject, PrivilegedExceptionAction)}
> 475:      *       by default in this implementation.

Should it also mention that unless you define the TL system property it will still affect the new current() call? (Just to introduce the concept by repetition).

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 708:

> 706:                             @SuppressWarnings("removal")
> 707:                             final Subject subject =
> 708:                                 AccessController.doPrivilegedWithCombiner(

Is this actually needed and correct to wrap this into a priveledged action?

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java line 107:

> 105:      */
> 106:     public static ServiceCreds getServiceCreds(GSSCaller caller,
> 107:             String serverPrincipal) throws LoginException {

What would be the new way to pass an authentication context on, passing the subject directly? (In case of Krb5AcceptCredential acc is actually the current one)

test/jdk/javax/security/auth/Subject/DoAs.java line 44:

> 42:             final int index = i;
> 43:             Subject.callAs(subject, () -> {
> 44:                 Subject s = Subject.current();

Should it Test old and new method to retrieve subject?

test/jdk/sun/security/krb5/KrbCredSubKey.java line 34:

> 32: 
> 33: import java.io.FileOutputStream;
> 34: import java.util.concurrent.Callable;

Should those tests run with both permutations of the system property?

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

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

From duke at openjdk.java.net  Sat Oct 23 01:55:06 2021
From: duke at openjdk.java.net (Bernd)
Date: Sat, 23 Oct 2021 01:55:06 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
Message-ID: <lYawYuiUg4IdjRtfR-DRVlcw2FXJ9bYbIGN6VOBazyk=.e35380e2-302d-42eb-b25b-9cacdd87ed5a@github.com>

On Fri, 22 Oct 2021 22:00:57 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java line 107:
> 
>> 105:      */
>> 106:     public static ServiceCreds getServiceCreds(GSSCaller caller,
>> 107:             String serverPrincipal) throws LoginException {
> 
> What would be the new way to pass an authentication context on, passing the subject directly? (In case of Krb5AcceptCredential acc is actually the current one)

What about the Kerberos cipher suite callsite mentioned in the comment? If no longer used, can this be made not Public (and remove the comment)

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

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

From duke at openjdk.java.net  Sat Oct 23 05:30:07 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 23 Oct 2021 05:30:07 GMT
Subject: Withdrawn: 6859027: Duplicate communications to KDC in
 GSSManager.createCredential(usage)
In-Reply-To: <S2rTRcpVV0LZ--XIkGSUBQ2j_MJ3yv6B5hnTGBn188c=.6d2d5a69-2739-4f05-872b-68b0fd3ee592@github.com>
References: <S2rTRcpVV0LZ--XIkGSUBQ2j_MJ3yv6B5hnTGBn188c=.6d2d5a69-2739-4f05-872b-68b0fd3ee592@github.com>
Message-ID: <XlQGv3i52z7PBFmG0L7PxO-pUITqaA8SwiDb4XxYV34=.7705112e-df48-4441-92cd-6b5d4e75a48b@github.com>

On Fri, 27 Aug 2021 19:47:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A one slot ccache is added to avoid multiple authentication from the same principal.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Sat Oct 23 06:57:33 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 23 Oct 2021 06:57:33 GMT
Subject: RFR: 8275811 Incorrect instance to dispose [v3]
In-Reply-To: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
Message-ID: <T12gFC873MbrPycG0kQFGzrrkEAS8gRpHdMvT6qBF4w=.ef398401-8a7b-4c8a-9db4-6b0f335da645@github.com>

> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
> 
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)

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

  Do not dispose writeCipher in changeCipherSpec - we may still need it

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6084/files
  - new: https://git.openjdk.java.net/jdk/pull/6084/files/1ee99ae4..dfc1a9ee

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

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

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

From alanb at openjdk.java.net  Sat Oct 23 07:04:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Oct 2021 07:04:05 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
Message-ID: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>

On Fri, 22 Oct 2021 14:27:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More javadoc updates to API classes

I've done another pass over the API. Overall it's looking very good and my comments are just to improve the javadoc in a few places to make it clearer.

src/java.base/share/classes/java/net/InetAddress.java line 169:

> 167:  * Access Protocol (LDAP).
> 168:  * The particular naming services that the built-in resolver uses by default
> 169:  * depend on the configuration of the local machine.

depend -> depends

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 38:

> 36:  * deployed as a <a href="InetAddressResolverProvider.html#system-wide-resolver">
> 37:  * system-wide resolver</a>. {@link InetAddress} delegates all lookup requests to
> 38:  * the deployed <i>system-wide resolver</i> instance.

I think the class description would be a bit clearer if we drop sentence 2 because it overlaps with paragraph 2. I think we can adjust sentence 3 to "InetAddress delegates all lookup operations to the system-wide resolver" and it will all flow nicely.

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 88:

> 86:      *                                  to a valid IP address length
> 87:      */
> 88:     String lookupByAddress(byte[] addr) throws UnknownHostException;

I assume this throws NPE if addr is null.

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 137:

> 135:         /**
> 136:          * This factory method creates {@link LookupPolicy LookupPolicy} instance with a provided
> 137:          * {@code characteristics} value.

This should be "This factory method creates a LookupPolicy ...".

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45:

> 43:  * system-wide resolver instance, which is used by
> 44:  * <a href="{@docRoot}/java.base/java/net/InetAddress.html#host-name-resolution">
> 45:  * InetAddress</a>.

I think we should prune some some of the text from the class description to avoid repetition.  Here's a suggestion:

1. Add the following immediately after the sentence "A given innovation ..."
"It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 

2. Replace the text in L47-65 with:
"A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows:

3. Replace the remaining three usages of "install" with "set".

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

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

From alanb at openjdk.java.net  Sat Oct 23 07:04:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Oct 2021 07:04:06 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>
Message-ID: <XmR0-Viqe4WDCUYoa2pI-LTLkXlrHXUbHYIBWXXRm8o=.b000002f-94b0-466a-b605-8d6952df7f25@github.com>

On Wed, 20 Oct 2021 18:25:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change InetAddressResolver method names
>
> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52:
> 
>> 50:     /**
>> 51:      * Initialise and return the {@link InetAddressResolver} provided by
>> 52:      * this provider. This method is called by {@link InetAddress} when
> 
> "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that.

Initialise -> Initialize to be consistent with other usages that use US spelling.

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

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

From duke at openjdk.java.net  Sat Oct 23 07:10:02 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 23 Oct 2021 07:10:02 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
Message-ID: <NUSDMHo13PWhl6flxc7L6klJx7duG_AKsul7LvDxrZ0=.599e9fa3-4cfa-40e2-8acd-c475b41e34af@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Did you want to cover the update for line 222 at OutputRecord.java as well?

After reviewing the scope of changes to fix writeCipher disposal I decided to remove it entirely. It would probably be a nice follow-up enhancement, but I'm not confident I'd implement it correctly on the first try, so I'd rather not introduce it in a bugfix PR. @XueleiFan is that acceptable to you?

On a side note, I had another look at [DTLSOutputRecord](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106). It looks like we keep a reference to `prevWriteCipher` only to call `dispose()` during the next cipher change. I admit I don't know how often DTLS changes ciphers, but I think GC would have collected that cipher earlier if we didn't keep it.

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

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

From xuelei at openjdk.java.net  Sun Oct 24 05:03:06 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 24 Oct 2021 05:03:06 GMT
Subject: RFR: 8275811 Incorrect instance to dispose
In-Reply-To: <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
References: <aNl3RvkODDdhaq8Ifk0A9gk0-ylDXfD0tJXSPs9v_hM=.e330ac56-701a-4a42-ab0f-ec17f01cb1a3@github.com>
 <ewxnuaQXGUmqhAaoViJObil2yn0iQMAJfwByrAHbH7Q=.6c37963a-6df1-4a30-a1cd-065f4f2d5584@github.com>
Message-ID: <7PLZHlwJz9x2vSwKzSRqnqotW9KJOytFVbGRUgVwomA=.1ab389ec-728e-4451-bba4-779d97c685bd@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The current code that changes cipher suites disposes the new suite instead of the old one, which usually silently fails. This patch fixes the code to dispose the old instance instead.
>> 
>> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly [disposes the old one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), and DTLSInputRecord [doesn't dispose anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
>
> Did you want to cover the update for line 222 at OutputRecord.java as well?

> After reviewing the scope of changes to fix writeCipher disposal I decided to remove it entirely. It would probably be a nice follow-up enhancement, but I'm not confident I'd implement it correctly on the first try, so I'd rather not introduce it in a bugfix PR. @XueleiFan is that acceptable to you?
> 
I'm not sure of the removal.  Please hold on the integration, and I will have a further look if I have cycles.

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

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

From abakhtin at openjdk.java.net  Mon Oct 25 08:04:16 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 25 Oct 2021 08:04:16 GMT
Subject: Integrated: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key
In-Reply-To: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
Message-ID: <In_vjZSQiN5bBV39QBYQyQgo5yZ1ixDRdUSuVXsmxZM=.1b0e7c70-a21b-47f4-a5b0-9ab3582d4f15@github.com>

On Fri, 23 Jul 2021 10:33:14 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Hello,
> 
> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
> 
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
> If not applied, implementation can try to select signer from other providers
> 
> Regards
> Alexey

This pull request has now been integrated.

Changeset: f6232982
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f6232982b91cb2314e96ddbde3984836a810a556
Stats:     89 lines in 2 files changed: 69 ins; 14 del; 6 mod

8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key

Reviewed-by: xuelei, valeriep

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

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

From mullan at openjdk.java.net  Mon Oct 25 13:30:45 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 25 Oct 2021 13:30:45 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject,
 Issuer}AlternativeNames does
 not throw CertificateParsingException if extension is unparseable
Message-ID: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>

The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.

This fix changes the behavior to comply with the specification.

CSR: https://bugs.openjdk.java.net/browse/JDK-8275822

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

Commit messages:
 - Remove trailing whitespace.
 - 8251468: X509Certificate.get{Subject,Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

Changes: https://git.openjdk.java.net/jdk/pull/6106/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6106&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251468
  Stats: 199 lines in 4 files changed: 157 ins; 33 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6106/head:pull/6106

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

From weijun at openjdk.java.net  Mon Oct 25 14:23:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 14:23:08 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
Message-ID: <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>

On Mon, 25 Oct 2021 12:53:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.
> 
> This fix changes the behavior to comply with the specification.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275822

How about other `X509Certificate` methods that get info of an extension?

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

> 1616:         }
> 1617:         SubjectAlternativeNameExtension subjectAltNameExt =
> 1618:             getSubjectAlternativeNameExtension();

Does it make sense to let the line above throwing an exception? I see the method is called in several places (`X509CertSelector`, `Builder`, etc). What is the correct behavior in those places?

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

> 1689:         }
> 1690:         IssuerAlternativeNameExtension issuerAltNameExt =
> 1691:             getIssuerAlternativeNameExtension();

Same comment as above, but this method seems to be only called once in src.

test/jdk/java/security/cert/GetSubjectAlternativeNames/NullRFC822Name.java line 37:

> 35:  */
> 36: public class NullRFC822Name {
> 37: 

Adding a comment showing the ASN.1 fields would be a relief for the reader. OpenSSL shows:

//  430:d=4  hl=2 l=  11 cons: SEQUENCE
//  432:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
//  437:d=5  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:30028100

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

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

From mullan at openjdk.java.net  Mon Oct 25 14:40:11 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 25 Oct 2021 14:40:11 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
Message-ID: <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>

On Wed, 20 Oct 2021 02:08:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.

src/java.base/share/classes/java/security/KeyStore.java line 1035:

> 1033:      *      not extractable (For example, if the attributes is encrypted
> 1034:      *      in a private key entry or a secret key entry).
> 1035:      *

I think this would read better if you broke it up into multiple sentences, ex: "an unmodifiable {@code Set} of attributes. The set may be empty if the given alias does not exist, or the alias does exist but there are no attributes associated with it or the attributes are not extractable (for example, the attributes may not be extractable if they are encrypted in a private key or secret key entry)."

You may also want to add a sentence to try the `KeyStore$Entry::getAttributes` method if there are no attributes.

Did you consider throwing a KeyStoreException if they are not extractable? It would be useful to distinguish that case from an alias that has no attributes.

src/java.base/share/classes/java/security/KeyStore.java line 1038:

> 1036:      * @throws    KeyStoreException if the keystore has not been initialized
> 1037:      * (loaded).
> 1038:      *

throw NPE if alias is null?

src/java.base/share/classes/java/security/KeyStoreSpi.java line 450:

> 448:     /**
> 449:      * Retrieves the attributes associated with the given alias.
> 450:      *

You should also document the default implementation.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 457:

> 455:      */
> 456:     public Set<Entry.Attribute> engineGetAttributes(String alias) {
> 457:         return Collections.emptySet();

Would `Set.of()` be better here?

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

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

From mullan at openjdk.java.net  Mon Oct 25 15:10:10 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 25 Oct 2021 15:10:10 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
Message-ID: <EjoQcIaUpRdRXz7Jzz1KsZXsam3jIibbmU2xpUA9wX4=.f2af9719-7da5-4185-a4fe-089c0ec71844@github.com>

On Mon, 25 Oct 2021 14:20:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> How about other `X509Certificate` methods that get info of an extension?

Good question. There are 3: `getBasicConstraints`, `getKeyUsage` and `getExtendedKeyUsage`. The first two methods are not specified to throw an Exception, so that seems like a more significant change and I'm not sure it is worth it. Also, if they are marked critical, then an exception will be thrown when the X509Certificate is parsed.

As for `getExtendedKeyUsage`, it is specified to throw a `CertificateParsingException` but it looks like it also has the same problem as the altnames, so I will change the impl to comply with the spec.

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

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

From mullan at openjdk.java.net  Mon Oct 25 15:16:09 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 25 Oct 2021 15:16:09 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
Message-ID: <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>

On Mon, 25 Oct 2021 14:17:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.
>> 
>> This fix changes the behavior to comply with the specification.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8275822
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1618:
> 
>> 1616:         }
>> 1617:         SubjectAlternativeNameExtension subjectAltNameExt =
>> 1618:             getSubjectAlternativeNameExtension();
> 
> Does it make sense to let the line above throwing an exception? I see the method is called in several places (`X509CertSelector`, `Builder`, etc). What is the correct behavior in those places?

To clarify, do you mean this code in `getExtension(ObjectIdentifier)` that swallows the exception?:


        } catch (IOException ioe) {
            return null;
        }

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

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

From weijun at openjdk.java.net  Mon Oct 25 18:06:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 18:06:13 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
Message-ID: <4yomLmh_dnLfLEjGEKMd8dkdhmyYOCrAIrxrJk7LNCg=.4bb1d786-d986-445c-be56-c2455d5a46d0@github.com>

On Fri, 22 Oct 2021 21:45:25 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 325:
> 
>> 323: 
>> 324:     // Store the current subject to a ThreadLocal when a system property is set.
>> 325:     private static final boolean USE_TL = "true".equalsIgnoreCase(
> 
> Can you use GetBooleanAction.privilegedGetProperty instead?

Sure, I can. I was testing the default value to "false" at some time and found `"true".equals` and `!"false".equals` symmetric and good-looking. :-)

> src/java.base/share/classes/javax/security/auth/Subject.java line 349:
> 
>> 347:      * the one of its parent thread, and will not change even if
>> 348:      * its parent thread's current subject is changed to another value.
>> 349:      *
> 
> Should it say something about installing or unsettling the subject in a nested execution (if it can be restricted)?

I said "After {@code action} is finished, the current subject is reset to its previous value". Is that what you meant?

> src/java.base/share/classes/javax/security/auth/Subject.java line 393:
> 
>> 391:      * always be retrievable by the {@link #current} method.
>> 392:      *
>> 393:      * @param subject the intended current subject for {@code action}.
> 
> The ?current? could be removed to make it less complex to read? (Especially if the next parameter still uses the ?current? term.

OK, I can choose the existing `doAs` style. `the {@code Subject} that the specified {@code action} will run as`. I admit I specified this "current subject" too much. I even wanted to invent an acronym for it.

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

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

From weijun at openjdk.java.net  Mon Oct 25 18:11:07 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 18:11:07 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
Message-ID: <NByKzEbyrhEimH7mxpBKJ8-SvfqXSMITJGQynroRrhQ=.d0a89b01-1fa4-4bbd-a17a-b037bcab95d6@github.com>

On Fri, 22 Oct 2021 21:53:30 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 475:
> 
>> 473:      *       call {@link #callAs} to perform the same work, which is based on
>> 474:      *       {@link #doAs(Subject, PrivilegedExceptionAction)}
>> 475:      *       by default in this implementation.
> 
> Should it also mention that unless you define the TL system property it will still affect the new current() call? (Just to introduce the concept by repetition).

I just don't want to touch existing spec. Even for `doAs`, I only said "callAs is based on doAs by default" and didn't went out explaining what is NOT by default. Is that OK?

> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 708:
> 
>> 706:                             @SuppressWarnings("removal")
>> 707:                             final Subject subject =
>> 708:                                 AccessController.doPrivilegedWithCombiner(
> 
> Is this actually needed and correct to wrap this into a priveledged action?

Oh, it's needed. Otherwise the `AccessController.getContext()` call (which is inside `current()`) will also be called in a clean privileged context and there is no subject associated with it.

On the other hand, it still needs to in some sort of doPriv. I don't want to ignore `AuthPermission("getSubject")`.

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

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

From weijun at openjdk.java.net  Mon Oct 25 18:30:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 18:30:11 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <lYawYuiUg4IdjRtfR-DRVlcw2FXJ9bYbIGN6VOBazyk=.e35380e2-302d-42eb-b25b-9cacdd87ed5a@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <lYawYuiUg4IdjRtfR-DRVlcw2FXJ9bYbIGN6VOBazyk=.e35380e2-302d-42eb-b25b-9cacdd87ed5a@github.com>
Message-ID: <ujF6BE_VI2WTxEnUPClC0zNh4bkySVZNC6qwYGrpphQ=.1b7fd753-0122-4f96-895a-acd9ee068304@github.com>

On Fri, 22 Oct 2021 22:13:51 GMT, Bernd <duke at openjdk.java.net> wrote:

>> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java line 107:
>> 
>>> 105:      */
>>> 106:     public static ServiceCreds getServiceCreds(GSSCaller caller,
>>> 107:             String serverPrincipal) throws LoginException {
>> 
>> What would be the new way to pass an authentication context on, passing the subject directly? (In case of Krb5AcceptCredential acc is actually the current one)
>
> What about the Kerberos cipher suite callsite mentioned in the comment? If no longer used, can this be made not Public (and remove the comment)

Yes, it's better to pass the subject directly. Whoever wants their code to continue working after the SecurityManager is completely removed should not use AccessControlContext anymore.

Yes, the JSSE comment is useless now. I thought it was still used by older TLS versions.

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

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

From weijun at openjdk.java.net  Mon Oct 25 18:30:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 18:30:13 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
Message-ID: <dYhIBACoVnuBRvUAwD5BsWCac_r2PVGiijT7qa_sH-8=.8ea5526d-e736-4d00-a650-3b0e35d02216@github.com>

On Fri, 22 Oct 2021 22:07:50 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> test/jdk/javax/security/auth/Subject/DoAs.java line 44:
> 
>> 42:             final int index = i;
>> 43:             Subject.callAs(subject, () -> {
>> 44:                 Subject s = Subject.current();
> 
> Should it Test old and new method to retrieve subject?

I did it in `CurrentSubject.java` when test=both (checking `cas != accs` in `check()`). All changes to existing tests are just to avoid calling deprecated methods.

> test/jdk/sun/security/krb5/KrbCredSubKey.java line 34:
> 
>> 32: 
>> 33: import java.io.FileOutputStream;
>> 34: import java.util.concurrent.Callable;
> 
> Should those tests run with both permutations of the system property?

I did ran it but not sure if it's good  to add an extra `@run` to all tests. I'll select a few.

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

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

From weijun at openjdk.java.net  Mon Oct 25 18:30:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 18:30:13 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <dYhIBACoVnuBRvUAwD5BsWCac_r2PVGiijT7qa_sH-8=.8ea5526d-e736-4d00-a650-3b0e35d02216@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <dYhIBACoVnuBRvUAwD5BsWCac_r2PVGiijT7qa_sH-8=.8ea5526d-e736-4d00-a650-3b0e35d02216@github.com>
Message-ID: <c-E3B1aMNwGGuB66rmWyA3dq0XGnn7TEFy52zBFuEhg=.118870b9-7078-414a-94fb-6d77f2f710a2@github.com>

On Mon, 25 Oct 2021 18:24:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/krb5/KrbCredSubKey.java line 34:
>> 
>>> 32: 
>>> 33: import java.io.FileOutputStream;
>>> 34: import java.util.concurrent.Callable;
>> 
>> Should those tests run with both permutations of the system property?
>
> I did ran it but not sure if it's good  to add an extra `@run` to all tests. I'll select a few.

Hi Bernd, thanks a huge lot for all your comments. I'm really glad you care about the next steps of JEP 411 in such details. There are quite some other things we need to do in the next few releases.

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

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

From weijun at openjdk.java.net  Mon Oct 25 18:33:04 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 18:33:04 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
 <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>
Message-ID: <VPi2QN-z4C_B0itYRe-D3pBNPRkOZYpyOrY76BdH3qw=.ae0cf2d9-3604-4015-b168-3cf810d2c033@github.com>

On Mon, 25 Oct 2021 15:13:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1618:
>> 
>>> 1616:         }
>>> 1617:         SubjectAlternativeNameExtension subjectAltNameExt =
>>> 1618:             getSubjectAlternativeNameExtension();
>> 
>> Does it make sense to let the line above throwing an exception? I see the method is called in several places (`X509CertSelector`, `Builder`, etc). What is the correct behavior in those places?
>
> To clarify, do you mean this code in `getExtension(ObjectIdentifier)` that swallows the exception?:
> 
> 
>         } catch (IOException ioe) {
>             return null;
>         }

That's probably a little deeper and changing it will have a mass effect. What about at the `getIssuerAlternativeNameExtension` level?

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

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

From duke at openjdk.java.net  Mon Oct 25 19:58:11 2021
From: duke at openjdk.java.net (Bernd)
Date: Mon, 25 Oct 2021 19:58:11 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <4yomLmh_dnLfLEjGEKMd8dkdhmyYOCrAIrxrJk7LNCg=.4bb1d786-d986-445c-be56-c2455d5a46d0@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <4yomLmh_dnLfLEjGEKMd8dkdhmyYOCrAIrxrJk7LNCg=.4bb1d786-d986-445c-be56-c2455d5a46d0@github.com>
Message-ID: <pLNRmMB4k2SKw_Hd2BTZaumvHnxz45_qezUTplX9-6M=.85910591-2c7f-44c0-9811-53baca1313ec@github.com>

On Mon, 25 Oct 2021 17:58:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/security/auth/Subject.java line 325:
>> 
>>> 323: 
>>> 324:     // Store the current subject to a ThreadLocal when a system property is set.
>>> 325:     private static final boolean USE_TL = "true".equalsIgnoreCase(
>> 
>> Can you use GetBooleanAction.privilegedGetProperty instead?
>
> Sure, I can. I was testing the default value to "false" at some time and found `"true".equals` and `!"false".equals` symmetric and good-looking. :-)

It probably doesn?t matter to have the Logic centralized, just looked a bit hardcoded (who knows if yes/no/1/0 is wanted as well ,).

>> src/java.base/share/classes/javax/security/auth/Subject.java line 349:
>> 
>>> 347:      * the one of its parent thread, and will not change even if
>>> 348:      * its parent thread's current subject is changed to another value.
>>> 349:      *
>> 
>> Should it say something about installing or unsettling the subject in a nested execution (if it can be restricted)?
>
> I said "After {@code action} is finished, the current subject is reset to its previous value". Is that what you meant?

My question was more along the line of Post-Security-manager. Will you always be able to call Subject.doAs - especially with null? And if this can already be speced if it might be rejected or not? (the ?after finished? is well documented)

>> src/java.base/share/classes/javax/security/auth/Subject.java line 475:
>> 
>>> 473:      *       call {@link #callAs} to perform the same work, which is based on
>>> 474:      *       {@link #doAs(Subject, PrivilegedExceptionAction)}
>>> 475:      *       by default in this implementation.
>> 
>> Should it also mention that unless you define the TL system property it will still affect the new current() call? (Just to introduce the concept by repetition).
>
> I just don't want to touch existing spec. Even for `doAs`, I only said "callAs is based on doAs by default" and didn't went out explaining what is NOT by default. Is that OK?

Yes good reason not to change it.

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

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

From duke at openjdk.java.net  Mon Oct 25 20:07:08 2021
From: duke at openjdk.java.net (Bernd)
Date: Mon, 25 Oct 2021 20:07:08 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <NByKzEbyrhEimH7mxpBKJ8-SvfqXSMITJGQynroRrhQ=.d0a89b01-1fa4-4bbd-a17a-b037bcab95d6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <NByKzEbyrhEimH7mxpBKJ8-SvfqXSMITJGQynroRrhQ=.d0a89b01-1fa4-4bbd-a17a-b037bcab95d6@github.com>
Message-ID: <fWipdJl9w-AsiErjoiAFWQyBkBkUeVqiFKS58nlgHfA=.fe98e295-e694-47a7-af08-7bb6880dcad6@github.com>

On Mon, 25 Oct 2021 18:08:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 708:
>> 
>>> 706:                             @SuppressWarnings("removal")
>>> 707:                             final Subject subject =
>>> 708:                                 AccessController.doPrivilegedWithCombiner(
>> 
>> Is this actually needed and correct to wrap this into a priveledged action?
>
> Oh, it's needed. Otherwise the `AccessController.getContext()` call (which is inside `current()`) will also be called in a clean privileged context and there is no subject associated with it.
> 
> On the other hand, it still needs to in some sort of doPriv. I don't want to ignore `AuthPermission("getSubject")`.

Hm yes i see why ?withacombiner? would be needed, just not sure why doPriveledged() is needed (especially since current() does it as well). But I admit i don?t see through that part, so ignore me if I don?t make sense.

>> test/jdk/javax/security/auth/Subject/DoAs.java line 44:
>> 
>>> 42:             final int index = i;
>>> 43:             Subject.callAs(subject, () -> {
>>> 44:                 Subject s = Subject.current();
>> 
>> Should it Test old and new method to retrieve subject?
>
> I did it in `CurrentSubject.java` when test=both (checking `cas != accs` in `check()`). All changes to existing tests are just to avoid calling deprecated methods.

Yes, probably not worth it in all tests (but would be maybe a good one time exercise?)

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

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

From mullan at openjdk.java.net  Mon Oct 25 20:20:04 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 25 Oct 2021 20:20:04 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <VPi2QN-z4C_B0itYRe-D3pBNPRkOZYpyOrY76BdH3qw=.ae0cf2d9-3604-4015-b168-3cf810d2c033@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
 <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>
 <VPi2QN-z4C_B0itYRe-D3pBNPRkOZYpyOrY76BdH3qw=.ae0cf2d9-3604-4015-b168-3cf810d2c033@github.com>
Message-ID: <-a24YMG24rA6exgdmd9zSi7gNIjHbqNUk8bZqIwxXDA=.58bfc552-a975-478a-b108-7bfcd9cce702@github.com>

On Mon, 25 Oct 2021 18:29:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> To clarify, do you mean this code in `getExtension(ObjectIdentifier)` that swallows the exception?:
>> 
>> 
>>         } catch (IOException ioe) {
>>             return null;
>>         }
>
> That's probably a little deeper and changing it will have a mass effect. What about at the `getIssuerAlternativeNameExtension` level?

Unless I am misunderstanding your comment, I don't think this is an issue in practice. The code inside the `X509CertImpl.getExtension` method only throws an Exception if invalid OIDs or attribute names are passed to the internal `get` methods of `X509CertInfo` and `CertificateExtensions`, which isn't possible when you are passing in known values/attributes. I think this is why the code swallows the exceptions and returns null, but it would be nice to have a comment explaining that.

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

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

From mullan at openjdk.java.net  Mon Oct 25 20:49:06 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 25 Oct 2021 20:49:06 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore
In-Reply-To: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
Message-ID: <rulz2zvAMcX9vpPEUhclSEU-HZuKuFI7ZzHWVqKYCVY=.1b40b85c-03a0-4b67-901b-d59970351e5d@github.com>

On Thu, 14 Oct 2021 14:43:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
> 
> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.

test/jdk/sun/security/pkcs12/EmptyPassword.java line 27:

> 25:  * @test
> 26:  * @bug 8202299 8231107
> 27:  * @modules java.base/sun.security.tools.keytool

Can you add an @summary?

test/jdk/sun/security/pkcs12/EmptyPassword.java line 57:

> 55:                 });
> 56: 
> 57:         // 8202299: interop before new char[0] and new char[1]

Can you make this comment more descriptive? Not sure what "before" means. Is this just making sure you can store a keystore and key entry with "\0" as the password and load it back with ""? Should you also try to load it back with "\0" too?

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

PR: https://git.openjdk.java.net/jdk/pull/5950

From valeriep at openjdk.java.net  Mon Oct 25 23:11:16 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 25 Oct 2021 23:11:16 GMT
Subject: RFR: 8251134: Unwrapping a key with a Private Key generated by
 Microsoft CNG fails
In-Reply-To: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
References: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
Message-ID: <m5w1UWUGT5HKmAniH6lRFJ2MsXByusMmeQ5xUCnFxTY=.14d4c46f-1571-4c13-b3c0-4c469f930ccf@github.com>

On Wed, 20 Oct 2021 18:06:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Support Cipher operations on CNG keys.

Changes look good~

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6049

From weijun at openjdk.java.net  Mon Oct 25 23:44:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 23:44:13 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore
In-Reply-To: <rulz2zvAMcX9vpPEUhclSEU-HZuKuFI7ZzHWVqKYCVY=.1b40b85c-03a0-4b67-901b-d59970351e5d@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
 <rulz2zvAMcX9vpPEUhclSEU-HZuKuFI7ZzHWVqKYCVY=.1b40b85c-03a0-4b67-901b-d59970351e5d@github.com>
Message-ID: <AbvAUnZFjyWnxoabtuaF7soZISC__M_2iEePWVLDss0=.52cdefd4-d672-4341-933b-5bd074bd128e@github.com>

On Mon, 25 Oct 2021 17:02:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
>> 
>> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.
>
> test/jdk/sun/security/pkcs12/EmptyPassword.java line 57:
> 
>> 55:                 });
>> 56: 
>> 57:         // 8202299: interop before new char[0] and new char[1]
> 
> Can you make this comment more descriptive? Not sure what "before" means. Is this just making sure you can store a keystore and key entry with "\0" as the password and load it back with ""? Should you also try to load it back with "\0" too?

Typo: s/before/between/.

I'll add one with "\0". That should always work since it's the same password used in load() and store().

-------------

PR: https://git.openjdk.java.net/jdk/pull/5950

From weijun at openjdk.java.net  Mon Oct 25 23:47:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 23:47:12 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore
In-Reply-To: <rulz2zvAMcX9vpPEUhclSEU-HZuKuFI7ZzHWVqKYCVY=.1b40b85c-03a0-4b67-901b-d59970351e5d@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
 <rulz2zvAMcX9vpPEUhclSEU-HZuKuFI7ZzHWVqKYCVY=.1b40b85c-03a0-4b67-901b-d59970351e5d@github.com>
Message-ID: <aRwYzB7_R0m1dGGt4bJ-9E3U3lP7AoElf3Wapd04rcU=.4b05ed8b-98c3-405e-b904-d46d76003330@github.com>

On Mon, 25 Oct 2021 17:05:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
>> 
>> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.
>
> test/jdk/sun/security/pkcs12/EmptyPassword.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8202299 8231107
>> 27:  * @modules java.base/sun.security.tools.keytool
> 
> Can you add an @summary?

I'll update the existing summary to `@summary Testing empty (null, "", "\0") password behaviors`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5950

From weijun at openjdk.java.net  Mon Oct 25 23:51:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 25 Oct 2021 23:51:13 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <-a24YMG24rA6exgdmd9zSi7gNIjHbqNUk8bZqIwxXDA=.58bfc552-a975-478a-b108-7bfcd9cce702@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
 <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>
 <VPi2QN-z4C_B0itYRe-D3pBNPRkOZYpyOrY76BdH3qw=.ae0cf2d9-3604-4015-b168-3cf810d2c033@github.com>
 <-a24YMG24rA6exgdmd9zSi7gNIjHbqNUk8bZqIwxXDA=.58bfc552-a975-478a-b108-7bfcd9cce702@github.com>
Message-ID: <8q0feoy-rGHzNQFLGkjLWrEFZ4ORSUyWWWXZnCp3mgs=.33f5f72e-0521-474d-979c-5bb3aa5e7b05@github.com>

On Mon, 25 Oct 2021 20:17:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> That's probably a little deeper and changing it will have a mass effect. What about at the `getIssuerAlternativeNameExtension` level?
>
> Unless I am misunderstanding your comment, I don't think this is an issue in practice. The code inside the `X509CertImpl.getExtension` method only throws an Exception if invalid OIDs or attribute names are passed to the internal `get` methods of `X509CertInfo` and `CertificateExtensions`, which isn't possible when you are passing in known values/attributes. I think this is why the code swallows the exceptions and returns null, but it would be nice to have a comment explaining that.

I was asking if `getIssuerAlternativeNameExtension` can throw the exception is IAE exists but not parseable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6106

From valeriep at openjdk.java.net  Tue Oct 26 01:19:12 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 26 Oct 2021 01:19:12 GMT
Subject: RFR: 8185844: MSCAPI doesn't list aliases correctly
In-Reply-To: <ts57VYM7pGl4dRk6wFNNt9XQGsws7qGLIldkNu5yu9k=.9a4805ca-c3ba-420d-945a-47ac104e7f7c@github.com>
References: <ts57VYM7pGl4dRk6wFNNt9XQGsws7qGLIldkNu5yu9k=.9a4805ca-c3ba-420d-945a-47ac104e7f7c@github.com>
Message-ID: <x4Bsqal44Jd8PBqHcdENB9FWWTenLvP46n8nhsH-EAw=.6a4bfa79-350c-4f1a-9bb9-eb7ee86220dd@github.com>

On Wed, 20 Oct 2021 17:54:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> If a entry is overwritten by another one using the same alias, make sure the old one is removed.

Changes look good. Thanks!

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6047

From weijun at openjdk.java.net  Tue Oct 26 02:42:23 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 02:42:23 GMT
Subject: Integrated: 8185844: MSCAPI doesn't list aliases correctly
In-Reply-To: <ts57VYM7pGl4dRk6wFNNt9XQGsws7qGLIldkNu5yu9k=.9a4805ca-c3ba-420d-945a-47ac104e7f7c@github.com>
References: <ts57VYM7pGl4dRk6wFNNt9XQGsws7qGLIldkNu5yu9k=.9a4805ca-c3ba-420d-945a-47ac104e7f7c@github.com>
Message-ID: <sO7_VjAqCW8ZXJhNBZ830xvPZpAFm8_vLhX7R_MlU4A=.53b10514-65ed-4cc1-9da7-e320144b64dd@github.com>

On Wed, 20 Oct 2021 17:54:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> If a entry is overwritten by another one using the same alias, make sure the old one is removed.

This pull request has now been integrated.

Changeset: 43619458
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/43619458d183bbbaec745887314ddcf7a8aa4136
Stats:     174 lines in 2 files changed: 123 ins; 34 del; 17 mod

8185844: MSCAPI doesn't list aliases correctly

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/6047

From weijun at openjdk.java.net  Tue Oct 26 02:48:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 02:48:57 GMT
Subject: RFR: 8251134: Unwrapping a key with a Private Key generated by
 Microsoft CNG fails [v2]
In-Reply-To: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
References: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
Message-ID: <jZW14-Lheq31gXCYF4QJ2nZo2SVbcv-zSNPRqlWQvpg=.09ec3148-c1d2-4b3b-8b3a-d7cab6016ccf@github.com>

> Support Cipher operations on CNG keys.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6049/files
  - new: https://git.openjdk.java.net/jdk/pull/6049/files/2612797b..2612797b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6049&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6049&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6049/head:pull/6049

PR: https://git.openjdk.java.net/jdk/pull/6049

From duke at openjdk.java.net  Tue Oct 26 02:48:58 2021
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 26 Oct 2021 02:48:58 GMT
Subject: RFR: 8251134: Unwrapping a key with a Private Key generated by
 Microsoft CNG fails
In-Reply-To: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
References: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
Message-ID: <WGHGDH38gftdGP8pMoWPKKedNVet1qji5wbtXXLPbzA=.b9d3486f-0fda-4ec9-a876-b4fc586166e0@github.com>

On Wed, 20 Oct 2021 18:06:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Support Cipher operations on CNG keys.

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8185844
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

-------------

PR: https://git.openjdk.java.net/jdk/pull/6049

From weijun at openjdk.java.net  Tue Oct 26 02:49:00 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 02:49:00 GMT
Subject: Integrated: 8251134: Unwrapping a key with a Private Key generated by
 Microsoft CNG fails
In-Reply-To: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
References: <QPBzcYAhM2BG6KqCJfb_tQD6HOqBz_xODZMB-mf2-hA=.e21aad2f-652e-4744-b4eb-115bab42c630@github.com>
Message-ID: <YKallmvCwocacX5HvJ-mSnVlZ88BwA7iGdOt40F8F18=.9db4058b-9ed6-4189-8a65-5340f37ec565@github.com>

On Wed, 20 Oct 2021 18:06:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Support Cipher operations on CNG keys.

This pull request has now been integrated.

Changeset: 10e1610f
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/10e1610f7b99f42f834478528df7ecfb4320aec1
Stats:     210 lines in 4 files changed: 201 ins; 0 del; 9 mod

8251134: Unwrapping a key with a Private Key generated by Microsoft CNG fails

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/6049

From duke at openjdk.java.net  Tue Oct 26 12:20:27 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 26 Oct 2021 12:20:27 GMT
Subject: RFR: 8275918: Remove unused local variables in java.base security code
Message-ID: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>

Cleanup unused local variables. Looks like they are leftovers after refactoring.

-------------

Commit messages:
 - [PATCH] Remove unused local variables in java.base security code

Changes: https://git.openjdk.java.net/jdk/pull/6092/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6092&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275918
  Stats: 31 lines in 13 files changed: 0 ins; 16 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6092.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6092/head:pull/6092

PR: https://git.openjdk.java.net/jdk/pull/6092

From aefimov at openjdk.java.net  Tue Oct 26 12:52:58 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:52:58 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov 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 14 additional commits since the last revision:

 - Changes to address review comments
 - Update tests to address SM deprecation
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - More javadoc updates to API classes
 - Review updates + move resolver docs to the provider class (CSR update to follow)
 - Change InetAddressResolver method names
 - Remove no longer used import from IPSupport
 - Rename IPSupport.hasAddress and update it to use SocketChannel.open
 - Address review comments: javadoc + code cleanup
 - Address resolver bootstraping issue
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a8495826...1378686b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/fa655be2..1378686b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=06-07

  Stats: 32082 lines in 838 files changed: 22928 ins; 6060 del; 3094 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 12:53:06 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:53:06 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
 <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>
Message-ID: <bNzeqx8yPjqgV-AjHArisAGsQvRloLHSR-InzxCZqn8=.c06b5c23-6ae7-4acd-8813-1bc68325f5d5@github.com>

On Sat, 23 Oct 2021 06:19:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More javadoc updates to API classes
>
> src/java.base/share/classes/java/net/InetAddress.java line 169:
> 
>> 167:  * Access Protocol (LDAP).
>> 168:  * The particular naming services that the built-in resolver uses by default
>> 169:  * depend on the configuration of the local machine.
> 
> depend -> depends

Thanks, changed in 1378686becfcbf18793556de8381b5ebcd79698d

> src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 38:
> 
>> 36:  * deployed as a <a href="InetAddressResolverProvider.html#system-wide-resolver">
>> 37:  * system-wide resolver</a>. {@link InetAddress} delegates all lookup requests to
>> 38:  * the deployed <i>system-wide resolver</i> instance.
> 
> I think the class description would be a bit clearer if we drop sentence 2 because it overlaps with paragraph 2. I think we can adjust sentence 3 to "InetAddress delegates all lookup operations to the system-wide resolver" and it will all flow nicely.

Thanks, changed as suggested in 1378686becfcbf18793556de8381b5ebcd79698d

> src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 88:
> 
>> 86:      *                                  to a valid IP address length
>> 87:      */
>> 88:     String lookupByAddress(byte[] addr) throws UnknownHostException;
> 
> I assume this throws NPE if addr is null.

1378686becfcbf18793556de8381b5ebcd79698d: added @ throws NPE javadoc, also added additional checks for `null` parameter values into the built-in and hosts file resolver implementations.

> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45:
> 
>> 43:  * system-wide resolver instance, which is used by
>> 44:  * <a href="{@docRoot}/java.base/java/net/InetAddress.html#host-name-resolution">
>> 45:  * InetAddress</a>.
> 
> I think we should prune some some of the text from the class description to avoid repetition.  Here's a suggestion:
> 
> 1. Add the following immediately after the sentence "A given innovation ..."
> "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 
> 
> 2. Replace the text in L47-65 with:
> "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows:
> 
> 3. Replace the remaining three usages of "install" with "set".

Thanks, changed as suggested: 1378686becfcbf18793556de8381b5ebcd79698d

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 12:53:09 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:53:09 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XmR0-Viqe4WDCUYoa2pI-LTLkXlrHXUbHYIBWXXRm8o=.b000002f-94b0-466a-b605-8d6952df7f25@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>
 <XmR0-Viqe4WDCUYoa2pI-LTLkXlrHXUbHYIBWXXRm8o=.b000002f-94b0-466a-b605-8d6952df7f25@github.com>
Message-ID: <zZkne_nXwraiVo-ilhze4X1t8LJD8jRDsQFOvbu-blA=.fd1c3686-0d41-422e-8d19-9b065465cc13@github.com>

On Sat, 23 Oct 2021 06:33:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52:
>> 
>>> 50:     /**
>>> 51:      * Initialise and return the {@link InetAddressResolver} provided by
>>> 52:      * this provider. This method is called by {@link InetAddress} when
>> 
>> "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that.
>
> Initialise -> Initialize to be consistent with other usages that use US spelling.

Thanks, changed in 1378686becfcbf18793556de8381b5ebcd79698d

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 12:55:11 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:55:11 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <bNzeqx8yPjqgV-AjHArisAGsQvRloLHSR-InzxCZqn8=.c06b5c23-6ae7-4acd-8813-1bc68325f5d5@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
 <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>
 <bNzeqx8yPjqgV-AjHArisAGsQvRloLHSR-InzxCZqn8=.c06b5c23-6ae7-4acd-8813-1bc68325f5d5@github.com>
Message-ID: <ABI76QQbjlVkXxRAGpRdIeTHjbdJQshI7AqHC3Tc3KQ=.4219703b-cd16-4bb0-a1df-744ab421a560@github.com>

On Tue, 26 Oct 2021 12:49:30 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45:
>> 
>>> 43:  * system-wide resolver instance, which is used by
>>> 44:  * <a href="{@docRoot}/java.base/java/net/InetAddress.html#host-name-resolution">
>>> 45:  * InetAddress</a>.
>> 
>> I think we should prune some some of the text from the class description to avoid repetition.  Here's a suggestion:
>> 
>> 1. Add the following immediately after the sentence "A given innovation ..."
>> "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 
>> 
>> 2. Replace the text in L47-65 with:
>> "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows:
>> 
>> 3. Replace the remaining three usages of "install" with "set".
>
> Thanks, changed as suggested: 1378686becfcbf18793556de8381b5ebcd79698d

Pruned `InetAddressResolverProvider` class-level doc as suggested: 1378686becfcbf18793556de8381b5ebcd79698d

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Tue Oct 26 13:11:21 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 26 Oct 2021 13:11:21 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
Message-ID: <1ocUc2kRrpqHA-uWpjWrTtByfCvRoXWV-tbDJCEjmbs=.1149b134-96fc-45c3-81e3-1cee89b8d3aa@github.com>

On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov 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 14 additional commits since the last revision:
> 
>  - Changes to address review comments
>  - Update tests to address SM deprecation
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - More javadoc updates to API classes
>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>  - Change InetAddressResolver method names
>  - Remove no longer used import from IPSupport
>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>  - Address review comments: javadoc + code cleanup
>  - Address resolver bootstraping issue
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c2db4e04...1378686b

Thanks for the updates to the API docs, you've addressed all my comments.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Tue Oct 26 15:10:24 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Oct 2021 15:10:24 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
Message-ID: <tb8g4zT745Ybk1uHQnmAIwoKPK7cPh_nJU3WljpNYT0=.243257e0-fdd0-4bb1-a646-59608fb56319@github.com>

On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov 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 14 additional commits since the last revision:
> 
>  - Changes to address review comments
>  - Update tests to address SM deprecation
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - More javadoc updates to API classes
>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>  - Change InetAddressResolver method names
>  - Remove no longer used import from IPSupport
>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>  - Address review comments: javadoc + code cleanup
>  - Address resolver bootstraping issue
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/10094444...1378686b

Marked as reviewed by dfuchs (Reviewer).

src/java.base/share/classes/java/net/InetAddress.java line 1151:

> 1149: 
> 1150:             Objects.requireNonNull(host);
> 1151:             Objects.requireNonNull(lookupPolicy);

for consistency we could add `@throws NullPointerException` to the API doc of that method - since it seems to have everything else...

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From weijun at openjdk.java.net  Tue Oct 26 15:22:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 15:22:15 GMT
Subject: RFR: 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: <V5ThbufI_q2hmUVqL4ew6DSQwd7rUJAn6Xli4Kg4UrU=.5d4bbf3d-5f52-4dcf-aa45-454dc44d8e2d@github.com>

On Sat, 23 Oct 2021 14:04:07 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cleanup unused local variables. Looks like they are leftovers after refactoring.

src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 211:

> 209:         AlgorithmParameterSpec keyParams = rsaKey.getParams();
> 210:         // validate key parameters
> 211:         if (!isCompatible(keyParams, this.sigParams)) {

Why not remove the assignment on line 209? This is more consistent with your fix this time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6092

From duke at openjdk.java.net  Tue Oct 26 15:28:22 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 26 Oct 2021 15:28:22 GMT
Subject: Integrated: 8273299: Unnecessary Vector usage in java.security.jgss
In-Reply-To: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>
References: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>
Message-ID: <-vINh74tQBSEMPaovBMLeuQfps7z_nrq_6RvuektVxk=.9c747a93-b802-4bf0-a3d5-07c07683793e@github.com>

On Thu, 26 Aug 2021 08:09:16 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.

This pull request has now been integrated.

Changeset: c9dec2f9
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c9dec2f9849f98048f32ccef4e5573ce21204fbb
Stats:     106 lines in 12 files changed: 2 ins; 15 del; 89 mod

8273299: Unnecessary Vector usage in java.security.jgss

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/5264

From mullan at openjdk.java.net  Tue Oct 26 15:32:13 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 26 Oct 2021 15:32:13 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <8q0feoy-rGHzNQFLGkjLWrEFZ4ORSUyWWWXZnCp3mgs=.33f5f72e-0521-474d-979c-5bb3aa5e7b05@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
 <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>
 <VPi2QN-z4C_B0itYRe-D3pBNPRkOZYpyOrY76BdH3qw=.ae0cf2d9-3604-4015-b168-3cf810d2c033@github.com>
 <-a24YMG24rA6exgdmd9zSi7gNIjHbqNUk8bZqIwxXDA=.58bfc552-a975-478a-b108-7bfcd9cce702@github.com>
 <8q0feoy-rGHzNQFLGkjLWrEFZ4ORSUyWWWXZnCp3mgs=.33f5f72e-0521-474d-979c-5bb3aa5e7b05@github.com>
Message-ID: <_EDWrIj80ppmt70WW5a-TAMoO4xuMkRP71Hhg0oYWqI=.c570569b-1e95-4ce6-885b-601339f8506e@github.com>

On Mon, 25 Oct 2021 23:48:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Unless I am misunderstanding your comment, I don't think this is an issue in practice. The code inside the `X509CertImpl.getExtension` method only throws an Exception if invalid OIDs or attribute names are passed to the internal `get` methods of `X509CertInfo` and `CertificateExtensions`, which isn't possible when you are passing in known values/attributes. I think this is why the code swallows the exceptions and returns null, but it would be nice to have a comment explaining that.
>
> I was asking if `getIssuerAlternativeNameExtension` can throw the exception is IAE exists but not parseable.

Ok, I understand your comment now. I'm hesitant to change those methods to throw an exception because to be consistent all the `get*Extension()` methods should then throw an Exception. That might be the right thing to do, but it is a bigger change and more risky. The code that calls these internal methods is used for building certification paths, and if null is returned, it is as if the certificate did not contain the extension. That might be a more reasonable behavior than throwing an Exception, since it allows the code to find other potential certificates or certification paths. Adding certpath debug can always be used to find out more about why certain certificates were not selected.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6106

From weijun at openjdk.java.net  Tue Oct 26 15:39:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 15:39:11 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
Message-ID: <poRsRgMLQ4-Xcyvi6Lq6k_xPYYO6sOK6nQgaRZ7JFjY=.4213040b-acbc-4098-8a1c-6c5602caa814@github.com>

On Mon, 25 Oct 2021 14:34:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.
>
> src/java.base/share/classes/java/security/KeyStore.java line 1035:
> 
>> 1033:      *      not extractable (For example, if the attributes is encrypted
>> 1034:      *      in a private key entry or a secret key entry).
>> 1035:      *
> 
> I think this would read better if you broke it up into multiple sentences, ex: "an unmodifiable {@code Set} of attributes. The set may be empty if the given alias does not exist, or the alias does exist but there are no attributes associated with it or the attributes are not extractable (for example, the attributes may not be extractable if they are encrypted in a private key or secret key entry)."
> 
> You may also want to add a sentence to try the `KeyStore$Entry::getAttributes` method if there are no attributes.
> 
> Did you consider throwing a KeyStoreException if they are not extractable? It would be useful to distinguish that case from an alias that has no attributes.

This is complicated. Theoretically a KeyStore implementation can store some attributes in clear text and some encrypted, and it's probably not possible to know if there exist any encrypted ones before actually decrypting the entry. Maybe I should say "For a PrivateKeyEntry or SecretKeyEntry, some attributes might only be available after the entry is extracted by the getEntry() method. Try calling the entry's getAttributes() method to see if there are any".

> src/java.base/share/classes/java/security/KeyStoreSpi.java line 450:
> 
>> 448:     /**
>> 449:      * Retrieves the attributes associated with the given alias.
>> 450:      *
> 
> You should also document the default implementation.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Tue Oct 26 15:45:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 15:45:13 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
Message-ID: <GNmiQnNhYHYKuUBiQMK-YgQOGBrRItWh2fDJikIZmxk=.27fc8046-0a76-4bfe-aacb-6d6699071705@github.com>

On Mon, 25 Oct 2021 14:36:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.
>
> src/java.base/share/classes/java/security/KeyStore.java line 1038:
> 
>> 1036:      * @throws    KeyStoreException if the keystore has not been initialized
>> 1037:      * (loaded).
>> 1038:      *
> 
> throw NPE if alias is null?

OK.

> src/java.base/share/classes/java/security/KeyStoreSpi.java line 457:
> 
>> 455:      */
>> 456:     public Set<Entry.Attribute> engineGetAttributes(String alias) {
>> 457:         return Collections.emptySet();
> 
> Would `Set.of()` be better here?

Both returns an internal constant object and I think they are similar. I was copying the default implementation of `Entry::getAttributes`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Tue Oct 26 15:50:20 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 15:50:20 GMT
Subject: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames
 does not throw CertificateParsingException if extension is unparseable
In-Reply-To: <_EDWrIj80ppmt70WW5a-TAMoO4xuMkRP71Hhg0oYWqI=.c570569b-1e95-4ce6-885b-601339f8506e@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <pojS8Huv0mzJyU50funa_99QhJdsLeE5_xDZW3Iu6FQ=.693f5cec-a0c3-4a2d-8a4c-20f48e90d604@github.com>
 <Iy3vlKR8EeKlMuCMOgwQ4HetXGMs9m0dY7J6uPJHjxI=.4f2c58b4-6ac9-4cad-9906-1eddb3d18a8d@github.com>
 <VPi2QN-z4C_B0itYRe-D3pBNPRkOZYpyOrY76BdH3qw=.ae0cf2d9-3604-4015-b168-3cf810d2c033@github.com>
 <-a24YMG24rA6exgdmd9zSi7gNIjHbqNUk8bZqIwxXDA=.58bfc552-a975-478a-b108-7bfcd9cce702@github.com>
 <8q0feoy-rGHzNQFLGkjLWrEFZ4ORSUyWWWXZnCp3mgs=.33f5f72e-0521-474d-979c-5bb3aa5e7b05@github.com>
 <_EDWrIj80ppmt70WW5a-TAMoO4xuMkRP71Hhg0oYWqI=.c570569b-1e95-4ce6-885b-601339f8506e@github.com>
Message-ID: <smLaqONqgAPPdK8bNEb-0IbPacfmfsCmk-A-ytEZUP0=.ec60e53e-d6f3-4c1d-8b5b-c178889eb8ec@github.com>

On Tue, 26 Oct 2021 15:28:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I was asking if `getIssuerAlternativeNameExtension` can throw the exception if IAE exists but not parseable.
>
> Ok, I understand your comment now. I'm hesitant to change those methods to throw an exception because to be consistent all the `get*Extension()` methods should then throw an Exception. That might be the right thing to do, but it is a bigger change and more risky. The code that calls these internal methods is used for building certification paths, and if null is returned, it is as if the certificate did not contain the extension. That might be a more reasonable behavior than throwing an Exception, since it allows the code to find other potential certificates or certification paths. Adding certpath debug can always be used to find out more about why certain certificates were not selected.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6106

From aefimov at openjdk.java.net  Tue Oct 26 16:24:48 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 16:24:48 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Add @ throws NPE to hosts file resolver javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/1378686b..2ca78ba9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=07-08

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 16:24:55 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 16:24:55 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <tb8g4zT745Ybk1uHQnmAIwoKPK7cPh_nJU3WljpNYT0=.243257e0-fdd0-4bb1-a646-59608fb56319@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
 <tb8g4zT745Ybk1uHQnmAIwoKPK7cPh_nJU3WljpNYT0=.243257e0-fdd0-4bb1-a646-59608fb56319@github.com>
Message-ID: <beYMyXv9niQPO5dbrBpGnDzjEHhawwEHFew5ZqKiQX0=.e532cee4-162e-44c1-ba36-869c99d1c73b@github.com>

On Tue, 26 Oct 2021 15:04:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov 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 14 additional commits since the last revision:
>> 
>>  - Changes to address review comments
>>  - Update tests to address SM deprecation
>>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>>  - More javadoc updates to API classes
>>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>>  - Change InetAddressResolver method names
>>  - Remove no longer used import from IPSupport
>>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>>  - Address review comments: javadoc + code cleanup
>>  - Address resolver bootstraping issue
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/1bbecc93...1378686b
>
> src/java.base/share/classes/java/net/InetAddress.java line 1151:
> 
>> 1149: 
>> 1150:             Objects.requireNonNull(host);
>> 1151:             Objects.requireNonNull(lookupPolicy);
> 
> for consistency we could add `@throws NullPointerException` to the API doc of that method - since it seems to have everything else...

Added `@throws NullPointerException` to the hosts file resolver API docs: 2ca78ba98dc81cd6cc44b53dc7d56a6ae42c2736

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Tue Oct 26 16:30:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Oct 2021 16:30:16 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
Message-ID: <0mvmoo3ws7YZ_Wf_9bZmvjDHZZ5PQFaOCBhpn4x-q30=.08ef6e7a-f8b1-4b3f-9a1f-2d91e44d2598@github.com>

On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ throws NPE to hosts file resolver javadoc

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From mullan at openjdk.java.net  Tue Oct 26 16:43:09 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 26 Oct 2021 16:43:09 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore
In-Reply-To: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
Message-ID: <fjUS83GfYl37UrszWCjJjG7WSpOeVFymuHAg0QwURds=.873b4cd2-a728-4336-bada-7111f963e98d@github.com>

On Thu, 14 Oct 2021 14:43:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
> 
> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5950

From mullan at openjdk.java.net  Tue Oct 26 16:43:10 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 26 Oct 2021 16:43:10 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore
In-Reply-To: <aRwYzB7_R0m1dGGt4bJ-9E3U3lP7AoElf3Wapd04rcU=.4b05ed8b-98c3-405e-b904-d46d76003330@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
 <rulz2zvAMcX9vpPEUhclSEU-HZuKuFI7ZzHWVqKYCVY=.1b40b85c-03a0-4b67-901b-d59970351e5d@github.com>
 <aRwYzB7_R0m1dGGt4bJ-9E3U3lP7AoElf3Wapd04rcU=.4b05ed8b-98c3-405e-b904-d46d76003330@github.com>
Message-ID: <vPoAwLfh0iOv8pVKXCrB0vmdlIkcmi37i-plao3nPS4=.6feb1e88-5576-4f29-b6c8-a6a4530f4397@github.com>

On Mon, 25 Oct 2021 23:44:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs12/EmptyPassword.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8202299 8231107
>>> 27:  * @modules java.base/sun.security.tools.keytool
>> 
>> Can you add an @summary?
>
> I'll update the existing summary to `@summary Testing empty (null, "", "\0") password behaviors`.

Ok.

>> test/jdk/sun/security/pkcs12/EmptyPassword.java line 57:
>> 
>>> 55:                 });
>>> 56: 
>>> 57:         // 8202299: interop before new char[0] and new char[1]
>> 
>> Can you make this comment more descriptive? Not sure what "before" means. Is this just making sure you can store a keystore and key entry with "\0" as the password and load it back with ""? Should you also try to load it back with "\0" too?
>
> Typo: s/before/between/.
> 
> I'll add one with "\0". That should always work since it's the same password used in load() and store().

Ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5950

From duke at openjdk.java.net  Tue Oct 26 16:45:21 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 26 Oct 2021 16:45:21 GMT
Subject: Integrated: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
Message-ID: <44HAVmWJFcyu-AdhRRsJeF7mOszcfse1fl27XS0hiFM=.ba08b56a-8d4c-41f3-9370-2821310ca088@github.com>

On Sat, 2 Oct 2021 20:05:37 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: 19f76c21
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19f76c215dbe9528dde10acd744be54618ea5e4c
Stats:     34 lines in 13 files changed: 0 ins; 3 del; 31 mod

8275079: Remove unnecessary conversion to String in java.net.http

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/5795

From weijun at openjdk.java.net  Tue Oct 26 17:53:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 17:53:32 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore [v2]
In-Reply-To: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
Message-ID: <8L1Dv8kXUsQEOurFjZsyRMM98mnGg3NEsNU_b6Uazec=.c9f1db8c-0f37-4e87-a9b8-0efe9d026c97@github.com>

> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
> 
> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.

Weijun Wang 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/5950/files
  - new: https://git.openjdk.java.net/jdk/pull/5950/files/7d789775..aae1b0c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5950.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5950/head:pull/5950

PR: https://git.openjdk.java.net/jdk/pull/5950

From mullan at openjdk.java.net  Tue Oct 26 19:18:46 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 26 Oct 2021 19:18:46 GMT
Subject: RFR: X509Certificate.get{Subject,Issuer}AlternativeNames and
 getExtendedKeyUsage do not throw CertificateParsingException if extension is
 unparseable [v2]
In-Reply-To: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
Message-ID: <vHhfP55rkyfJfkDyyB6brML0BWy_WzRSKIfRKkWZEZk=.f14fd6f5-8219-4d9b-95c8-aff01779d8e0@github.com>

> The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.
> 
> This fix changes the behavior to comply with the specification.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275822

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  - Modified getExtendedKeyUsage to also throw exception if extension is unparseable.
  - Renamed and enhanced test to check cert with badly encoded extensions.
  - Added comments to test describing which fields are badly encoded.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6106/files
  - new: https://git.openjdk.java.net/jdk/pull/6106/files/e380c45a..10172038

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6106&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6106&range=00-01

  Stats: 210 lines in 3 files changed: 107 ins; 94 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6106/head:pull/6106

PR: https://git.openjdk.java.net/jdk/pull/6106

From mullan at openjdk.java.net  Tue Oct 26 19:35:42 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 26 Oct 2021 19:35:42 GMT
Subject: RFR: X509Certificate.get{Subject,Issuer}AlternativeNames and
 getExtendedKeyUsage do not throw CertificateParsingException if extension is
 unparseable [v3]
In-Reply-To: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
Message-ID: <z4H6LU9UOP5VSzx2HZ_K9Pn4Sp3aODZn_sr_GjEgU-c=.024eade0-033e-48ba-8ef4-375fc130adb1@github.com>

> The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.
> 
> This fix changes the behavior to comply with the specification.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275822

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Fix NPE.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6106/files
  - new: https://git.openjdk.java.net/jdk/pull/6106/files/10172038..371a384d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6106&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6106&range=01-02

  Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6106/head:pull/6106

PR: https://git.openjdk.java.net/jdk/pull/6106

From weijun at openjdk.java.net  Tue Oct 26 19:57:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 19:57:11 GMT
Subject: RFR: X509Certificate.get{Subject,Issuer}AlternativeNames and
 getExtendedKeyUsage do not throw CertificateParsingException if extension is
 unparseable [v3]
In-Reply-To: <z4H6LU9UOP5VSzx2HZ_K9Pn4Sp3aODZn_sr_GjEgU-c=.024eade0-033e-48ba-8ef4-375fc130adb1@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
 <z4H6LU9UOP5VSzx2HZ_K9Pn4Sp3aODZn_sr_GjEgU-c=.024eade0-033e-48ba-8ef4-375fc130adb1@github.com>
Message-ID: <23aqcypPD1455XO_dQVZt648fqlK2r1ELk0kR5IslRk=.2861fe76-4351-4516-a15a-ba35773ccd2d@github.com>

On Tue, 26 Oct 2021 19:35:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.
>> 
>> This fix changes the behavior to comply with the specification.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8275822
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix NPE.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6106

From hchao at openjdk.java.net  Tue Oct 26 22:43:36 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 26 Oct 2021 22:43:36 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output
Message-ID: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>

This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

-------------

Commit messages:
 - 8257722: Improve "keytool -printcert -jarfile" output

Changes: https://git.openjdk.java.net/jdk/pull/6126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257722
  Stats: 81 lines in 3 files changed: 75 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6126/head:pull/6126

PR: https://git.openjdk.java.net/jdk/pull/6126

From weijun at openjdk.java.net  Tue Oct 26 23:30:10 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Oct 2021 23:30:10 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output
In-Reply-To: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
Message-ID: <u7mYp2gcXwo9uVitVe4jHA9wfIgROco8q-NEF55LJcE=.5f748bcf-46d2-44ab-98ba-a306c13b51a5@github.com>

On Tue, 26 Oct 2021 22:37:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2878:

> 2876:                             out.println();
> 2877:                             out.println();
> 2878:                             out.println(rb.getString("Signature."));

Please remove a newline as well. There needn't be 3 `println()` calls.

src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 469:

> 467:         {"one.in.many", "%1$s #%2$d of %3$d"},
> 468:         {"one.in.many1", "%1$s of signer #%2$d"},
> 469:         {"one.in.many2", "%1$s #%2$d of %3$d of signer #%4$d"},

`certificate #1 of 2 of signer #1` is a little too complicated. The second number is not really necessary. I think `certificate #1 of signer #1` is enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From duke at openjdk.java.net  Wed Oct 27 12:56:41 2021
From: duke at openjdk.java.net (Larry-N)
Date: Wed, 27 Oct 2021 12:56:41 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v2]
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <742YBdq43C8WhbvB3wMLO-baw6u469KM2fnGEI597wY=.131523b0-e39d-4725-bb79-77d3ae9fb785@github.com>

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

Larry-N has updated the pull request incrementally with one additional commit since the last revision:

  1. Address JCK failure 2.Address review notes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5748/files
  - new: https://git.openjdk.java.net/jdk/pull/5748/files/026a41c4..0b181a3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=00-01

  Stats: 47 lines in 3 files changed: 21 ins; 17 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

PR: https://git.openjdk.java.net/jdk/pull/5748

From duke at openjdk.java.net  Wed Oct 27 13:06:54 2021
From: duke at openjdk.java.net (Larry-N)
Date: Wed, 27 Oct 2021 13:06:54 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v3]
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <3tZoXWAI_1yKbtZ3XL19PWb7ohSXy9xpUvJc3zg6KdY=.7de919ad-1b52-4b85-a138-2821b47ab702@github.com>

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

Larry-N has updated the pull request incrementally with one additional commit since the last revision:

  Corrected trailing whitespaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5748/files
  - new: https://git.openjdk.java.net/jdk/pull/5748/files/0b181a3b..fbe99ed7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

PR: https://git.openjdk.java.net/jdk/pull/5748

From duke at openjdk.java.net  Wed Oct 27 13:06:57 2021
From: duke at openjdk.java.net (Larry-N)
Date: Wed, 27 Oct 2021 13:06:57 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v2]
In-Reply-To: <742YBdq43C8WhbvB3wMLO-baw6u469KM2fnGEI597wY=.131523b0-e39d-4725-bb79-77d3ae9fb785@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <742YBdq43C8WhbvB3wMLO-baw6u469KM2fnGEI597wY=.131523b0-e39d-4725-bb79-77d3ae9fb785@github.com>
Message-ID: <cJS9WVJtyKygu-srQvXsuOTG0b_qBy0OLnZoLOxe-yk=.5150f5c5-9048-463e-a2df-89cd6cdf4a6e@github.com>

On Wed, 27 Oct 2021 12:56:41 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. Address JCK failure 2.Address review notes

@wangweij With the new commit, I've moved filling ServiceProviders cache filling to login() method. And addressed your notice about correction for spi/Loader.java test. Could you please take a look when you have a chance? Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From mullan at openjdk.java.net  Wed Oct 27 13:48:27 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 27 Oct 2021 13:48:27 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
Message-ID: <Fs5WMBPBUFJhbuuppXDi8wSWuTdXlK4WZ2wtfNy7Nb4=.9716489a-c572-4d9f-85fe-ada2debd024a@github.com>

On Sat, 23 Oct 2021 00:40:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renames

src/java.base/share/classes/javax/security/auth/Subject.java line 296:

> 294:      *       which is equivalent to
> 295:      *       {@code Subject.getSubject(AccessController.getContext())}
> 296:      *       by default in this implementation.

I don't think you need the words "by default".

src/java.base/share/classes/javax/security/auth/Subject.java line 324:

> 322:     }
> 323: 
> 324:     // Store the current subject to a ThreadLocal when a system property is set.

nit: "... in a ThreadLocal ..."

src/java.base/share/classes/javax/security/auth/Subject.java line 357:

> 355:      * is set to {@code true}, it will be retrieved from an inheritable
> 356:      * {@code ThreadLocal} object. This behavior is subject to change in a
> 357:      * future version.

Suggest rewording this to: "By default, this method returns the same value as {@code Subject.getSubject(AccessController.getContext())}. This preserves compatibility with code that may still be calling {@code doAs} which installs the subject in an {@code AccessControlContext}. However, if the system property {@systemProperty jdk.security.auth.subject.useTL} is set to {@code true}, the subject is retrieved from an inheritable {@code ThreadLocal} object. This implementation behavior is subject to change in a future version."

src/java.base/share/classes/javax/security/auth/Subject.java line 360:

> 358:      * <p>
> 359:      * No matter what storage is chosen, the current subject will
> 360:      * always be installed by the {@link #callAs} method.

I'm not really sure if this sentence is necessary. It seems like it doesn't need to be in the specification to me. The first sentence is clear enough to me: "The current subject is installed by the {@link #callAs} method."

src/java.base/share/classes/javax/security/auth/Subject.java line 362:

> 360:      * always be installed by the {@link #callAs} method.
> 361:      *
> 362:      * @return the current subject. The return value can be

Suggest to combine this into one sentence: the current subject, or {@code null} if a current subject is not installed or the current subject is set to {@code null}."

src/java.base/share/classes/javax/security/auth/Subject.java line 381:

> 379:      * @implNote
> 380:      * By default, this method calls {@link #doAs(Subject, PrivilegedExceptionAction)
> 381:      * Subject.doAs(subject, altAction)} to store the subject into

s/to store/which stores/
s/into/in/

src/java.base/share/classes/javax/security/auth/Subject.java line 386:

> 384:      * modified to match the specification of this method.
> 385:      * If the system property {@code jdk.security.auth.subject.useTL}
> 386:      * is set to {@code true}, it will be stored in an inheritable

s/it/the subject/

src/java.base/share/classes/javax/security/auth/Subject.java line 387:

> 385:      * If the system property {@code jdk.security.auth.subject.useTL}
> 386:      * is set to {@code true}, it will be stored in an inheritable
> 387:      * {@code ThreadLocal} object. The behavior is subject to change in a

s/The/This/

src/java.base/share/classes/javax/security/auth/Subject.java line 391:

> 389:      * <p>
> 390:      * No matter what storage is chosen, the current subject will
> 391:      * always be retrievable by the {@link #current} method.

Same comment as above.

src/java.base/share/classes/javax/security/auth/Subject.java line 394:

> 392:      *
> 393:      * @param subject the intended current subject for {@code action}.
> 394:      *                Can be {@code null}.

Is it necessary to allow `null` in the new `callAs` method? Is there a use case where this is useful? I know the `doAs` methods allowed it, but it looks like they simply call `AccessController.doPrivileged` in that case w/o a subject. Seems it would be simpler to not allow it and throw an NPE.

src/java.base/share/classes/javax/security/auth/Subject.java line 400:

> 398:      *            of {@code action}
> 399:      * @return the value returned by the {@code call} method of {@code action}
> 400:      * @throws NullPointerException if the {@code Callable} is {@code null}.

s/if the {@code Callable}/if {@code action}/
remove '.'

src/java.base/share/classes/javax/security/auth/Subject.java line 403:

> 401:      * @throws CompletionException if {@code action.call()} throws an
> 402:      *          exception, which will be the cause of this
> 403:      *          {@code CompletionException}.

Suggest to break this into two sentences: "if {@code action.call()} throws an exception. The cause of the           {@code CompletionException} is set to the exception thrown by {@code action.call()}."

test/jdk/javax/security/auth/Subject/CurrentSubject.java line 63:

> 61: 
> 62:     /**
> 63:      * Ensure the current subject is the expected Subject objet.

typo: objet -> object

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From mullan at openjdk.java.net  Wed Oct 27 13:52:18 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 27 Oct 2021 13:52:18 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <Fs5WMBPBUFJhbuuppXDi8wSWuTdXlK4WZ2wtfNy7Nb4=.9716489a-c572-4d9f-85fe-ada2debd024a@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <Fs5WMBPBUFJhbuuppXDi8wSWuTdXlK4WZ2wtfNy7Nb4=.9716489a-c572-4d9f-85fe-ada2debd024a@github.com>
Message-ID: <X8yLhzZP9QU61YkMtXeOGfvk963qWxy3U2UJmAuUoSs=.8c6ce5bd-fbe1-4db9-b6dc-29b24fd8c668@github.com>

On Wed, 27 Oct 2021 12:45:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 296:
> 
>> 294:      *       which is equivalent to
>> 295:      *       {@code Subject.getSubject(AccessController.getContext())}
>> 296:      *       by default in this implementation.
> 
> I don't think you need the words "by default".

I suggest changing the last sentence to two sentences: "However, obtaining a Subject is useful independent of the Security Manager. Thus, a replacement API named {@link #current()} has been added which can be used to obtain the current subject."

I don't think you need to describe the default implementation here because it is hard to explain that succinctly -- just keep that info in `current`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Wed Oct 27 14:05:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:05:12 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v3]
In-Reply-To: <3tZoXWAI_1yKbtZ3XL19PWb7ohSXy9xpUvJc3zg6KdY=.7de919ad-1b52-4b85-a138-2821b47ab702@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <3tZoXWAI_1yKbtZ3XL19PWb7ohSXy9xpUvJc3zg6KdY=.7de919ad-1b52-4b85-a138-2821b47ab702@github.com>
Message-ID: <0tu-ZLFBfiyFynBFGsqirY20ElDwVlNz2eGHfwENE3U=.4f3d6bb5-41e6-4bb0-86c2-b1601ae64d14@github.com>

On Wed, 27 Oct 2021 13:06:54 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected trailing whitespaces

Source code change looks mostly fine to me. I'm running some tests now. Will get back once they finish.

As for the test, IMO, it was meant to show that `SecondLoginModule` is still needed even if it's not in the JAAS login config file. Your updated test only prove it's not really instantiated. How about this:

Change the test directives to

 * @build FirstLoginModule
 * @run main/othervm/fail Loader
 * @build SecondLoginModule
 * @run main/othervm Loader

so that the login succeeds only after there exists a `SecondLoginModule`. All those `isLoaded` flags should be removed so their enclosing classes are not compiled automatically.

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 229:

> 227:     private static final sun.security.util.Debug debug =
> 228:         sun.security.util.Debug.getInstance("logincontext", "\t[LoginContext]");
> 229:     private static final WeakHashMap<ClassLoader, Set<Provider<LoginModule>>> cacheServiceProviders = new WeakHashMap<>();

This line can be a little shorter. There are some other lines below which is also quite long. The original limit was 80 chars but please be at most 90.

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 704:

> 702:                         lmProviders = cacheServiceProviders.get(contextClassLoader);
> 703:                         if (lmProviders == null){
> 704:                             if (debug != null)

Please enclose the following line in a pair of braces.

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 717:

> 715:                                 }
> 716:                             cacheServiceProviders.put(contextClassLoader,lmProviders);
> 717:                         }

Is it necessary the lines below still be inside the synchronized block?

src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 723:

> 721:                                 if (debug != null) {
> 722:                                     debug.println(name + " loaded as a service");
> 723:                                 }

Please de-indent the if block above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Wed Oct 27 14:28:18 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:28:18 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <pLNRmMB4k2SKw_Hd2BTZaumvHnxz45_qezUTplX9-6M=.85910591-2c7f-44c0-9811-53baca1313ec@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <4yomLmh_dnLfLEjGEKMd8dkdhmyYOCrAIrxrJk7LNCg=.4bb1d786-d986-445c-be56-c2455d5a46d0@github.com>
 <pLNRmMB4k2SKw_Hd2BTZaumvHnxz45_qezUTplX9-6M=.85910591-2c7f-44c0-9811-53baca1313ec@github.com>
Message-ID: <lMGoVr1qyRATEsvWCBU2IbXbhFPhXHCMm6tT__xJEIM=.44b3cce3-27e7-4bac-8278-5a695ab343a3@github.com>

On Mon, 25 Oct 2021 19:52:06 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Sure, I can. I was testing the default value to "false" at some time and found `"true".equals` and `!"false".equals` symmetric and good-looking. :-)
>
> It probably doesn?t matter to have the Logic centralized, just looked a bit hardcoded (who knows if yes/no/1/0 is wanted as well ,).

OK, switch to GetBooleanAction.

>> I said "After {@code action} is finished, the current subject is reset to its previous value". Is that what you meant?
>
> My question was more along the line of Post-Security-manager. Will you always be able to call Subject.doAs - especially with null? And if this can already be speced if it might be rejected or not? (the ?after finished? is well documented)

Before the method is removed (It's deprecated from removal), you should always be able to call it with whatever subject including null. If there's no more AccessControlContext we might even have to implement it with callAs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Wed Oct 27 14:40:17 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:40:17 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <X8yLhzZP9QU61YkMtXeOGfvk963qWxy3U2UJmAuUoSs=.8c6ce5bd-fbe1-4db9-b6dc-29b24fd8c668@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <Fs5WMBPBUFJhbuuppXDi8wSWuTdXlK4WZ2wtfNy7Nb4=.9716489a-c572-4d9f-85fe-ada2debd024a@github.com>
 <X8yLhzZP9QU61YkMtXeOGfvk963qWxy3U2UJmAuUoSs=.8c6ce5bd-fbe1-4db9-b6dc-29b24fd8c668@github.com>
Message-ID: <uOrbfXXqeJQ8ApW6arOF4l3p-A4Y0IlvmaGCgkUY_mw=.ee0462e9-6f12-4a78-a8be-cb3be93f8c65@github.com>

On Wed, 27 Oct 2021 13:49:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/javax/security/auth/Subject.java line 296:
>> 
>>> 294:      *       which is equivalent to
>>> 295:      *       {@code Subject.getSubject(AccessController.getContext())}
>>> 296:      *       by default in this implementation.
>> 
>> I don't think you need the words "by default".
>
> I suggest changing the last sentence to two sentences: "However, obtaining a Subject is useful independent of the Security Manager. Thus, a replacement API named {@link #current()} has been added which can be used to obtain the current subject."
> 
> I don't think you need to describe the default implementation here because it is hard to explain that succinctly -- just keep that info in `current`.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Wed Oct 27 14:40:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:40:19 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <Fs5WMBPBUFJhbuuppXDi8wSWuTdXlK4WZ2wtfNy7Nb4=.9716489a-c572-4d9f-85fe-ada2debd024a@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <Fs5WMBPBUFJhbuuppXDi8wSWuTdXlK4WZ2wtfNy7Nb4=.9716489a-c572-4d9f-85fe-ada2debd024a@github.com>
Message-ID: <Iw_SxkAuq_KzSIXtpC_3x-guC8SjMixSm9LvHUr76qk=.93dc7bfc-fdef-4a58-aa0c-651b1ffd5a6e@github.com>

On Wed, 27 Oct 2021 12:46:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 324:
> 
>> 322:     }
>> 323: 
>> 324:     // Store the current subject to a ThreadLocal when a system property is set.
> 
> nit: "... in a ThreadLocal ..."

Oops.

> src/java.base/share/classes/javax/security/auth/Subject.java line 360:
> 
>> 358:      * <p>
>> 359:      * No matter what storage is chosen, the current subject will
>> 360:      * always be installed by the {@link #callAs} method.
> 
> I'm not really sure if this sentence is necessary. It seems like it doesn't need to be in the specification to me. The first sentence is clear enough to me: "The current subject is installed by the {@link #callAs} method."

Removed.

> src/java.base/share/classes/javax/security/auth/Subject.java line 362:
> 
>> 360:      * always be installed by the {@link #callAs} method.
>> 361:      *
>> 362:      * @return the current subject. The return value can be
> 
> Suggest to combine this into one sentence: the current subject, or {@code null} if a current subject is not installed or the current subject is set to {@code null}."

OK.

> src/java.base/share/classes/javax/security/auth/Subject.java line 394:
> 
>> 392:      *
>> 393:      * @param subject the intended current subject for {@code action}.
>> 394:      *                Can be {@code null}.
> 
> Is it necessary to allow `null` in the new `callAs` method? Is there a use case where this is useful? I know the `doAs` methods allowed it, but it looks like they simply call `AccessController.doPrivileged` in that case w/o a subject. Seems it would be simpler to not allow it and throw an NPE.

Maybe in a nested call that wants to clear out the existing subject temporarily? It could be useful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Wed Oct 27 14:40:20 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:40:20 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <fWipdJl9w-AsiErjoiAFWQyBkBkUeVqiFKS58nlgHfA=.fe98e295-e694-47a7-af08-7bb6880dcad6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <NByKzEbyrhEimH7mxpBKJ8-SvfqXSMITJGQynroRrhQ=.d0a89b01-1fa4-4bbd-a17a-b037bcab95d6@github.com>
 <fWipdJl9w-AsiErjoiAFWQyBkBkUeVqiFKS58nlgHfA=.fe98e295-e694-47a7-af08-7bb6880dcad6@github.com>
Message-ID: <dzZow7gKZrnvMS8MkoKstLg6rRvUTppt6AghNOXckA4=.c0307680-5487-48b2-9425-5e2e94f33306@github.com>

On Mon, 25 Oct 2021 20:02:14 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Oh, it's needed. Otherwise the `AccessController.getContext()` call (which is inside `current()`) will also be called in a clean privileged context and there is no subject associated with it.
>> 
>> On the other hand, it still needs to in some sort of doPriv. I don't want to ignore `AuthPermission("getSubject")`.
>
> Hm yes i see why ?withacombiner? would be needed, just not sure why doPriveledged() is needed (especially since current() does it as well). But I admit i don?t see through that part, so ignore me if I don?t make sense.

Application code calling `Krb5Context::initSecContext` does not require a `AuthPermission("getSubject")` because `getSubject` was called in a doPriv. After switching to `current`, it still does not require this permission if we call the new method in a doPrivWithCombiner.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Wed Oct 27 14:52:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:52:47 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v3]
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <6GbQghQwwhfQdWUSFn4f30zba8UMd2M4B6Wi33T8T-k=.ce9723a6-b017-465e-b954-cc9555328e10@github.com>

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  address comments from Sean and Bernd

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5024/files
  - new: https://git.openjdk.java.net/jdk/pull/5024/files/2f862e02..a29c8d93

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=01-02

  Stats: 39 lines in 5 files changed: 0 ins; 11 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5024.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5024/head:pull/5024

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Wed Oct 27 14:52:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 14:52:51 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v2]
In-Reply-To: <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
Message-ID: <130pM_koAhwW6pFyVYzSTMNLItLVziZ-4ZxyxdxcbUQ=.dfc6042d-9fc8-4332-a823-554bf13395d9@github.com>

On Sat, 23 Oct 2021 00:40:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renames

New commit pushed. The only unresolved is about whether `callAs` can take a null subject.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From duke at openjdk.java.net  Wed Oct 27 16:21:20 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 27 Oct 2021 16:21:20 GMT
Subject: Integrated: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <9BGa0d9dkCjuAJV2PJrCCMDAMGjW6WSkDGeuWSn3Xh8=.6eacd128-16e4-4d80-a9a4-310e9107f6af@github.com>

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

This pull request has now been integrated.

Changeset: 9a3e9542
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a3e9542997860de79d07a4411b1007e9cd5c348
Stats:     31 lines in 11 files changed: 0 ins; 0 del; 31 mod

8274879: Replace uses of StringBuffer with StringBuilder within java.base classes

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/5432

From hchao at openjdk.java.net  Wed Oct 27 16:32:48 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 27 Oct 2021 16:32:48 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v2]
In-Reply-To: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
Message-ID: <d-KP7lylOuaz5ciPLNg3TdhhxLmOQKC8Ky-NPjG0MX8=.a0ea7389-0952-4cb8-aa09-0996303f7c10@github.com>

> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updated TimestampCheck test and removed its unused methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6126/files
  - new: https://git.openjdk.java.net/jdk/pull/6126/files/ba4bb4b7..02f723d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=00-01

  Stats: 46 lines in 1 file changed: 0 ins; 45 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6126/head:pull/6126

PR: https://git.openjdk.java.net/jdk/pull/6126

From weijun at openjdk.java.net  Wed Oct 27 16:47:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 16:47:12 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v2]
In-Reply-To: <d-KP7lylOuaz5ciPLNg3TdhhxLmOQKC8Ky-NPjG0MX8=.a0ea7389-0952-4cb8-aa09-0996303f7c10@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
 <d-KP7lylOuaz5ciPLNg3TdhhxLmOQKC8Ky-NPjG0MX8=.a0ea7389-0952-4cb8-aa09-0996303f7c10@github.com>
Message-ID: <I_OZIq0-EQAGyndQ2SZA9pBh2kx14TfoUiZrEQrSMbY=.f28e4fc5-318c-482b-b996-dfbf3487985c@github.com>

On Wed, 27 Oct 2021 16:32:48 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated TimestampCheck test and removed its unused methods

One new comment: Now that if there is only one cert, there is no need to write `Certificate #n of m`. If there's only one signer, we also don't need to write `of signer #n`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From michaelm at openjdk.java.net  Wed Oct 27 17:23:17 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 27 Oct 2021 17:23:17 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
Message-ID: <fw2tN1vI4v7XDWUcwDWuCEkMPd9gHszwarIjIi2pNMI=.5d28a2b6-838c-409b-8a2a-377269e75568@github.com>

On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ throws NPE to hosts file resolver javadoc

src/java.base/share/classes/java/net/InetAddress.java line 841:

> 839:         // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0' delegate to the system-wide resolver,
> 840:         // which could be a custom one. At that point we treat any unexpected RuntimeException thrown by
> 841:         // the resolver as we would treat an UnknownHostException or an unmatched host name.

indentation issue in comment above

src/java.base/share/classes/java/net/InetAddress.java line 1308:

> 1306:      * Creates an InetAddress based on the provided host name and IP address.
> 1307:      * System {@linkplain InetAddressResolver resolver} is not used to check
> 1308:      * the validity of the address.

Is this term "system resolver" defined somewhere? I think it means the configured resolver for the current VM. Previously, it really was the system resolver. So, I think it's potentially confusing, as there is also reference to the java.net.preferIPv6Addresses system property as having a possible value "system" which refers to the operating system. Since the CSR is approved, I'm happy to discuss this point post integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From ascarpino at openjdk.java.net  Wed Oct 27 17:55:15 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 27 Oct 2021 17:55:15 GMT
Subject: Withdrawn: 8158689: java.security.KeyPair should implement Destroyable
In-Reply-To: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
References: <IgvIYaZzDEKHHwaAQbjwuNipAwjdULlMCbSl47hK8q0=.d28b5df1-71d0-4a04-af2d-4d4f49765410@github.com>
Message-ID: <H-sZjSO2Z18iwTpKukP1SWjKF6yVfxIdxggzIrZDeXY=.cd504ddf-afcd-4f71-9140-1185c92a4a64@github.com>

On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this change.  It makes KeyPair implement Destroyable and implements the methods to call the underlying privateKey.  It also sets the public and private key to 'final'.
> 
> The bug includes a CSR and Release Notes
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
> RN: https://bugs.openjdk.java.net/browse/JDK-8275826

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6089

From duke at openjdk.java.net  Wed Oct 27 18:25:40 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 27 Oct 2021 18:25:40 GMT
Subject: RFR: 8275918: Remove unused local variables in java.base security
 code [v2]
In-Reply-To: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
References: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
Message-ID: <XL4s3IUc830daAHowA2M2LXdLk4KV7rPZyGi3X52oyU=.850df05e-909a-4126-ab63-b740772ec1e5@github.com>

> Cleanup unused local variables. Looks like they are leftovers after refactoring.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8275918: Remove unused local variables in java.base security code
  remove local variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6092/files
  - new: https://git.openjdk.java.net/jdk/pull/6092/files/1d333bb4..3e917a27

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6092&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6092&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6092.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6092/head:pull/6092

PR: https://git.openjdk.java.net/jdk/pull/6092

From duke at openjdk.java.net  Wed Oct 27 18:25:44 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 27 Oct 2021 18:25:44 GMT
Subject: RFR: 8275918: Remove unused local variables in java.base security
 code [v2]
In-Reply-To: <V5ThbufI_q2hmUVqL4ew6DSQwd7rUJAn6Xli4Kg4UrU=.5d4bbf3d-5f52-4dcf-aa45-454dc44d8e2d@github.com>
References: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
 <V5ThbufI_q2hmUVqL4ew6DSQwd7rUJAn6Xli4Kg4UrU=.5d4bbf3d-5f52-4dcf-aa45-454dc44d8e2d@github.com>
Message-ID: <_9a-Ha7K4s9RmG8DEjnPpqpknFL4_aNtr6Q7C8jYsDs=.f1607ae2-f385-4395-a456-9ec53b915ec7@github.com>

On Tue, 26 Oct 2021 15:18:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8275918: Remove unused local variables in java.base security code
>>   remove local variable
>
> src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 211:
> 
>> 209:         AlgorithmParameterSpec keyParams = rsaKey.getParams();
>> 210:         // validate key parameters
>> 211:         if (!isCompatible(keyParams, this.sigParams)) {
> 
> Why not remove the assignment on line 209? This is more consistent with your fix this time.

Ok. Removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6092

From duke at openjdk.java.net  Wed Oct 27 18:43:46 2021
From: duke at openjdk.java.net (Larry-N)
Date: Wed, 27 Oct 2021 18:43:46 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v3]
In-Reply-To: <3tZoXWAI_1yKbtZ3XL19PWb7ohSXy9xpUvJc3zg6KdY=.7de919ad-1b52-4b85-a138-2821b47ab702@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <3tZoXWAI_1yKbtZ3XL19PWb7ohSXy9xpUvJc3zg6KdY=.7de919ad-1b52-4b85-a138-2821b47ab702@github.com>
Message-ID: <ahTaYqLlhLe1h7GDIz6dIpJx_6mTs5rflghzb3XWjzQ=.b02b206f-42a5-4684-a3d5-990d62c58bc8@github.com>

On Wed, 27 Oct 2021 13:06:54 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected trailing whitespaces

Thanks for the review, I'll update the code according to your notices.

Sorry, I didn't catch the point with the test.
Why the `lc.login();`  succeed if SecondLoginModule is compiled or not? 

> "so that the login succeeds only after there exists a SecondLoginModule"

maybe you mean the test Loader.java itself? I have rolled back changes in Loader.java and FirstLoginModule.java, added directives that you proposed to Loader.java, but the test fails.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From duke at openjdk.java.net  Wed Oct 27 18:43:41 2021
From: duke at openjdk.java.net (Larry-N)
Date: Wed, 27 Oct 2021 18:43:41 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v4]
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <rAWg5QTSaPXTxJwFs8UpF-j5Yhtc0I4XX7ttZd9bznI=.dd5e5739-2564-4fd5-a8d7-fcbe2e25929e@github.com>

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

Larry-N has updated the pull request incrementally with one additional commit since the last revision:

  Address review notices

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5748/files
  - new: https://git.openjdk.java.net/jdk/pull/5748/files/fbe99ed7..c4d744a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=02-03

  Stats: 15 lines in 1 file changed: 3 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

PR: https://git.openjdk.java.net/jdk/pull/5748

From duke at openjdk.java.net  Wed Oct 27 18:49:26 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 27 Oct 2021 18:49:26 GMT
Subject: RFR: 8275918: Remove unused local variables in java.base security
 code [v3]
In-Reply-To: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
References: <nRbaqqngILQ2vbl1kkHGTjEbBCRaOK2JIkSRjH2Mrvs=.f7c26784-7ba3-435a-af33-47a0647a233c@github.com>
Message-ID: <lTyLjRnAp4oVh9UC5ph0cAziFOdM798z-D3iBJrmldw=.b612e6ce-50f0-468a-93d7-436a45161161@github.com>

> 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

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6092/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6092&range=02
  Stats: 31 lines in 13 files changed: 0 ins; 17 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6092.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6092/head:pull/6092

PR: https://git.openjdk.java.net/jdk/pull/6092

From mullan at openjdk.java.net  Wed Oct 27 19:32:08 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 27 Oct 2021 19:32:08 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <GNmiQnNhYHYKuUBiQMK-YgQOGBrRItWh2fDJikIZmxk=.27fc8046-0a76-4bfe-aacb-6d6699071705@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
 <GNmiQnNhYHYKuUBiQMK-YgQOGBrRItWh2fDJikIZmxk=.27fc8046-0a76-4bfe-aacb-6d6699071705@github.com>
Message-ID: <lv3iKiOGs9dNEKnStcevP7U5BRZxkAHQdf9ftMxhImA=.3e83a0c1-9933-4b43-a9a7-0dc313ef2c59@github.com>

On Tue, 26 Oct 2021 15:42:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/KeyStoreSpi.java line 457:
>> 
>>> 455:      */
>>> 456:     public Set<Entry.Attribute> engineGetAttributes(String alias) {
>>> 457:         return Collections.emptySet();
>> 
>> Would `Set.of()` be better here?
>
> Both returns an internal constant object and I think they are similar. I was copying the default implementation of `Entry::getAttributes`.

Ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Wed Oct 27 19:39:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 19:39:33 GMT
Subject: RFR: 8231107: Allow store password to be null when saving a PKCS12
 KeyStore [v3]
In-Reply-To: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
References: <eZTgZ0tmhtxv5zgNA6tSZseLrLrw-Cs0WzhfMHOtGZU=.a7e37ccb-bfb6-466f-910f-d03b77417a01@github.com>
Message-ID: <rNz8JZVjCECHTltdXHzBUiY-sIoSKDy1HVUvgtbvTE4=.e7b4fb77-360c-44ee-abc1-d7cc55d3507b@github.com>

> You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`.
> 
> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  spec change
  
  only in patch2:
  unchanged:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5950/files
  - new: https://git.openjdk.java.net/jdk/pull/5950/files/aae1b0c1..3670f992

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5950&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5950.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5950/head:pull/5950

PR: https://git.openjdk.java.net/jdk/pull/5950

From mullan at openjdk.java.net  Wed Oct 27 19:43:15 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 27 Oct 2021 19:43:15 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <poRsRgMLQ4-Xcyvi6Lq6k_xPYYO6sOK6nQgaRZ7JFjY=.4213040b-acbc-4098-8a1c-6c5602caa814@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
 <poRsRgMLQ4-Xcyvi6Lq6k_xPYYO6sOK6nQgaRZ7JFjY=.4213040b-acbc-4098-8a1c-6c5602caa814@github.com>
Message-ID: <4dQ1KFbLDUzR1dRXv_slBDR21YYjSZmoFI2bTkzSvIQ=.27aff629-78e1-48fe-b85f-dd36b5be73b8@github.com>

On Tue, 26 Oct 2021 15:35:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/KeyStore.java line 1035:
>> 
>>> 1033:      *      not extractable (For example, if the attributes is encrypted
>>> 1034:      *      in a private key entry or a secret key entry).
>>> 1035:      *
>> 
>> I think this would read better if you broke it up into multiple sentences, ex: "an unmodifiable {@code Set} of attributes. The set may be empty if the given alias does not exist, or the alias does exist but there are no attributes associated with it or the attributes are not extractable (for example, the attributes may not be extractable if they are encrypted in a private key or secret key entry)."
>> 
>> You may also want to add a sentence to try the `KeyStore$Entry::getAttributes` method if there are no attributes.
>> 
>> Did you consider throwing a KeyStoreException if they are not extractable? It would be useful to distinguish that case from an alias that has no attributes.
>
> This is complicated. Theoretically a KeyStore implementation can store some attributes in clear text and some encrypted, and it's probably not possible to know if there exist any encrypted ones before actually decrypting the entry. Maybe I should say "For a PrivateKeyEntry or SecretKeyEntry, some attributes might only be available after the entry is extracted by the getEntry() method. Try calling the entry's getAttributes() method to see if there are any".

Yes, a sentence like that would help. Some suggested tweaks: "For a PrivateKeyEntry or SecretKeyEntry, some attributes may be protected and not available unless the entry is first extracted by the getEntry() method."

I don't think you need the last sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Wed Oct 27 19:59:11 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 19:59:11 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v4]
In-Reply-To: <rAWg5QTSaPXTxJwFs8UpF-j5Yhtc0I4XX7ttZd9bznI=.dd5e5739-2564-4fd5-a8d7-fcbe2e25929e@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <rAWg5QTSaPXTxJwFs8UpF-j5Yhtc0I4XX7ttZd9bznI=.dd5e5739-2564-4fd5-a8d7-fcbe2e25929e@github.com>
Message-ID: <ZvY6SwhyUTeG7VSfeHLGEhJpbR2L_2N80GFD-2QFPxw=.287f3dc7-9a13-4d09-980d-f44d2d99c93f@github.com>

On Wed, 27 Oct 2021 18:43:41 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review notices

Have you removed the `isLoaded` flags? If they are still referenced in `Loader`, the two files will always be compiled before running the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From duke at openjdk.java.net  Wed Oct 27 20:08:34 2021
From: duke at openjdk.java.net (Larry-N)
Date: Wed, 27 Oct 2021 20:08:34 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v5]
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

Larry-N has updated the pull request incrementally with one additional commit since the last revision:

  Trailing spaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5748/files
  - new: https://git.openjdk.java.net/jdk/pull/5748/files/c4d744a0..a6cc6151

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Wed Oct 27 20:14:18 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Oct 2021 20:14:18 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <4dQ1KFbLDUzR1dRXv_slBDR21YYjSZmoFI2bTkzSvIQ=.27aff629-78e1-48fe-b85f-dd36b5be73b8@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
 <poRsRgMLQ4-Xcyvi6Lq6k_xPYYO6sOK6nQgaRZ7JFjY=.4213040b-acbc-4098-8a1c-6c5602caa814@github.com>
 <4dQ1KFbLDUzR1dRXv_slBDR21YYjSZmoFI2bTkzSvIQ=.27aff629-78e1-48fe-b85f-dd36b5be73b8@github.com>
Message-ID: <d5VD51QeGFqqilzWytgGZB6fQDoxABHlE-7OKkZcKgI=.36ea9f4d-071c-4ddd-9292-87c2fc05b977@github.com>

On Wed, 27 Oct 2021 19:40:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is complicated. Theoretically a KeyStore implementation can store some attributes in clear text and some encrypted, and it's probably not possible to know if there exist any encrypted ones before actually decrypting the entry. Maybe I should say "For a PrivateKeyEntry or SecretKeyEntry, some attributes might only be available after the entry is extracted by the getEntry() method. Try calling the entry's getAttributes() method to see if there are any".
>
> Yes, a sentence like that would help. Some suggested tweaks: "For a PrivateKeyEntry or SecretKeyEntry, some attributes may be protected and not available unless the entry is first extracted by the getEntry() method."
> 
> I don't think you need the last sentence.

I wonder if someone will interpret this as "after I've called `getEntry` on a private key, I can get the encrypted attributes through `KeyStore::getAttributes`". How about something like "and only available through the {@link KeyEntry.getAttributres} method after the entry is extracted"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From mullan at openjdk.java.net  Thu Oct 28 13:46:20 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Oct 2021 13:46:20 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v3]
In-Reply-To: <6GbQghQwwhfQdWUSFn4f30zba8UMd2M4B6Wi33T8T-k=.ce9723a6-b017-465e-b954-cc9555328e10@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <6GbQghQwwhfQdWUSFn4f30zba8UMd2M4B6Wi33T8T-k=.ce9723a6-b017-465e-b954-cc9555328e10@github.com>
Message-ID: <yV-tGZGlvowqARUxlhoikT1AQie-IrUVVErY-wem6zY=.bb1063b4-618c-4573-863b-2da76549a8b0@github.com>

On Wed, 27 Oct 2021 14:52:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments from Sean and Bernd

src/java.base/share/classes/javax/security/auth/Subject.java line 381:

> 379:      * is equivalent to {@code action.call()} and the exception thrown is
> 380:      * modified to match the specification of this method.
> 381:      * If the system property {@code jdk.security.auth.subject.useTL}

I would add a similar sentence before this, like in the `current` method: "This preserves compatibility with code that may still be calling {@code getSubject(AccessControlContext)} which retrieves the subject from an {@code AccessControlContext}."

src/java.base/share/classes/javax/security/auth/Subject.java line 393:

> 391:      *            of {@code action}
> 392:      * @return the value returned by the {@code call} method of {@code action}
> 393:      * @throws NullPointerException if {@code code} is {@code null}

s/code/action/

src/java.base/share/classes/javax/security/auth/Subject.java line 539:

> 537:      *       and subject to removal in a future release. Instead, users can
> 538:      *       call {@link #callAs} to perform the same work, which is based on
> 539:      *       this method by default in this implementation.

Same comment as above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From mullan at openjdk.java.net  Thu Oct 28 13:46:20 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Oct 2021 13:46:20 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v3]
In-Reply-To: <pLNRmMB4k2SKw_Hd2BTZaumvHnxz45_qezUTplX9-6M=.85910591-2c7f-44c0-9811-53baca1313ec@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <UHjyJQmd-nobxfwy8Z7ZXqdtvrHID_87j2DsHSb3imQ=.434625ea-e4cb-47be-949c-af53076624f7@github.com>
 <HA8vIHvoS3IGGy5x44RN9pn_yNy-DEEFHqBcjmaCINg=.0839f3b3-207f-429b-968e-135bb9620ec6@github.com>
 <4yomLmh_dnLfLEjGEKMd8dkdhmyYOCrAIrxrJk7LNCg=.4bb1d786-d986-445c-be56-c2455d5a46d0@github.com>
 <pLNRmMB4k2SKw_Hd2BTZaumvHnxz45_qezUTplX9-6M=.85910591-2c7f-44c0-9811-53baca1313ec@github.com>
Message-ID: <uZGFer0fFbomdhCUlIUAfCVIa3y70g5W516Kh3FXGk8=.e1f9a121-6dc7-405c-91eb-30e183079010@github.com>

On Mon, 25 Oct 2021 19:55:44 GMT, Bernd <duke at openjdk.java.net> wrote:

>> I just don't want to touch existing spec. Even for `doAs`, I only said "callAs is based on doAs by default" and didn't went out explaining what is NOT by default. Is that OK?
>
> Yes good reason not to change it.

Suggest using similar wording as in `getSubject`: "However, performing work as a Subject is useful independent of the Security Manager. Thus, a replacement API named {@link #callAs()} has been added which can be used to perform the same work."

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From mullan at openjdk.java.net  Thu Oct 28 13:54:16 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Oct 2021 13:54:16 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method
In-Reply-To: <d5VD51QeGFqqilzWytgGZB6fQDoxABHlE-7OKkZcKgI=.36ea9f4d-071c-4ddd-9292-87c2fc05b977@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
 <poRsRgMLQ4-Xcyvi6Lq6k_xPYYO6sOK6nQgaRZ7JFjY=.4213040b-acbc-4098-8a1c-6c5602caa814@github.com>
 <4dQ1KFbLDUzR1dRXv_slBDR21YYjSZmoFI2bTkzSvIQ=.27aff629-78e1-48fe-b85f-dd36b5be73b8@github.com>
 <d5VD51QeGFqqilzWytgGZB6fQDoxABHlE-7OKkZcKgI=.36ea9f4d-071c-4ddd-9292-87c2fc05b977@github.com>
Message-ID: <_An1mPxt9cv-ZN70M46vimP6zylG3bbRzdyhTx1XVkI=.f7b3bcfa-4764-457e-8a48-a977b5a62fd2@github.com>

On Wed, 27 Oct 2021 20:10:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Yes, a sentence like that would help. Some suggested tweaks: "For a PrivateKeyEntry or SecretKeyEntry, some attributes may be protected and not available unless the entry is first extracted by the getEntry() method."
>> 
>> I don't think you need the last sentence.
>
> I wonder if someone will interpret this as "after I've called `getEntry` on a private key, I can get the encrypted attributes through `KeyStore::getAttributes`". How about something like "and only available through the {@link KeyEntry.getAttributres} method after the entry is extracted"?

Ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From duke at openjdk.java.net  Thu Oct 28 15:39:18 2021
From: duke at openjdk.java.net (Larry-N)
Date: Thu, 28 Oct 2021 15:39:18 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v5]
In-Reply-To: <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
Message-ID: <Rl-iAuy3NlRmPP8chiHgYVcF3JQHIcY-gHcno3pQEG8=.f1f53ab5-d6d3-42f8-ba24-fc8604a94bf7@github.com>

On Wed, 27 Oct 2021 20:08:34 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing spaces

Probably i do something wrong, but I've removed the isLoaded from both login modules classes, so the test looks like this:

 * @build FirstLoginModule
 * @run main/othervm/fail Loader
 * @build SecondLoginModule
 * @run main/othervm Loader
 */
public class Loader {

    public static void main(String[] args) throws Exception {

        System.setProperty("java.security.auth.login.config",
                new File(System.getProperty("test.src"), "sl.conf").toString());
        LoginContext lc = new LoginContext("me");

        lc.login();

    }
}

and the jtreg says: 
Failed. Execution passed unexpectedly:

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Thu Oct 28 16:05:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 16:05:13 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v5]
In-Reply-To: <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
Message-ID: <mA9r-bWxNBnbfwSyCp9ng0Vvkj8HK3ntI2ZnZcwJbG4=.70b4686a-1842-452a-ac55-9cb915be4a82@github.com>

On Wed, 27 Oct 2021 20:08:34 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing spaces

On my machine, the 1st `@run` fails as expected with "java.util.ServiceConfigurationError: javax.security.auth.spi.LoginModule: Provider SecondLoginModule not found". When it passed on your machine, can you find SecondLoginModule.class in jtreg's working directory? If I stop at the first `@run` I only see Loader.class and FirstLoginModule.class. Maybe you need to clean up the working directory first?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From hchao at openjdk.java.net  Thu Oct 28 16:17:44 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 16:17:44 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v3]
In-Reply-To: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
Message-ID: <mvELhRxtNRLf8uYMFEsu8tQJzb9-nBzNoTRLH_BCdek=.3c72c050-20ad-4f5d-b451-e276943d7033@github.com>

> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update output per review comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6126/files
  - new: https://git.openjdk.java.net/jdk/pull/6126/files/02f723d5..85b3cf46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=01-02

  Stats: 130 lines in 4 files changed: 82 ins; 23 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6126/head:pull/6126

PR: https://git.openjdk.java.net/jdk/pull/6126

From hchao at openjdk.java.net  Thu Oct 28 16:17:51 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 16:17:51 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v3]
In-Reply-To: <u7mYp2gcXwo9uVitVe4jHA9wfIgROco8q-NEF55LJcE=.5f748bcf-46d2-44ab-98ba-a306c13b51a5@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
 <u7mYp2gcXwo9uVitVe4jHA9wfIgROco8q-NEF55LJcE=.5f748bcf-46d2-44ab-98ba-a306c13b51a5@github.com>
Message-ID: <k6Y0IFOTSDzTA5ImskMo5hCP53nyaaYTU7iXsBWZnAc=.49eb7586-acd6-439c-8f9d-90a0cc73d308@github.com>

On Tue, 26 Oct 2021 23:23:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update output per review comment
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2878:
> 
>> 2876:                             out.println();
>> 2877:                             out.println();
>> 2878:                             out.println(rb.getString("Signature."));
> 
> Please remove a newline as well. There needn't be 3 `println()` calls.

Done.

> src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 469:
> 
>> 467:         {"one.in.many", "%1$s #%2$d of %3$d"},
>> 468:         {"one.in.many1", "%1$s of signer #%2$d"},
>> 469:         {"one.in.many2", "%1$s #%2$d of %3$d of signer #%4$d"},
> 
> `certificate #1 of 2 of signer #1` is a little too complicated. The second number is not really necessary. I think `certificate #1 of signer #1` is enough.

Done. Changed the warning message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From weijun at openjdk.java.net  Thu Oct 28 16:58:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 16:58:47 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v2]
In-Reply-To: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
Message-ID: <HWQeiDEEIMa5A8ZeSmOVMYi2r7TQ7HhYgaPMUvJL-hY=.fd38bedf-93d9-4e53-a6a1-26e7dce46ed6@github.com>

> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  clarification on protected attributes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6026/files
  - new: https://git.openjdk.java.net/jdk/pull/6026/files/86bbe87b..7238e784

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=00-01

  Stats: 18 lines in 2 files changed: 13 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Thu Oct 28 16:58:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 16:58:49 GMT
Subject: RFR: 8225181: KeyStore should have a getAttributes method [v2]
In-Reply-To: <_An1mPxt9cv-ZN70M46vimP6zylG3bbRzdyhTx1XVkI=.f7b3bcfa-4764-457e-8a48-a977b5a62fd2@github.com>
References: <XTW5eese0JOA1h_vEs4l6_qaza3MLxdcryK_TFs5vFA=.3eb2796e-f3e1-4b0d-898e-c6918ce2de57@github.com>
 <A-tvE1HKsscvvHBtCmVsk-vvVbHEG_0JjSTnlWFrAH8=.ddbb7492-2c18-4e36-b4b2-cb7a72a6640a@github.com>
 <poRsRgMLQ4-Xcyvi6Lq6k_xPYYO6sOK6nQgaRZ7JFjY=.4213040b-acbc-4098-8a1c-6c5602caa814@github.com>
 <4dQ1KFbLDUzR1dRXv_slBDR21YYjSZmoFI2bTkzSvIQ=.27aff629-78e1-48fe-b85f-dd36b5be73b8@github.com>
 <d5VD51QeGFqqilzWytgGZB6fQDoxABHlE-7OKkZcKgI=.36ea9f4d-071c-4ddd-9292-87c2fc05b977@github.com>
 <_An1mPxt9cv-ZN70M46vimP6zylG3bbRzdyhTx1XVkI=.f7b3bcfa-4764-457e-8a48-a977b5a62fd2@github.com>
Message-ID: <GJxz4HQMVViixr8Jpg64KfIc_Y6kFIGbv5eenfD8R5E=.9d79e696-e363-4366-bcd1-96b99e1628f9@github.com>

On Thu, 28 Oct 2021 13:51:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I wonder if someone will interpret this as "after I've called `getEntry` on a private key, I can get the encrypted attributes through `KeyStore::getAttributes`". How about something like "and only available through the {@link KeyEntry.getAttributres} method after the entry is extracted"?
>
> Ok.

New commit pushed. The words are sightly different between in `KeyStore` and `KeyStoreSpi`. CSR updated as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6026

From weijun at openjdk.java.net  Thu Oct 28 17:21:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 17:21:42 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v4]
In-Reply-To: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
Message-ID: <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>

> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
> 
> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
> 
> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
> 
> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more spec tweaks

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5024/files
  - new: https://git.openjdk.java.net/jdk/pull/5024/files/a29c8d93..a9380c0b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5024&range=02-03

  Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5024.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5024/head:pull/5024

PR: https://git.openjdk.java.net/jdk/pull/5024

From weijun at openjdk.java.net  Thu Oct 28 17:25:17 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 17:25:17 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v4]
In-Reply-To: <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>
Message-ID: <XfzTM8raj6B0ywM3LO97YN81Okva8umVNGXQBArJWjo=.24986f56-e723-4fda-8f5e-5705053a4172@github.com>

On Thu, 28 Oct 2021 17:21:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more spec tweaks

New commit pushed. CSR updated as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From duke at openjdk.java.net  Thu Oct 28 17:34:16 2021
From: duke at openjdk.java.net (Larry-N)
Date: Thu, 28 Oct 2021 17:34:16 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v5]
In-Reply-To: <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
Message-ID: <K8V_QMk1HZTUrBTTK5atGSa5GQ40WMDko5eBnUvbZ94=.260c19da-c57b-4da6-94a8-34ff7d125dbf@github.com>

On Wed, 27 Oct 2021 20:08:34 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing spaces

Thank you for the explanations. When I cleaned up the working directory all pass ok. ( And fails when I submitted the test a second time)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Thu Oct 28 17:39:17 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 17:39:17 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v3]
In-Reply-To: <mvELhRxtNRLf8uYMFEsu8tQJzb9-nBzNoTRLH_BCdek=.3c72c050-20ad-4f5d-b451-e276943d7033@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
 <mvELhRxtNRLf8uYMFEsu8tQJzb9-nBzNoTRLH_BCdek=.3c72c050-20ad-4f5d-b451-e276943d7033@github.com>
Message-ID: <ZLTdLbGXy30_queuDrQXjpptifJPU2KEdgcJEy707HM=.8b30f858-a020-4c28-8edd-d80ad8b208cb@github.com>

On Thu, 28 Oct 2021 16:17:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update output per review comment

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2895:

> 2893:                             ss.add(signer);
> 2894:                         }
> 2895:                     }

I think the `while (entries.hasMoreElements())` block should end here, so that you collect all signers of all entries before printing them out. Also, there is no need to count `CodeSigner`, you can simply get it from `ss.size()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From duke at openjdk.java.net  Thu Oct 28 17:45:44 2021
From: duke at openjdk.java.net (Larry-N)
Date: Thu, 28 Oct 2021 17:45:44 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v6]
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <0Ze5JxE4sVukq8xrfkamAz6rjpE0HH0QSdkuneB4mD4=.b1760826-9681-4cb6-9a1a-6ec6bd5ae6c4@github.com>

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

Larry-N has updated the pull request incrementally with one additional commit since the last revision:

  A Corrected the Loader.java testcase

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5748/files
  - new: https://git.openjdk.java.net/jdk/pull/5748/files/a6cc6151..9ab2090e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=04-05

  Stats: 25 lines in 3 files changed: 3 ins; 21 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Thu Oct 28 17:45:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 17:45:46 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v6]
In-Reply-To: <0Ze5JxE4sVukq8xrfkamAz6rjpE0HH0QSdkuneB4mD4=.b1760826-9681-4cb6-9a1a-6ec6bd5ae6c4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <0Ze5JxE4sVukq8xrfkamAz6rjpE0HH0QSdkuneB4mD4=.b1760826-9681-4cb6-9a1a-6ec6bd5ae6c4@github.com>
Message-ID: <3Qc97mO_YzU0zkElaz1pdG4i_iNcyNt7UanChGPvYXU=.185d0955-cdf2-4fb6-abb9-47107c7fa47f@github.com>

On Thu, 28 Oct 2021 17:42:28 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A Corrected the Loader.java testcase

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Thu Oct 28 17:45:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 17:45:49 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v5]
In-Reply-To: <K8V_QMk1HZTUrBTTK5atGSa5GQ40WMDko5eBnUvbZ94=.260c19da-c57b-4da6-94a8-34ff7d125dbf@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
 <K8V_QMk1HZTUrBTTK5atGSa5GQ40WMDko5eBnUvbZ94=.260c19da-c57b-4da6-94a8-34ff7d125dbf@github.com>
Message-ID: <1HOkre9YE0FRpUF1Icksc11TGDR71uMxFLDbmuq5vHs=.1278c9f8-e18e-46af-8ea1-df032030f3af@github.com>

On Thu, 28 Oct 2021 17:31:26 GMT, Larry-N <duke at openjdk.java.net> wrote:

> Thank you for the explanations. When I cleaned up the working directory all pass ok. ( And fails when I submitted the test a second time)

Let's hope the directory is always clean when the test is actually launched. I have no other comments. Thanks for the patience.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Thu Oct 28 17:48:17 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 17:48:17 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v5]
In-Reply-To: <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <72ol0eu2KxP3ZIMygieY8ZMN5heXQ7-AHX7TCj-wXSc=.84ddb8e6-56ab-4f23-a7d3-3e4281d088f7@github.com>
Message-ID: <AbdQ3BshtngD9jPB66i4qfo3Hk9uBbwl__1zfyiFvwc=.18ef7fa7-5a60-4be0-bd3f-240db62b1c06@github.com>

On Wed, 27 Oct 2021 20:08:34 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing spaces

You might want to see if the "clean" action is useful here. See https://openjdk.java.net/jtreg/tag-spec.html.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From chap at anastigmatix.net  Thu Oct 28 17:48:19 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Thu, 28 Oct 2021 13:48:19 -0400
Subject: Post-JEP411 request: callAs(Supplier<Subject>) Re: RFR: 8267108:
 Alternate Subject.getSubject and doAs APIs that do not depend on Security
 Manager APIs [v4]
In-Reply-To: <XfzTM8raj6B0ywM3LO97YN81Okva8umVNGXQBArJWjo=.24986f56-e723-4fda-8f5e-5705053a4172@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>
 <XfzTM8raj6B0ywM3LO97YN81Okva8umVNGXQBArJWjo=.24986f56-e723-4fda-8f5e-5705053a4172@github.com>
Message-ID: <617AE263.5050306@anastigmatix.net>

On 10/28/21 13:25, Weijun Wang wrote:
>>> New `Subject` APIs `current()` and `callAs()` are created ...
>>> where the `callAs()` method stores the subject into a `ThreadLocal`
>>> object and the `current()` method returns it


That approach is simple and sweet. There is a case it doesn't cover,
where the Java runtime is embedded in a larger application where the
identity could change during upcalls from Java into the embedding app.

For those cases, it is better to be able to pass callAs a Supplier<Subject>
rather than a single unchanging Subject.

The effect was achievable in the pre-JEP411 world by installing
a suitably clever DomainCombiner, but with the current proposed replacement
the ability would be lost.

Naturally, it would be simple to support the callAs(Subject s) common case
as well, and simply store () -> s in the ThreadLocal.

Regards,
-Chap

From duke at openjdk.java.net  Thu Oct 28 18:55:32 2021
From: duke at openjdk.java.net (Larry-N)
Date: Thu, 28 Oct 2021 18:55:32 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v7]
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <xwvnl__yeRiaUh6v1Kmwqzk2Ib-Qs1ySFsd77xuIMH8=.6520dbe1-cc62-4084-aaa1-bf686b6e6002@github.com>

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

Larry-N has updated the pull request incrementally with one additional commit since the last revision:

  Address review notes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5748/files
  - new: https://git.openjdk.java.net/jdk/pull/5748/files/9ab2090e..842eb370

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=05-06

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

PR: https://git.openjdk.java.net/jdk/pull/5748

From duke at openjdk.java.net  Thu Oct 28 18:55:33 2021
From: duke at openjdk.java.net (Larry-N)
Date: Thu, 28 Oct 2021 18:55:33 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v6]
In-Reply-To: <0Ze5JxE4sVukq8xrfkamAz6rjpE0HH0QSdkuneB4mD4=.b1760826-9681-4cb6-9a1a-6ec6bd5ae6c4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <0Ze5JxE4sVukq8xrfkamAz6rjpE0HH0QSdkuneB4mD4=.b1760826-9681-4cb6-9a1a-6ec6bd5ae6c4@github.com>
Message-ID: <YlsZuiEOsRr9Nm-f5ubNqQJXBGVs5KN-B4mHnBGq4JY=.35af58b7-6c09-4c35-9b85-0a169e077634@github.com>

On Thu, 28 Oct 2021 17:45:44 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A Corrected the Loader.java testcase

Thanks, I've added `@clean` as you propose.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From rick.hillegas at gmail.com  Thu Oct 28 19:14:41 2021
From: rick.hillegas at gmail.com (Rick Hillegas)
Date: Thu, 28 Oct 2021 12:14:41 -0700
Subject: previously prevented exploit now possible with JDK 18
Message-ID: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>

As a canary in the mineshaft, I built and tested Apache Derby with the 
recent build 18-ea+20-1248 of Open JDK 18. I tripped across the 
following issue when running Derby's regression tests. The problem is 
explained in more detail at 
https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro 
(DERBY_7126_A) can be found. The problem is almost surely the result of 
work done on https://bugs.openjdk.java.net/browse/JDK-8269039 (Disable 
SHA-1 Signed JARs).

Under previous versions of the JDK, the JVM would raise an error if you 
tried to load a class from a jar file which had been signed with SHA-1 
but later hacked by inserting malware via "jar -uf". This was the error:

 ? SHA1 digest error for $corruptedJarFileName

However, under JDK 18 the hacked class loads, no error is raised, and 
the malware can now be executed. I was surprised that a previously 
prevented exploit now works. I think it would be better if the JVM still 
refused to load the hacked class even though SHA-1 has been deprecated.

Thanks,
-Rick


From weijun at openjdk.java.net  Thu Oct 28 19:28:16 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 19:28:16 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading
 application [v7]
In-Reply-To: <xwvnl__yeRiaUh6v1Kmwqzk2Ib-Qs1ySFsd77xuIMH8=.6520dbe1-cc62-4084-aaa1-bf686b6e6002@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
 <xwvnl__yeRiaUh6v1Kmwqzk2Ib-Qs1ySFsd77xuIMH8=.6520dbe1-cc62-4084-aaa1-bf686b6e6002@github.com>
Message-ID: <u37GxkXcVcGVZAM3gyiePO0gZNa600c8yz1R5IB0V_A=.954692d6-c33d-4c02-90c4-57bf4fc18580@github.com>

On Thu, 28 Oct 2021 18:55:32 GMT, Larry-N <duke at openjdk.java.net> wrote:

>> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
>> This code passed successfully tier1 and tier2 tests on mac os.
>
> Larry-N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review notes

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From weijun at openjdk.java.net  Thu Oct 28 19:38:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 19:38:13 GMT
Subject: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do
 not depend on Security Manager APIs [v4]
In-Reply-To: <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>
References: <m2bps3oEd1tyliiqGIrs0yNjOssh1lYHi0oEkZT4ICM=.35a7100e-09a3-4f87-8f4d-8440db3150cc@github.com>
 <1Zw7noLccsCfoSTfZ_3rLgMhhLeuwPU0vSlaWVHsIuo=.7a2287ea-48c6-40fc-880d-84d529ca9aa6@github.com>
Message-ID: <1Crl5KbvRl-JoKbc0ZhJ6-QPgHhLj3E9KQEVYVmWOMc=.d4899d9f-dbda-413d-91ea-c9819c824831@github.com>

On Thu, 28 Oct 2021 17:21:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we?ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more spec tweaks

Hi, Chap. Thanks for the comment.

Is it possible you run `callAs` with a "higher level" subject that contains a link to another more dynamic subject? For example, just make your `Supplier<Subject>` a public credential inside.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5024

From hchao at openjdk.java.net  Thu Oct 28 21:13:40 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 21:13:40 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v4]
In-Reply-To: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
Message-ID: <CrHUGtNqAe1NhUz5zvCgHnJnd-Oh4wCn4hIE46fg_PE=.874ae3ef-9b26-430f-8358-522094e92aa3@github.com>

> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update while block code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6126/files
  - new: https://git.openjdk.java.net/jdk/pull/6126/files/85b3cf46..1b5840b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=02-03

  Stats: 82 lines in 1 file changed: 33 ins; 38 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6126/head:pull/6126

PR: https://git.openjdk.java.net/jdk/pull/6126

From hchao at openjdk.java.net  Thu Oct 28 21:13:44 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 21:13:44 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v3]
In-Reply-To: <ZLTdLbGXy30_queuDrQXjpptifJPU2KEdgcJEy707HM=.8b30f858-a020-4c28-8edd-d80ad8b208cb@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
 <mvELhRxtNRLf8uYMFEsu8tQJzb9-nBzNoTRLH_BCdek=.3c72c050-20ad-4f5d-b451-e276943d7033@github.com>
 <ZLTdLbGXy30_queuDrQXjpptifJPU2KEdgcJEy707HM=.8b30f858-a020-4c28-8edd-d80ad8b208cb@github.com>
Message-ID: <ArraFJwx57kN0olUGhw9DXk1PJfgTZACELiP36l_-rI=.8417bf25-57a3-4e3d-bd43-bb96a631ea2b@github.com>

On Thu, 28 Oct 2021 17:34:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update output per review comment
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2895:
> 
>> 2893:                             ss.add(signer);
>> 2894:                         }
>> 2895:                     }
> 
> I think the `while (entries.hasMoreElements())` block should end here, so that you collect all signers of all entries before printing them out. Also, there is no need to count `CodeSigner`, you can simply get it from `ss.size()`.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From weijun at openjdk.java.net  Thu Oct 28 22:02:17 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Oct 2021 22:02:17 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v4]
In-Reply-To: <CrHUGtNqAe1NhUz5zvCgHnJnd-Oh4wCn4hIE46fg_PE=.874ae3ef-9b26-430f-8358-522094e92aa3@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
 <CrHUGtNqAe1NhUz5zvCgHnJnd-Oh4wCn4hIE46fg_PE=.874ae3ef-9b26-430f-8358-522094e92aa3@github.com>
Message-ID: <2BbotCXyLEjl8DqfIwIKILItU8cNbGpaKRr00z6ovYk=.bdca5c1e-4cd0-4d42-83c8-99a3a0d6f756@github.com>

On Thu, 28 Oct 2021 21:13:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update while block code

Looks fine now.

I wonder if the order of signers in the set matters. It's possible that one signer appears first in the result of `getCodeSigners()` but because `HashSet` maintains no order it becomes the second. If you are also worried about this, you can make `ss` a `LinkedHashSet`.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6126

From hchao at openjdk.java.net  Thu Oct 28 23:01:32 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 23:01:32 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v5]
In-Reply-To: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
Message-ID: <gYLjudJ-bMSRlToNXqPW7mSKcyNY68bYi3qZY-GwVHE=.e4bbebc6-4941-428e-a7e7-d0c7de5ab94c@github.com>

> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Used LinkedHashSet

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6126/files
  - new: https://git.openjdk.java.net/jdk/pull/6126/files/1b5840b8..a4dbd582

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6126&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6126/head:pull/6126

PR: https://git.openjdk.java.net/jdk/pull/6126

From hchao at openjdk.java.net  Thu Oct 28 23:01:32 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 23:01:32 GMT
Subject: RFR: 8257722: Improve "keytool -printcert -jarfile" output [v4]
In-Reply-To: <CrHUGtNqAe1NhUz5zvCgHnJnd-Oh4wCn4hIE46fg_PE=.874ae3ef-9b26-430f-8358-522094e92aa3@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
 <CrHUGtNqAe1NhUz5zvCgHnJnd-Oh4wCn4hIE46fg_PE=.874ae3ef-9b26-430f-8358-522094e92aa3@github.com>
Message-ID: <G4sfUsGKT6nfZivwuKU0tZITFugIKOvcWM_l1hQm-OM=.f6c92b77-5107-439a-9f7a-5e988f000261@github.com>

On Thu, 28 Oct 2021 21:13:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update while block code

It'd be worry-free by keeping the same ordering. Changed as suggested. Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From hchao at openjdk.java.net  Thu Oct 28 23:08:13 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 28 Oct 2021 23:08:13 GMT
Subject: Integrated: 8257722: Improve "keytool -printcert -jarfile" output
In-Reply-To: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
References: <eYNipvuogMnwp66gGZeZxzoWhEqVhQ8xMjHmzFkvr88=.6f818092-d996-410c-9ee5-6ed8b7781c19@github.com>
Message-ID: <CLv0e9Jku9-VEhyUTFKabaoG-3asUxYHD_0Fxxc5-lQ=.f3fc9ba3-ead6-4d7f-8e43-1a65edfc9c0e@github.com>

On Tue, 26 Oct 2021 22:37:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This change does a few improvements to the output of `keytool -printcert -jarfile` command to help readability and diagnosis.

This pull request has now been integrated.

Changeset: de93b1d0
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de93b1d0e83a9428dae4a9609996fe7b7e9b4932
Stats:     253 lines in 4 files changed: 166 ins; 84 del; 3 mod

8257722: Improve "keytool -printcert -jarfile" output

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/6126

From serb at openjdk.java.net  Fri Oct 29 05:47:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:47:10 GMT
Subject: RFR: 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: <GUSC53KVMDq7M34RiKj6SD7YztQdG8HUGgcvtp8kzOo=.75242db1-5065-4733-b9c3-26757f35e69c@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.

Does anybody have any other suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5326

From duke at openjdk.java.net  Fri Oct 29 11:41:15 2021
From: duke at openjdk.java.net (Larry-N)
Date: Fri, 29 Oct 2021 11:41:15 GMT
Subject: Integrated: 8273026: Slow LoginContext.login() on multi threading
 application
In-Reply-To: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
References: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@github.com>
Message-ID: <_gieCQIwkVflrb9sJRFBKMlymL0katqmdyO3QW9WN5g=.d35c0af8-6c10-42ef-8e07-d76ac956b779@github.com>

On Wed, 29 Sep 2021 10:45:41 GMT, Larry-N <duke at openjdk.java.net> wrote:

> This fix adds a cache of service provider classes to LoginContext (in particular, it's a cache of LoginModules classes). The approach helps to increase the performance of the LoginContext.login() method significantly, especially in a multi-threading environment. Service Loader is used for polling on Service Provider classes, without instantiating LoginModules object if Service Provider name doesn't match record in .config file. The set of service providers is cached for each Context Loader separately.
> This code passed successfully tier1 and tier2 tests on mac os.

This pull request has now been integrated.

Changeset: c0cda1db
Author:    Ilarion Nakonechnyy <Ilarion at azul.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0cda1db4fe74b86faa12136336bdf98c96758d2
Stats:     53 lines in 3 files changed: 26 ins; 17 del; 10 mod

8273026: Slow LoginContext.login() on multi threading application

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/5748

From Alan.Bateman at oracle.com  Fri Oct 29 11:58:29 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 29 Oct 2021 12:58:29 +0100
Subject: previously prevented exploit now possible with JDK 18
In-Reply-To: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
References: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
Message-ID: <7fefdfec-22d4-5b56-5705-8cb283eb4740@oracle.com>

On 28/10/2021 20:14, Rick Hillegas wrote:
> As a canary in the mineshaft, I built and tested Apache Derby with the 
> recent build 18-ea+20-1248 of Open JDK 18. I tripped across the 
> following issue when running Derby's regression tests. The problem is 
> explained in more detail at 
> https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro 
> (DERBY_7126_A) can be found. The problem is almost surely the result 
> of work done on https://bugs.openjdk.java.net/browse/JDK-8269039 
> (Disable SHA-1 Signed JARs).
>
> Under previous versions of the JDK, the JVM would raise an error if 
> you tried to load a class from a jar file which had been signed with 
> SHA-1 but later hacked by inserting malware via "jar -uf". This was 
> the error:
>
> ? SHA1 digest error for $corruptedJarFileName
>
> However, under JDK 18 the hacked class loads, no error is raised, and 
> the malware can now be executed. I was surprised that a previously 
> prevented exploit now works. I think it would be better if the JVM 
> still refused to load the hacked class even though SHA-1 has been 
> deprecated.

As I understand it, if the JAR file was signed with SHA-1 then it is now 
treated as unsigned. Are you saying that unsigned JARs are trusted in 
the environment?

-Alan

From mullan at openjdk.java.net  Fri Oct 29 12:46:24 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 29 Oct 2021 12:46:24 GMT
Subject: Integrated: 8251468:
 X509Certificate.get{Subject, Issuer}AlternativeNames and getExtendedKeyUsage do
 not throw CertificateParsingException if extension is unparseable
In-Reply-To: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
References: <cB-zah_ipPZlveAlEylEihOFXkjkbxoMjPFUtGASlwY=.59dfdbf6-cc22-41ea-aa6f-03bc762a3b40@github.com>
Message-ID: <15Ytiw5C1XPKhmx_fmow_DgFJaIypX5wqpXGQnHOvaM=.2842a324-578c-44a7-9854-ecd78ac1af85@github.com>

On Mon, 25 Oct 2021 12:53:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable.
> 
> This fix changes the behavior to comply with the specification.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8275822

This pull request has now been integrated.

Changeset: 8cc59509
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8cc59509fe7c01c9032275798ccd1531eb8f2e9f
Stats:     234 lines in 4 files changed: 182 ins; 36 del; 16 mod

8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/6106

From rick.hillegas at gmail.com  Fri Oct 29 15:23:22 2021
From: rick.hillegas at gmail.com (Rick Hillegas)
Date: Fri, 29 Oct 2021 08:23:22 -0700
Subject: previously prevented exploit now possible with JDK 18
In-Reply-To: <7fefdfec-22d4-5b56-5705-8cb283eb4740@oracle.com>
References: <2b6ac315-5de9-aa0f-6f3a-6ea9f019773b@gmail.com>
 <7fefdfec-22d4-5b56-5705-8cb283eb4740@oracle.com>
Message-ID: <20618e62-1f58-19c6-024e-d43ac1732fa8@gmail.com>

On 10/29/21 4:58 AM, Alan Bateman wrote:
> On 28/10/2021 20:14, Rick Hillegas wrote:
>> As a canary in the mineshaft, I built and tested Apache Derby with 
>> the recent build 18-ea+20-1248 of Open JDK 18. I tripped across the 
>> following issue when running Derby's regression tests. The problem is 
>> explained in more detail at 
>> https://issues.apache.org/jira/browse/DERBY-7126, where a simple 
>> repro (DERBY_7126_A) can be found. The problem is almost surely the 
>> result of work done on 
>> https://bugs.openjdk.java.net/browse/JDK-8269039 (Disable SHA-1 
>> Signed JARs).
>>
>> Under previous versions of the JDK, the JVM would raise an error if 
>> you tried to load a class from a jar file which had been signed with 
>> SHA-1 but later hacked by inserting malware via "jar -uf". This was 
>> the error:
>>
>> ? SHA1 digest error for $corruptedJarFileName
>>
>> However, under JDK 18 the hacked class loads, no error is raised, and 
>> the malware can now be executed. I was surprised that a previously 
>> prevented exploit now works. I think it would be better if the JVM 
>> still refused to load the hacked class even though SHA-1 has been 
>> deprecated.
>
> As I understand it, if the JAR file was signed with SHA-1 then it is 
> now treated as unsigned. Are you saying that unsigned JARs are trusted 
> in the environment?
>
> -Alan
There are many security mechanisms in Derby. Application designers pick 
and choose the mechanisms they think are useful. So, yes, many 
applications load unsigned jars into the database. For applications 
which require signed jars, this poses a vulnerability which didn't exist 
before. At first blush, the jar appears to be signed.



From aefimov at openjdk.java.net  Fri Oct 29 16:17:51 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 29 Oct 2021 16:17:51 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <fw2tN1vI4v7XDWUcwDWuCEkMPd9gHszwarIjIi2pNMI=.5d28a2b6-838c-409b-8a2a-377269e75568@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
 <fw2tN1vI4v7XDWUcwDWuCEkMPd9gHszwarIjIi2pNMI=.5d28a2b6-838c-409b-8a2a-377269e75568@github.com>
Message-ID: <in62DPYR3EJyJHmnVB3pxSzgLd6Ne3PusXMazCxPEPk=.11b775c3-1350-4b45-ac9e-3f365922a640@github.com>

On Wed, 27 Oct 2021 16:23:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @ throws NPE to hosts file resolver javadoc
>
> src/java.base/share/classes/java/net/InetAddress.java line 841:
> 
>> 839:         // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0' delegate to the system-wide resolver,
>> 840:         // which could be a custom one. At that point we treat any unexpected RuntimeException thrown by
>> 841:         // the resolver as we would treat an UnknownHostException or an unmatched host name.
> 
> indentation issue in comment above

Thanks - moved the comment block inside `catch` block (f660cc6ecc7a31c83de220160b9fd8d0fbacd1be)

> src/java.base/share/classes/java/net/InetAddress.java line 1308:
> 
>> 1306:      * Creates an InetAddress based on the provided host name and IP address.
>> 1307:      * System {@linkplain InetAddressResolver resolver} is not used to check
>> 1308:      * the validity of the address.
> 
> Is this term "system resolver" defined somewhere? I think it means the configured resolver for the current VM. Previously, it really was the system resolver. So, I think it's potentially confusing, as there is also reference to the java.net.preferIPv6Addresses system property as having a possible value "system" which refers to the operating system. Since the CSR is approved, I'm happy to discuss this point post integration.

Thanks for highlighting that: Changed `"system"` to `"the system-wide"` - that's what was originally meant by `"system resolver"` (f660cc6ecc7a31c83de220160b9fd8d0fbacd1be).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Fri Oct 29 16:17:46 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 29 Oct 2021 16:17:46 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v10]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Replace 'system' with 'the system-wide', move comment section

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/2ca78ba9..f660cc6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=08-09

  Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Fri Oct 29 16:28:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Oct 2021 16:28:16 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v10]
In-Reply-To: <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>
Message-ID: <wKCFBv1uFCM0-LKR0sZ3XKsF9ikJGCGa5c5-JwX0TRk=.50646f60-003c-4e1c-a82b-32ca0a133540@github.com>

On Fri, 29 Oct 2021 16:17:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 'system' with 'the system-wide', move comment section

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5822

From mchung at openjdk.java.net  Fri Oct 29 16:35:23 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 29 Oct 2021 16:35:23 GMT
Subject: RFR: 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: <DHI5YMCid9Tv-5Fd4KuFDA6i8GXIn0t5FJRGciK3KIE=.76d5b585-ec04-4d7e-8364-e2f07d888df4@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.

The change looks okay.   My suggestion is to get 1-6 all ready to push around the same time.  It's okay to have separate JBS issues and PRs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5326

From cverghese at openjdk.java.net  Fri Oct 29 23:58:06 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Fri, 29 Oct 2021 23:58:06 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
Message-ID: <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>

> 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

Clive Verghese 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 three new commits since the last revision:

 - 8274308: Improve efficiency for HandshakeContext initialization
 - Add SSLEngineBenchmark
 - Benchmark

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5793/files
  - new: https://git.openjdk.java.net/jdk/pull/5793/files/46ae42bf..baf0a90f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5793&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5793&range=00-01

  Stats: 882 lines in 9 files changed: 487 ins; 351 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5793/head:pull/5793

PR: https://git.openjdk.java.net/jdk/pull/5793

From cverghese at openjdk.java.net  Fri Oct 29 23:58:08 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Fri, 29 Oct 2021 23:58:08 GMT
Subject: RFR: 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: <ekq_OsuOgTnn6fuKXdD1SRZQoctbwEB2vUOHkD-YzAs=.eafc1b10-08a2-4bb4-94a7-c6978248c4ae@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

Hi, I have update the PR with an alternate implementation. 

The updated benchmark results are 

New Benchmarks 

Benchmark                                         Mode  Cnt  Score   Error   Units
SSLStartHandshake.handshakeBenchmark             thrpt   25  0.241 ? 0.016  ops/ms
SSLStartHandshake.handshakeBenchmark              avgt   25  4.010 ? 0.224   ms/op
SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.642 ? 0.021  ops/ms
SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.552 ? 0.058   ms/op


Old Benchmarks

Benchmark                                         Mode  Cnt  Score   Error   Units
SSLStartHandshake.handshakeBenchmark             thrpt   25  0.229 ? 0.010  ops/ms
SSLStartHandshake.handshakeBenchmark              avgt   25  4.375 ? 0.283   ms/op
SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.621 ? 0.035  ops/ms
SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.830 ? 0.406   ms/op


This new implementation uses a cache in the HandshakeContext class. 

Looking forward for you feedback.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793

From xuelei at openjdk.java.net  Sat Oct 30 05:02:10 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 30 Oct 2021 05:02:10 GMT
Subject: RFR: 8274308: Improve efficiency for HandshakeContext
 initialization. [v2]
In-Reply-To: <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
References: <YzMZ2222rLyq28VRkoDiy2MoPf9OmM4tt6Upop0BjnM=.4d1596f7-682f-4f1b-bc6c-8b90819992b1@github.com>
 <K2RAXB3dTj8C8CHyZmsEYel_0Obz2rrOTlc_KZrYpck=.4f16a781-ae7d-4273-a0d9-c6e9a94200b0@github.com>
Message-ID: <ux2qOe79gPq5OJDfKyIj14chiobLYbHRk4r1VCtgbsM=.60ec55a5-9f11-468f-a30b-1cf25f8ae820@github.com>

On Fri, 29 Oct 2021 23:58:06 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
>
> Clive Verghese 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 three new commits since the last revision:
> 
>  - 8274308: Improve efficiency for HandshakeContext initialization
>  - Add SSLEngineBenchmark
>  - Benchmark

src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 74:

> 72:                     "sun.security.ssl.allowLegacyHelloMessages", true);
> 73: 
> 74:     static Cache<Double, HandshakeContextCacheItem> handshakeContextCache;

I think I understand the motivation, but a mutable cache in handshake context does not sound like the right direction.  A cache could impact the performance more and occupy additional memories , because we have to synchronizing the access to the cache.  Maybe, you could to benchmark the maximum operations allowed per seconds, and try to use more complex cases, and see what the result could be.

I did not yet try to find an improvement yet.  But at this moment, the idea to me is to thinking about the TLS user cases.  It is common that applications use one instance of SSLContext and default configurations.  From the SSLContext instance, with the default configuration, the connections get established.  Normally, we don't recommend to set protocols and cipher suites other than the default SSLContex configuration, because it is not algorithm aglity.  So, it may be a direction to have the default and final active protocols and cipher suites, parsed and cached in SSLContext.  Just for your reference if you want a further improvement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793