From valeriep at openjdk.java.net  Wed Sep  1 02:32:48 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 1 Sep 2021 02:32:48 GMT
Subject: RFR: 8271745: Correct block size for KW,
 KWP mode and use fixed IV for KWP mode for SunJCE
In-Reply-To: <Ze9vXlHqp2s1gTGk9ph28Q9DGcN3bHBZKbn2pLZ93o8=.f3d2c67c-ea23-4147-8a41-86b431bbb10d@github.com>
References: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
 <pCAujmFqEujAmPMRHVY7NSzUCBKN_9uIH8puZU52_7w=.b71285b8-61ff-4012-b258-0fbe89b3e2bf@github.com>
 <HSFFfcR0iHP77wWCohMVcagNcSGyWjlf4x8pmrWTz7o=.6960f24e-b133-431d-b9dc-f2bc38fedb82@github.com>
 <Ze9vXlHqp2s1gTGk9ph28Q9DGcN3bHBZKbn2pLZ93o8=.f3d2c67c-ea23-4147-8a41-86b431bbb10d@github.com>
Message-ID: <8xchw-AoZ6_1aieJ_VTn95ame9kfetgkotDb8pSPmoM=.e56daf9f-9345-4fda-92ad-3bd19c0bf16b@github.com>

On Tue, 31 Aug 2021 12:05:48 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Line 186 is correct in that the underlying Cipher block size must be 128-bit. However, the KW/KWP processing affected the input size requirement into 8-byte blocks, thus the overall cipher block size is now 8 instead of 16 bytes.
>
> So the block size is always 8 even when there is no padding?

Yes, with KW (no pad), data must be in multiples of 8. When data does not meet this size requirement, an external padding scheme such as PKCS5/7 padding is needed to pad the data to multiples of 8 in order for KW mode to process the data.
As for KWP mode, it internally pads the data to multiples of 8 before starting the internal processing. Thus, no external padding is needed. Are you asking if 8 should be returned for KWP mode due to its internal padding? KWP is like a variant of KW, so it seems to me that it should return the same block size as KW.

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

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

From jnimeh at openjdk.java.net  Wed Sep  1 04:26:03 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 1 Sep 2021 04:26:03 GMT
Subject: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1,
 n-1] for SunEC provider
Message-ID: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>

This fix adds an EC private key range check for the scalar value to be within the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA Signature algorithms and ECDH KeyAgreement algorithms.  While the SunEC KeyGenerator for EC keys will not generate private keys that sit outside the accepted range, it is possible to create and attempt to use ECPrivateKey objects that violate this range through a KeyFactory.

JBS: https://bugs.openjdk.java.net/browse/JDK-8272385

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

Commit messages:
 - Merge
 - 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider

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

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

From mullan at openjdk.java.net  Wed Sep  1 12:23:49 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 1 Sep 2021 12:23:49 GMT
Subject: RFR: 8271745: Correct block size for KW,
 KWP mode and use fixed IV for KWP mode for SunJCE
In-Reply-To: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
References: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
Message-ID: <vjTcgPBsqexLr_pUooc7Au82hgwp_Srokk4FkCqB3q8=.8080dd27-07d8-42bb-a59d-dd524f3fd265@github.com>

On Tue, 24 Aug 2021 01:33:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this straight forward change? During the interoperability testing with PKCS11 KW/KWP support, it is noticed that SunJCE provider used the wrong block size (AES: 16) when padding is needed for KW mode. With KW, KWP modes, data block size is multiples of 8-byte, so the padding should pad data to multiples of 8 bytes instead of 16. In addition, although PKCS#11 v3.0 states the IV for KWP mode is 4-byte, NSS's implementation would silently ignore the specified IVs. Thus, for max interoperability, it seems safer to change SunJCE provider to always use the same default IV and disallow custom IVs for KWP mode, at least for now. Regression test is enhanced to test more scenarios.
> 
> Thanks,
> Valerie

Marked as reviewed by mullan (Reviewer).

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

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

From mullan at openjdk.java.net  Wed Sep  1 12:23:49 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 1 Sep 2021 12:23:49 GMT
Subject: RFR: 8271745: Correct block size for KW,
 KWP mode and use fixed IV for KWP mode for SunJCE
In-Reply-To: <8xchw-AoZ6_1aieJ_VTn95ame9kfetgkotDb8pSPmoM=.e56daf9f-9345-4fda-92ad-3bd19c0bf16b@github.com>
References: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
 <pCAujmFqEujAmPMRHVY7NSzUCBKN_9uIH8puZU52_7w=.b71285b8-61ff-4012-b258-0fbe89b3e2bf@github.com>
 <HSFFfcR0iHP77wWCohMVcagNcSGyWjlf4x8pmrWTz7o=.6960f24e-b133-431d-b9dc-f2bc38fedb82@github.com>
 <Ze9vXlHqp2s1gTGk9ph28Q9DGcN3bHBZKbn2pLZ93o8=.f3d2c67c-ea23-4147-8a41-86b431bbb10d@github.com>
 <8xchw-AoZ6_1aieJ_VTn95ame9kfetgkotDb8pSPmoM=.e56daf9f-9345-4fda-92ad-3bd19c0bf16b@github.com>
Message-ID: <_SAHKwsbNl_MzMIOv2admqNg-Gjes42SYceZITqFK6M=.f6c79864-6a1d-4bc1-a5f1-6ed4bf165809@github.com>

On Wed, 1 Sep 2021 02:29:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> So the block size is always 8 even when there is no padding?
>
> Yes, with KW (no pad), data must be in multiples of 8. When data does not meet this size requirement, an external padding scheme such as PKCS5/7 padding is needed to pad the data to multiples of 8 in order for KW mode to process the data.
> As for KWP mode, it internally pads the data to multiples of 8 before starting the internal processing. Thus, no external padding is needed. Are you asking if 8 should be returned for KWP mode due to its internal padding? KWP is like a variant of KW, so it seems to me that it should return the same block size as KW.

Your explanation make sense. I just wanted to make sure we didn't miss something.

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

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

From weijun at openjdk.java.net  Wed Sep  1 15:17:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 1 Sep 2021 15:17:50 GMT
Subject: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1,
 n-1] for SunEC provider
In-Reply-To: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
References: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
Message-ID: <Ri3paxIAhFesx8zyv7DpldHJv3UJNJdDl1y1_23VZS8=.2acb1fe9-92cf-40c8-ace2-de686954e60d@github.com>

On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix adds an EC private key range check for the scalar value to be within the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA Signature algorithms and ECDH KeyAgreement algorithms.  While the SunEC KeyGenerator for EC keys will not generate private keys that sit outside the accepted range, it is possible to create and attempt to use ECPrivateKey objects that violate this range through a KeyFactory.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8272385

So the key is only validated before it's used? Why not when creating it?

Do we need to validate public key as well? It might not be a problem since modular calculation should scale it back to normal. Our old native impl does have one at https://github.com/openjdk/jdk11u-dev/blob/master/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c#L481.

One more thing: I would prefer `[1, n)` or `(0, n)` in the bug title. :-)

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

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

From jdoyle at iso-ne.com  Wed Sep  1 15:48:47 2021
From: jdoyle at iso-ne.com (Doyle, James)
Date: Wed, 1 Sep 2021 15:48:47 +0000
Subject: JEP 411 - use cases
Message-ID: <6387f90155744d7aae2e208d076994cb@iso-ne.com>

Hi,

Earlier this summer, our organization became aware of JEP-411 and the plan to remove Security Manager in the future, and I'd like to add our perspective to the use case / adoption aspect.

We deploy and manage a number of server-side Java applications, both developed in-house and from vendors, and currently use Java Security Manager to provide an extra layer of security around the server application code.  Enabling Security Manager in the server application JVM provides an additional means to defend against malicious users/clients exploiting vulnerabilities (in our application code or third-party code) to access the host OS in ways the individual JVM and application are not intended to act.  The fine-grained permission model is very useful for giving the application code the least privilege needed for its specific function.  The permissions give us a way to use a deny-by-default model and require a whitelist of the files, directories, hosts, ports, URLs, etc. that each application actually needs.  Our organization operates under compliance oversight, and the Security Manager policy for our applications provides one of the controls we use to insure a secure environment.  We're worried about the impact to these controls should Security Manager be removed.

Is the low adoption rate cited in the JEP ("After decades of maintaining the Security Manager but seeing very little usage...") anecdotal, or has it been measured somehow as part of proposing and implementing the JEP?  What qualifies as "low" or "little"?

Is the use case above one that the OpenJDK team is considering, to make sure workable alternatives are available before removing Security Manager?

Some of our Security Manager usage is via Java EE / Jakarta EE Security Manager permissions, and within that set, some apps specifically use WildFly Security Manager.  Will the removal of Security Manager from OpenJDK make related implementations like WildFly Security Manager impossible to maintain as-is?  Will the removal of Security Manager make users dependent on vendor-specific implementations like WildFly Security Manager and unable to freely move between Java EE / Jakarta EE implementations?

Thanks for your time.

Sincerely,
Jim Doyle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210901/cd58d4f1/attachment-0001.htm>

From jnimeh at openjdk.java.net  Wed Sep  1 16:34:23 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 1 Sep 2021 16:34:23 GMT
Subject: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1,
 n-1] for SunEC provider
In-Reply-To: <Ri3paxIAhFesx8zyv7DpldHJv3UJNJdDl1y1_23VZS8=.2acb1fe9-92cf-40c8-ace2-de686954e60d@github.com>
References: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
 <Ri3paxIAhFesx8zyv7DpldHJv3UJNJdDl1y1_23VZS8=.2acb1fe9-92cf-40c8-ace2-de686954e60d@github.com>
Message-ID: <9izXNficZLXvbV99OhrjHM491j9yJK2RUD6AfIMFu50=.87f3bd4f-1085-477d-8351-abdd8a2e91e9@github.com>

On Wed, 1 Sep 2021 15:13:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> So the key is only validated before it's used? Why not when creating it?
> 
> Do we need to validate public key as well? It might not be a problem since modular calculation should scale it back to normal. Our old native impl does have one at https://github.com/openjdk/jdk11u-dev/blob/master/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c#L481.
> 
> One more thing: I would prefer `[1, n)` or `(0, n)` in the bug title, and, it's probably more efficient to call `sVal.compareTo(BigInteger.ZERO) <= 0` than `sVal.compareTo(BigInteger.ONE) < 0`.

Good questions.
WRT the KeyFactory, I looked not only at ours but also BC's and neither seems to put restrictions on ranges for an ECPrivateKey.  Given that behavior I thought for this change I'd leave KeyFactory alone.

Validating the public key might not be a bad idea.  I could come up with a Java-based version of what's in libsunec and update the test to cover that as well.

With respect to the synopsis, I'd prefer to leave it [1, n-1] because that's the notation used by FIPS 186-4, X9.62 and SEC 1.  But the BigInteger.compareTo I will change as you suggested.

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

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

From valeriep at openjdk.java.net  Wed Sep  1 17:11:33 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 1 Sep 2021 17:11:33 GMT
Subject: RFR: 8271745: Correct block size for KW,
 KWP mode and use fixed IV for KWP mode for SunJCE
In-Reply-To: <_SAHKwsbNl_MzMIOv2admqNg-Gjes42SYceZITqFK6M=.f6c79864-6a1d-4bc1-a5f1-6ed4bf165809@github.com>
References: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
 <pCAujmFqEujAmPMRHVY7NSzUCBKN_9uIH8puZU52_7w=.b71285b8-61ff-4012-b258-0fbe89b3e2bf@github.com>
 <HSFFfcR0iHP77wWCohMVcagNcSGyWjlf4x8pmrWTz7o=.6960f24e-b133-431d-b9dc-f2bc38fedb82@github.com>
 <Ze9vXlHqp2s1gTGk9ph28Q9DGcN3bHBZKbn2pLZ93o8=.f3d2c67c-ea23-4147-8a41-86b431bbb10d@github.com>
 <8xchw-AoZ6_1aieJ_VTn95ame9kfetgkotDb8pSPmoM=.e56daf9f-9345-4fda-92ad-3bd19c0bf16b@github.com>
 <_SAHKwsbNl_MzMIOv2admqNg-Gjes42SYceZITqFK6M=.f6c79864-6a1d-4bc1-a5f1-6ed4bf165809@github.com>
Message-ID: <Y8m5X2CU1SrZkO8eGknnXHGchnVzTg3oTHOiE1XqmEI=.d4a60369-0201-47e1-b3ce-4dd4a8e87065@github.com>

On Wed, 1 Sep 2021 12:20:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Yes, with KW (no pad), data must be in multiples of 8. When data does not meet this size requirement, an external padding scheme such as PKCS5/7 padding is needed to pad the data to multiples of 8 in order for KW mode to process the data.
>> As for KWP mode, it internally pads the data to multiples of 8 before starting the internal processing. Thus, no external padding is needed. Are you asking if 8 should be returned for KWP mode due to its internal padding? KWP is like a variant of KW, so it seems to me that it should return the same block size as KW.
>
> Your explanation make sense. I just wanted to make sure we didn't miss something.

Yes, thanks for checking.

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

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

From sean.mullan at oracle.com  Wed Sep  1 19:03:22 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 1 Sep 2021 15:03:22 -0400
Subject: JEP 411 - use cases
In-Reply-To: <6387f90155744d7aae2e208d076994cb@iso-ne.com>
References: <6387f90155744d7aae2e208d076994cb@iso-ne.com>
Message-ID: <076900c6-5141-a3ca-6f3d-88416f84b83d@oracle.com>

Hi James,

On 9/1/21 11:48 AM, Doyle, James wrote:
> Hi,
> 
> Earlier this summer, our organization became aware of JEP-411 and the 
> plan to remove Security Manager in the future, and I?d like to add our 
> perspective to the use case / adoption aspect.
> 
> We deploy and manage a number of server-side Java applications, both 
> developed in-house and from vendors, and currently use Java Security 
> Manager to provide an extra layer of security around the server 
> application code.? Enabling Security Manager in the server application 
> JVM provides an additional means to defend against malicious 
> users/clients exploiting vulnerabilities (in our application code or 
> third-party code) to access the host OS in ways the individual JVM and 
> application are not intended to act.? The fine-grained permission model 
> is very useful for giving the application code the least privilege 
> needed for its specific function.? The permissions give us a way to use 
> a deny-by-default model and require a whitelist of the files, 
> directories, hosts, ports, URLs, etc. that each application actually 
> needs.? Our organization operates under compliance oversight, and the 
> Security Manager policy for our applications provides one of the 
> controls we use to insure a secure environment.? We?re worried about the 
> impact to these controls should Security Manager be removed.
> 
> Is the low adoption rate cited in the JEP (?After decades of maintaining 
> the Security Manager but seeing very little usage??) anecdotal, or has 
> it been measured somehow as part of proposing and implementing the JEP?  
> What qualifies as ?low? or ?little??

This is based on various pieces of data accumulated over the years such 
as incoming bug reports, surveys, external papers/studies of the SM, 
source code repositories, product searches, difficulties using the SM, 
declining usage on the client, etc.

> Is the use case above one that the OpenJDK team is considering, to make 
> sure workable alternatives are available before removing Security Manager?

As described in the Futures section of the JEP, we are looking at some 
alternatives for certain use cases. One of those is to potentially add a 
mechanism that allows applications to monitor and optionally block 
certain operations. The common use case listed in the JEP is blocking 
System.exit, but some others have requested being able to monitor and/or 
block file/network access. These and other alternatives need more 
discussion, but this is the list where it will be discussed.

> Some of our Security Manager usage is via Java EE / Jakarta EE Security 
> Manager permissions, and within that set, some apps specifically use 
> WildFly Security Manager.? Will the removal of Security Manager from 
> OpenJDK make related implementations like WildFly Security Manager 
> impossible to maintain as-is?? Will the removal of Security Manager make 
> users dependent on vendor-specific implementations like WildFly Security 
> Manager and unable to freely move between Java EE / Jakarta EE 
> implementations?

This is probably a question that is best answered by those that work on 
or support WildFly.

--Sean

From ascarpino at openjdk.java.net  Wed Sep  1 19:56:32 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 1 Sep 2021 19:56:32 GMT
Subject: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1,
 n-1] for SunEC provider
In-Reply-To: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
References: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
Message-ID: <vhjDG1tIAxg6q3VBIPPo9PtsBxVOF3LakvGZ0pQBGUo=.15926f90-47af-4513-9bc1-7413d27f55ab@github.com>

On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix adds an EC private key range check for the scalar value to be within the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA Signature algorithms and ECDH KeyAgreement algorithms.  While the SunEC KeyGenerator for EC keys will not generate private keys that sit outside the accepted range, it is possible to create and attempt to use ECPrivateKey objects that violate this range through a KeyFactory.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8272385

Looks good to me

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

Marked as reviewed by ascarpino (Reviewer).

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

From weijun at openjdk.java.net  Wed Sep  1 21:54:29 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 1 Sep 2021 21:54:29 GMT
Subject: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1,
 n-1] for SunEC provider
In-Reply-To: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
References: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
Message-ID: <TKld6UH_YuYWqyOjuoTi2WDpLtbeTwTk2JrQG23f6zs=.db811808-34d1-4583-87f2-beb2fa1ff67d@github.com>

On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix adds an EC private key range check for the scalar value to be within the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA Signature algorithms and ECDH KeyAgreement algorithms.  While the SunEC KeyGenerator for EC keys will not generate private keys that sit outside the accepted range, it is possible to create and attempt to use ECPrivateKey objects that violate this range through a KeyFactory.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8272385

Looks fine. One nit: how about let `checkPrivateKey` returning the key like `Objects.requireNonNull()` does?

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

Marked as reviewed by weijun (Reviewer).

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

From valeriep at openjdk.java.net  Wed Sep  1 22:20:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 1 Sep 2021 22:20:38 GMT
Subject: Integrated: 8271745: Correct block size for KW,
 KWP mode and use fixed IV for KWP mode for SunJCE
In-Reply-To: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
References: <JWsNLfFhgYSpevDn2_Suyo7Sy8iHnCcflKG3iFgyPEs=.e8031f44-24ef-49ee-af9e-bfa0e2d90e1e@github.com>
Message-ID: <ZE_YV1mGD1qNK2Kd2euAYGFHg0LFSj_lqrYCYDJ7I80=.97704f7f-6f1b-4023-88a6-92ec47ef571b@github.com>

On Tue, 24 Aug 2021 01:33:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this straight forward change? During the interoperability testing with PKCS11 KW/KWP support, it is noticed that SunJCE provider used the wrong block size (AES: 16) when padding is needed for KW mode. With KW, KWP modes, data block size is multiples of 8-byte, so the padding should pad data to multiples of 8 bytes instead of 16. In addition, although PKCS#11 v3.0 states the IV for KWP mode is 4-byte, NSS's implementation would silently ignore the specified IVs. Thus, for max interoperability, it seems safer to change SunJCE provider to always use the same default IV and disallow custom IVs for KWP mode, at least for now. Regression test is enhanced to test more scenarios.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 1a5a2b6b
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a5a2b6b15e22b21343244e3a2b649d00eef5ffa
Stats:     248 lines in 3 files changed: 98 ins; 35 del; 115 mod

8271745: Correct block size for KW,KWP mode and use fixed IV for KWP mode for SunJCE

Reviewed-by: xuelei, mullan

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  2 07:07:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 2 Sep 2021 07:07:43 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for
 in java.base
Message-ID: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>

There are few places in code where manual while loop is used with Iterator to iterate over Collection.
Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.

Similar cleanups:
* https://bugs.openjdk.java.net/browse/JDK-8258006
* https://bugs.openjdk.java.net/browse/JDK-8257912

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

Commit messages:
 - [PATCH] Replace while cycles with iterator with enhanced-for in java.base

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  2 07:07:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 2 Sep 2021 07:07:43 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <IluMSbOZNUOxK2MNOxRnj6VRv_H-ak5vmrWwnrbjOy8=.bc931e12-b030-4869-9946-bda17baac93e@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

Tested "tier2" on linux-x86_64-server-fastdebug Ubuntu 21.04

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/jdk:tier2                               3772  3771     1     0 <<
   jtreg:test/langtools:tier2                           11    11     0     0   
   jtreg:test/jaxp:tier2                               452   452     0     0   
==============================
TEST FAILURE

Only one test `java/nio/file/FileStore/Basic.java` failed, but it fails without my changes too.

----------System.out:(46/2591)----------

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

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

From serb at openjdk.java.net  Thu Sep  2 08:20:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Sep 2021 08:20:53 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging
Message-ID: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>

The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.

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.

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

Commit messages:
 - Some tests deleted
 - Update the RootLevelInConfigFile test
 - Initial version of JDK-8273101

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

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

From dfuchs at openjdk.java.net  Thu Sep  2 09:41:30 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 2 Sep 2021 09:41:30 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <aceK2KREj0o8vTnFgzms-wU-sLASvg38VQOhdXUj3jY=.3d6974d5-078e-48f0-afdc-5f4a568df581@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

Generally this looks like a good improvement as the resulting code becomes more readable.
Changes in sun/net or jar index classes look fine. Please obtain approval from maintainers of the other areas before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

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

From rriggs at openjdk.java.net  Thu Sep  2 13:30:29 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Sep 2021 13:30:29 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <ywJUC0MJhT3kE26Ld8FqbJsWMF6grnzV1Il0Won6lGQ=.9495c7f3-145b-437d-99e1-bb5b44551a77@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

LGTM

For the security related code a second reviewer would be good.

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

Marked as reviewed by rriggs (Reviewer).

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

From fguallini at openjdk.java.net  Thu Sep  2 13:41:40 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 2 Sep 2021 13:41:40 GMT
Subject: RFR: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is
 skipped
Message-ID: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>

This trivial change fixes the case 2 in test sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method testKeySpec is expecting a class object of type KeySpec as second argument in order to be reusable for multiple test scenarios, but then instead of using that argument the RSAPrivateKeySpec.class is hardcoded:


private static void testKeySpec(KeyFactory factory, PrivateKey key, Class<? extends KeySpec> specClass) throws Exception {
        try {
            KeySpec spec = factory.getKeySpec(key, RSAPrivateKeySpec.class);


it should be:

`KeySpec spec = factory.getKeySpec(key, specClass);
`

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

Commit messages:
 - use param specClass

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

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

From jdoyle at iso-ne.com  Thu Sep  2 13:42:32 2021
From: jdoyle at iso-ne.com (Doyle, James)
Date: Thu, 2 Sep 2021 13:42:32 +0000
Subject: [EXT] security-dev Digest, Vol 171, Issue 3
In-Reply-To: <mailman.4133.1630533344.4010.security-dev@openjdk.java.net>
References: <mailman.4133.1630533344.4010.security-dev@openjdk.java.net>
Message-ID: <411270a18f8a4bcf8f714d758bdc1e5d@iso-ne.com>

Hi Sean,

Thanks for your response!

I re-checked the "Future Work" section of https://openjdk.java.net/jeps/411 and see the "Monitoring access to resources" use case / enhancement you were referring to.

The enhancement as worded focuses on monitoring the operations and seems ambiguous about whether blocking the operations is in scope ("while not necessarily restricting these operations").  Can I suggest updating the wording a little to be clearer that having the ability to block the operations is part of that use case?  

Also, one of the things that's been helpful with Security Manager permission-based policies today, is the ability to base decisions about those operations on a whitelist of what's allowed for a given application, and that the resources in that whitelist can be fine-grained (specific DNS names, file paths, ports, etc).  Could that aspect be captured in the wording of that use case?  In other words, a feature for monitoring and blocking operations would be helpful if it could act not just as a blacklist of forbidden operations, but a whitelist of allowed operations and resources at a fine-grained level.

Thanks,
Jim Doyle

-----Original Message-----

Date: Wed, 1 Sep 2021 15:03:22 -0400
From: Sean Mullan <sean.mullan at oracle.com>
To: security-dev at openjdk.java.net
Subject: Re: JEP 411 - use cases
Message-ID: <076900c6-5141-a3ca-6f3d-88416f84b83d at oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi James,

On 9/1/21 11:48 AM, Doyle, James wrote:
> Hi,
>
> Earlier this summer, our organization became aware of JEP-411 and the 
> plan to remove Security Manager in the future, and I?d like to add our 
> perspective to the use case / adoption aspect.
>
> We deploy and manage a number of server-side Java applications, both 
> developed in-house and from vendors, and currently use Java Security 
> Manager to provide an extra layer of security around the server 
> application code.? Enabling Security Manager in the server application 
> JVM provides an additional means to defend against malicious 
> users/clients exploiting vulnerabilities (in our application code or 
> third-party code) to access the host OS in ways the individual JVM and 
> application are not intended to act.? The fine-grained permission 
> model is very useful for giving the application code the least 
> privilege needed for its specific function.? The permissions give us a 
> way to use a deny-by-default model and require a whitelist of the 
> files, directories, hosts, ports, URLs, etc. that each application 
> actually needs.? Our organization operates under compliance oversight, 
> and the Security Manager policy for our applications provides one of 
> the controls we use to insure a secure environment.? We?re worried 
> about the impact to these controls should Security Manager be removed.
>
> Is the low adoption rate cited in the JEP (?After decades of 
> maintaining the Security Manager but seeing very little usage??) 
> anecdotal, or has it been measured somehow as part of proposing and implementing the JEP?
> What qualifies as ?low? or ?little??

This is based on various pieces of data accumulated over the years such as incoming bug reports, surveys, external papers/studies of the SM, source code repositories, product searches, difficulties using the SM, declining usage on the client, etc.

> Is the use case above one that the OpenJDK team is considering, to 
> make sure workable alternatives are available before removing Security Manager?

As described in the Futures section of the JEP, we are looking at some alternatives for certain use cases. One of those is to potentially add a mechanism that allows applications to monitor and optionally block certain operations. The common use case listed in the JEP is blocking System.exit, but some others have requested being able to monitor and/or block file/network access. These and other alternatives need more discussion, but this is the list where it will be discussed.

> Some of our Security Manager usage is via Java EE / Jakarta EE 
> Security Manager permissions, and within that set, some apps 
> specifically use WildFly Security Manager.? Will the removal of 
> Security Manager from OpenJDK make related implementations like 
> WildFly Security Manager impossible to maintain as-is?? Will the 
> removal of Security Manager make users dependent on vendor-specific 
> implementations like WildFly Security Manager and unable to freely 
> move between Java EE / Jakarta EE implementations?

This is probably a question that is best answered by those that work on or support WildFly.

--Sean


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


From iris at openjdk.java.net  Thu Sep  2 14:57:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 2 Sep 2021 14:57:06 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <2L0IWm1_kLMzLLdlB6vKuWNAe0qXPQ-2rHnFBkvwe98=.f12300b3-646b-4c67-a17b-f69d55155b21@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

Marked as reviewed by iris (Reviewer).

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

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

From jnimeh at openjdk.java.net  Thu Sep  2 17:26:16 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 2 Sep 2021 17:26:16 GMT
Subject: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1,
 n-1] for SunEC provider [v2]
In-Reply-To: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
References: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
Message-ID: <y2u3o8j7KFgzxnavtdawY3eggVI_1caLzsNOMSjEkwQ=.6efd796b-79cb-468b-b034-d06486486148@github.com>

> This fix adds an EC private key range check for the scalar value to be within the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA Signature algorithms and ECDH KeyAgreement algorithms.  While the SunEC KeyGenerator for EC keys will not generate private keys that sit outside the accepted range, it is possible to create and attempt to use ECPrivateKey objects that violate this range through a KeyFactory.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8272385

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

  change checkPrivateKey signature to return ECPrivateKey instead of void

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5324/files
  - new: https://git.openjdk.java.net/jdk/pull/5324/files/864b9aaf..15696f21

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

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

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

From jnimeh at openjdk.java.net  Thu Sep  2 17:57:33 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 2 Sep 2021 17:57:33 GMT
Subject: Integrated: 8272385: Enforce ECPrivateKey d value to be in the range
 [1, n-1] for SunEC provider
In-Reply-To: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
References: <kPfW1Ub4T3ADvuJBI3fGpuZcjTX-yFdxaBHZ4N-dxY8=.042c85c7-f967-4262-a128-5158314e376f@github.com>
Message-ID: <Hg9Pcc3h4C5xm4ZGsb9Z3E39BWMZdX2UfkplAfQPmeI=.fb0fe332-e86a-47b2-91d5-244496cfc8a0@github.com>

On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix adds an EC private key range check for the scalar value to be within the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA Signature algorithms and ECDH KeyAgreement algorithms.  While the SunEC KeyGenerator for EC keys will not generate private keys that sit outside the accepted range, it is possible to create and attempt to use ECPrivateKey objects that violate this range through a KeyFactory.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8272385

This pull request has now been integrated.

Changeset: 29e0f138
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29e0f1386d247731e8733f6fdd1307642b2b9f96
Stats:     148 lines in 4 files changed: 147 ins; 0 del; 1 mod

8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider

Reviewed-by: ascarpino, weijun

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  2 18:58:49 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 2 Sep 2021 18:58:49 GMT
Subject: RFR: 8273299: Unnecessary Vector usage in java.security.jgss
Message-ID: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>

Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.

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

Commit messages:
 - [PATCH] Unnecessary Vector usage in java.security.jgss

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  2 18:58:50 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 2 Sep 2021 18:58:50 GMT
Subject: RFR: 8273299: Unnecessary Vector usage in java.security.jgss
In-Reply-To: <DMaevKvXPZ7hsTkfi1MIK3ZuHWu7plUfjPfF7SlP61M=.a7787910-cd3d-4fea-8549-770769b88819@github.com>
References: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>
 <DMaevKvXPZ7hsTkfi1MIK3ZuHWu7plUfjPfF7SlP61M=.a7787910-cd3d-4fea-8549-770769b88819@github.com>
Message-ID: <EMUNYZNhFdusvuiNNDyfnC50C_7R9__pCJOS7B5N3dI=.3f7382a9-4bfb-4f2a-92f5-5c3f9c537c08@github.com>

On Thu, 26 Aug 2021 15:50:42 GMT, Yasser Bazzi <github.com+32601969+YShow at openjdk.org> wrote:

>> Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java line 574:
> 
>> 572:             v.add(st.nextToken());
>> 573:         }
>> 574:         final String[] command = new String[v.size()];
> 
> Could probably simplify most of these .toArray to simply `var variable = myarraylist.toArray(new ArrayType[0])`

I think it's better to leave it to separate cleanup issue.

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

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

From github.com+32601969+yshow at openjdk.java.net  Thu Sep  2 18:58:49 2021
From: github.com+32601969+yshow at openjdk.java.net (Yasser Bazzi)
Date: Thu, 2 Sep 2021 18:58:49 GMT
Subject: RFR: 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: <DMaevKvXPZ7hsTkfi1MIK3ZuHWu7plUfjPfF7SlP61M=.a7787910-cd3d-4fea-8549-770769b88819@github.com>

On Thu, 26 Aug 2021 08:09:16 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.

src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java line 574:

> 572:             v.add(st.nextToken());
> 573:         }
> 574:         final String[] command = new String[v.size()];

Could probably simplify most of these .toArray to simply `var variable = myarraylist.toArray(new ArrayType[0])`

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

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

From sean.mullan at oracle.com  Thu Sep  2 19:48:04 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 2 Sep 2021 15:48:04 -0400
Subject: [EXT] security-dev Digest, Vol 171, Issue 3
In-Reply-To: <411270a18f8a4bcf8f714d758bdc1e5d@iso-ne.com>
References: <mailman.4133.1630533344.4010.security-dev@openjdk.java.net>
 <411270a18f8a4bcf8f714d758bdc1e5d@iso-ne.com>
Message-ID: <0f3c6faa-3274-092a-f0e9-1ed70054f54d@oracle.com>



On 9/2/21 9:42 AM, Doyle, James wrote:
> Hi Sean,
> 
> Thanks for your response!
> 
> I re-checked the "Future Work" section of https://openjdk.java.net/jeps/411 and see the "Monitoring access to resources" use case / enhancement you were referring to.
> 
> The enhancement as worded focuses on monitoring the operations and seems ambiguous about whether blocking the operations is in scope ("while not necessarily restricting these operations").  Can I suggest updating the wording a little to be clearer that having the ability to block the operations is part of that use case?

Good point, although JFR is really a better solution for monitoring. In 
recent releases, we have added more security-specific events to JFR 
which help monitor TLS connections, certificates, deserialization, etc 
so we should continue to explore this area more to see if it can provide 
more security events, such as network/file access, etc.

So I would like to leave that one as-is. The "Blocking System::exit" 
bullet should be expanded to potentially include other operations such 
as file/network access.

> 
> Also, one of the things that's been helpful with Security Manager permission-based policies today, is the ability to base decisions about those operations on a whitelist of what's allowed for a given application, and that the resources in that whitelist can be fine-grained (specific DNS names, file paths, ports, etc).  Could that aspect be captured in the wording of that use case?  In other words, a feature for monitoring and blocking operations would be helpful if it could act not just as a blacklist of forbidden operations, but a whitelist of allowed operations and resources at a fine-grained level.

So one point that should be made clear is that we don't intend to 
replace the current Policy API and policy file implementation, etc. If 
we go down this route, it will be up to the application to decide if a 
particular operation should be blocked or not based on its own policies. 
The JDK will no longer be a Policy Decision Point.

--Sean

> 
> Thanks,
> Jim Doyle
> 
> -----Original Message-----
> 
> Date: Wed, 1 Sep 2021 15:03:22 -0400
> From: Sean Mullan <sean.mullan at oracle.com>
> To: security-dev at openjdk.java.net
> Subject: Re: JEP 411 - use cases
> Message-ID: <076900c6-5141-a3ca-6f3d-88416f84b83d at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi James,
> 
> On 9/1/21 11:48 AM, Doyle, James wrote:
>> Hi,
>>
>> Earlier this summer, our organization became aware of JEP-411 and the
>> plan to remove Security Manager in the future, and I?d like to add our
>> perspective to the use case / adoption aspect.
>>
>> We deploy and manage a number of server-side Java applications, both
>> developed in-house and from vendors, and currently use Java Security
>> Manager to provide an extra layer of security around the server
>> application code.? Enabling Security Manager in the server application
>> JVM provides an additional means to defend against malicious
>> users/clients exploiting vulnerabilities (in our application code or
>> third-party code) to access the host OS in ways the individual JVM and
>> application are not intended to act.? The fine-grained permission
>> model is very useful for giving the application code the least
>> privilege needed for its specific function.? The permissions give us a
>> way to use a deny-by-default model and require a whitelist of the
>> files, directories, hosts, ports, URLs, etc. that each application
>> actually needs.? Our organization operates under compliance oversight,
>> and the Security Manager policy for our applications provides one of
>> the controls we use to insure a secure environment.? We?re worried
>> about the impact to these controls should Security Manager be removed.
>>
>> Is the low adoption rate cited in the JEP (?After decades of
>> maintaining the Security Manager but seeing very little usage??)
>> anecdotal, or has it been measured somehow as part of proposing and implementing the JEP?
>> What qualifies as ?low? or ?little??
> 
> This is based on various pieces of data accumulated over the years such as incoming bug reports, surveys, external papers/studies of the SM, source code repositories, product searches, difficulties using the SM, declining usage on the client, etc.
> 
>> Is the use case above one that the OpenJDK team is considering, to
>> make sure workable alternatives are available before removing Security Manager?
> 
> As described in the Futures section of the JEP, we are looking at some alternatives for certain use cases. One of those is to potentially add a mechanism that allows applications to monitor and optionally block certain operations. The common use case listed in the JEP is blocking System.exit, but some others have requested being able to monitor and/or block file/network access. These and other alternatives need more discussion, but this is the list where it will be discussed.
> 
>> Some of our Security Manager usage is via Java EE / Jakarta EE
>> Security Manager permissions, and within that set, some apps
>> specifically use WildFly Security Manager.? Will the removal of
>> Security Manager from OpenJDK make related implementations like
>> WildFly Security Manager impossible to maintain as-is?? Will the
>> removal of Security Manager make users dependent on vendor-specific
>> implementations like WildFly Security Manager and unable to freely
>> move between Java EE / Jakarta EE implementations?
> 
> This is probably a question that is best answered by those that work on or support WildFly.
> 
> --Sean
> 
> 
> ------------------------------
> 

From serb at openjdk.java.net  Thu Sep  2 22:59:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Sep 2021 22:59:31 GMT
Subject: Integrated: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <tin2l2VOVGWktdXefgDZIBJz2kpyYBxoc4d9Tq2Qzdk=.f818542a-aba3-400c-9127-74516d3d0905@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

This pull request has now been integrated.

Changeset: 7fff22af
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987
Stats:     364 lines in 53 files changed: 98 ins; 128 del; 138 mod

8272805: Avoid looking up standard charsets

Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj

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

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

From mullan at openjdk.java.net  Fri Sep  3 13:38:27 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 3 Sep 2021 13:38:27 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <wEttvrpldJEBgaNJj7Z0tKhMTgG_QEuHb4GW62M6hTY=.9b9e3491-9be5-46ac-af82-d71048481f8d@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

The security related changes look fine to me.

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

Marked as reviewed by mullan (Reviewer).

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

From mullan at openjdk.java.net  Fri Sep  3 13:41:26 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 3 Sep 2021 13:41:26 GMT
Subject: RFR: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec
 is skipped
In-Reply-To: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>
References: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>
Message-ID: <GhSFgjNW4mENMBg3fBk7mxNyct-G0ECSHhTabp9Nv7A=.1406cf50-8502-44df-b502-22f6f294b34b@github.com>

On Thu, 2 Sep 2021 13:33:30 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This trivial change fixes the case 2 in test sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method testKeySpec is expecting a class object of type KeySpec as second argument in order to be reusable for multiple test scenarios, but then instead of using that argument the RSAPrivateKeySpec.class is hardcoded:
> 
> 
> private static void testKeySpec(KeyFactory factory, PrivateKey key, Class<? extends KeySpec> specClass) throws Exception {
>         try {
>             KeySpec spec = factory.getKeySpec(key, RSAPrivateKeySpec.class);
> 
> 
> it should be:
> 
> `KeySpec spec = factory.getKeySpec(key, specClass);
> `

Marked as reviewed by mullan (Reviewer).

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

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

From prr at openjdk.java.net  Fri Sep  3 16:18:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Sep 2021 16:18:24 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: <yZ38rN9EPs6q9q1oX6h9bj1TWSf7qhq9oLnkorBbRkk=.b29aaff0-62bb-4f13-a01e-85260df3723d@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> This is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

This fix requires coordinated closed changes so needs an Oracle sponsor.
And actually is probably better handled entirely by an Oracle engineer because pushes need to be very co-ordinated.

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

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

From prr at openjdk.java.net  Fri Sep  3 16:53:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Sep 2021 16:53:28 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: <t_Wdki21hUmv1EeYxui39r2wWf707dDxMOfi22dNmhE=.f430e31c-522f-427c-8775-edd1883ed8bd@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> 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.

I believe we should have a CSR for this. It removes a long standing capability in the platform that was used by
components such as plugin and webstart.

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

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

From prr at openjdk.java.net  Fri Sep  3 17:22:27 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Sep 2021 17:22:27 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: <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> 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.

Hmm I was under the impression this was removing AppContext itself but it is just removing the backdoor needed by logging
Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ...

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

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

From prr at openjdk.java.net  Fri Sep  3 17:33:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Sep 2021 17:33:24 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: <6GaYNpoX8_A1olW1Ikfu03HdbhVbK7reFN0BdTnV77w=.1aecd2fc-ace8-4f91-9a2c-a08b05086fc0@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> 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.

@aivanov-jdk will help make sure the closed changes are pushed at exactly the same time as this gets pushed.

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

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

From serb at openjdk.java.net  Fri Sep  3 17:46:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Sep 2021 17:46:27 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>
Message-ID: <DM2kRZt4ehUbUCbEhWPLGAJAPZDuJ6vRsyUp2eIv6DY=.999aa5f0-04a7-481f-a0a3-837583944834@github.com>

On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ...

Even java.desktop does not support it fully, since for a couple of years nobody care about appcontext when write a new code.
Note that I mentioned the "threadgroup sandboxing" in the subject, which is not necessary implemented via Appcontext. The JavaBeans and JavaSound use the thread group directly, I plan to remove them as well.

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

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

From dfuchs at openjdk.java.net  Fri Sep  3 20:30:12 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 3 Sep 2021 20:30:12 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: <6tT-CF3Huqab-wBF2L_yzvaCw23pML3Oc2jFALEhWew=.306be274-9244-4050-b9be-d12542123c68@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> 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.

Right. I am also a bit uncomfortable about the inconsistency. That said - if everybody agrees that this should be done I have no objection. The changes to the java.util.logging implementation correspond to my expectation if this were to be carried through.

test/jdk/java/util/logging/TestLoggingWithMainAppContext.java line 1:

> 1: /*

Humm... There's no direct reference to AppContext here. Maybe this test should be preserved?

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

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

From duke at openjdk.java.net  Fri Sep  3 22:10:52 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 3 Sep 2021 22:10:52 GMT
Subject: Withdrawn: 8217408: Reduce storage of duplicate identifiers in TLS
 vectors in SunJSSE
In-Reply-To: <MeAI7FVKZIeAR6OhHpR_wfuki1_ywHuWbtgfuSijG1E=.870db436-185f-4318-b370-4e6c2c9ed031@github.com>
References: <MeAI7FVKZIeAR6OhHpR_wfuki1_ywHuWbtgfuSijG1E=.870db436-185f-4318-b370-4e6c2c9ed031@github.com>
Message-ID: <UsokmNIoasU6bPB3ZaXl_niLTvNbMS4d1NUzk5MUYPk=.f2fc237c-eafc-4927-b67f-d1fb0ea6e78b@github.com>

On Wed, 23 Jun 2021 20:15:39 GMT, Jack Hartstein <github.com+44308314+jackh2000 at openjdk.org> wrote:

> 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE

This pull request has been closed without being integrated.

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

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

From serb at openjdk.java.net  Fri Sep  3 22:17:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Sep 2021 22:17:56 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <6tT-CF3Huqab-wBF2L_yzvaCw23pML3Oc2jFALEhWew=.306be274-9244-4050-b9be-d12542123c68@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <6tT-CF3Huqab-wBF2L_yzvaCw23pML3Oc2jFALEhWew=.306be274-9244-4050-b9be-d12542123c68@github.com>
Message-ID: <pZYBJD6C5DFNs9h9ON6BtRq4ZfJ-Ojdc39z0QZsYvHk=.d81cac4a-307a-4109-a848-245d01a724d1@github.com>

On Thu, 2 Sep 2021 09:59:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
>> 
>> 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.
>
> test/jdk/java/util/logging/TestLoggingWithMainAppContext.java line 1:
> 
>> 1: /*
> 
> Humm... There's no direct reference to AppContext here. Maybe this test should be preserved?

It uses it indirectly, the next line under security manager trigger creation of the appcontext:
`ImageIO.read(is); // triggers calls to system loggers & creation of main AppContext`

but I can preserve/rename it for sure.

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

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

From alanb at openjdk.java.net  Mon Sep  6 09:42:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Sep 2021 09:42:47 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: <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> 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.

No objection to removing this legacy/unused code but I think it would be useful to useful to have the JBS issue or the PR summary provide a bit more context. As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right?

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

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

From serb at openjdk.java.net  Mon Sep  6 20:39:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Sep 2021 20:39:43 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>
Message-ID: <OHntSJmFBMrLXA7OfvttlPSWhKYaT0yRVLdXYQHdSZs=.64067eb3-b66a-44f0-8eac-1e5d77bc884b@github.com>

On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right?

Yes, you are right.

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Tue Sep  7 03:42:59 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Tue, 7 Sep 2021 03:42:59 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath
Message-ID: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>

There is a bug for URLClassPath.findResources with JarIndex.
With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 

The PR includes:
1. remove the JarIndex support in URLClassPath
2. move JarIndex into  jdk.jartool module.

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

Commit messages:
 - 8273401: Remove JarIndex support in URLClassPath

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

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

From alanb at openjdk.java.net  Tue Sep  7 07:22:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Sep 2021 07:22:44 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath
In-Reply-To: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
Message-ID: <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>

On Tue, 7 Sep 2021 03:34:27 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
> 
> The PR includes:
> 1. remove the JarIndex support in URLClassPath
> 2. move JarIndex into  jdk.jartool module.

Thanks for taking this on. I've done a pass over the changes and it looks complete, just a few issues. Next step will be to create a CSR for this change.

src/java.base/share/classes/java/util/jar/JarFile.java line 220:

> 218:      * The index file name.
> 219:      */
> 220:     public static final String INDEX_NAME = "META-INF/INDEX.LIST";

Adding this as a public field means it becomes part of the API, so it shouldn't be public here.

src/java.base/share/classes/java/util/jar/JarVerifier.java line 147:

> 145: 
> 146:                 if (uname.equals(JarFile.MANIFEST_NAME) ||
> 147:                         uname.equals(JarFile.INDEX_NAME)) {

It would be useful if someone from security-libs could comment on this. The interaction between signed JAR and JAR index isn't very clear. The change you have is safe but it might be that we can drop the checking for INDEX.LIST here.

test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 44:

> 42: import sun.tools.jar.JarIndex;
> 43: 
> 44: public class JarIndexMergeTest {

Is this the one remaining test in sun/misc/JarIndex? I think it can be moved to test/jdk/java/util/jar. I think we should change the package name in the summary comment too.

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

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

From rhalade at openjdk.java.net  Tue Sep  7 14:36:38 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Tue, 7 Sep 2021 14:36:38 GMT
Subject: RFR: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec
 is skipped
In-Reply-To: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>
References: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>
Message-ID: <3ap59K4rvrrhom03Ujs_2l0SBjGZnVF5kF81vap6seU=.ac47fc52-e08d-47af-860a-e9cbc4120d1b@github.com>

On Thu, 2 Sep 2021 13:33:30 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This trivial change fixes the case 2 in test sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method testKeySpec is expecting a class object of type KeySpec as second argument in order to be reusable for multiple test scenarios, but then instead of using that argument the RSAPrivateKeySpec.class is hardcoded:
> 
> 
> private static void testKeySpec(KeyFactory factory, PrivateKey key, Class<? extends KeySpec> specClass) throws Exception {
>         try {
>             KeySpec spec = factory.getKeySpec(key, RSAPrivateKeySpec.class);
> 
> 
> it should be:
> 
> `KeySpec spec = factory.getKeySpec(key, specClass);
> `

Marked as reviewed by rhalade (Reviewer).

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

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

From fguallini at openjdk.java.net  Tue Sep  7 14:38:39 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Tue, 7 Sep 2021 14:38:39 GMT
Subject: Integrated: 8268558: [TESTBUG] Case 2 in
 TestP11KeyFactoryGetRSAKeySpec is skipped
In-Reply-To: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>
References: <kNp5WVutJZAAPvyVkY3DJM-eQuHS3h3HaYKIV0RzXRc=.a90fe804-991f-459b-be0b-a1e1d09d0fe0@github.com>
Message-ID: <0b1lfA9aMheLTvxtE3qymDRT3x_koqZ0kTvaDC6UGcc=.128aff17-036f-4d64-832e-3b23f96e49f5@github.com>

On Thu, 2 Sep 2021 13:33:30 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This trivial change fixes the case 2 in test sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method testKeySpec is expecting a class object of type KeySpec as second argument in order to be reusable for multiple test scenarios, but then instead of using that argument the RSAPrivateKeySpec.class is hardcoded:
> 
> 
> private static void testKeySpec(KeyFactory factory, PrivateKey key, Class<? extends KeySpec> specClass) throws Exception {
>         try {
>             KeySpec spec = factory.getKeySpec(key, RSAPrivateKeySpec.class);
> 
> 
> it should be:
> 
> `KeySpec spec = factory.getKeySpec(key, specClass);
> `

This pull request has now been integrated.

Changeset: 041ae20b
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/041ae20b10e11381415e8f61fd39e9e19aa8d4f2
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped

Reviewed-by: mullan, rhalade

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

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

From lancea at openjdk.java.net  Tue Sep  7 16:33:36 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 7 Sep 2021 16:33:36 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath
In-Reply-To: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
Message-ID: <YWyiF9H1kE5OABN2-IeriWtQ5d3Qn8EfnSzmT66sjfo=.7db9bae3-9008-48a1-83a5-01acdb1a0c57@github.com>

On Tue, 7 Sep 2021 03:34:27 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
> 
> The PR includes:
> 1. remove the JarIndex support in URLClassPath
> 2. move JarIndex into  jdk.jartool module.

I think this looks good overall.

Once you do your next set up updates, I will run it through mach5 for you

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73:

> 71: import static java.util.jar.JarFile.MANIFEST_NAME;
> 72: import static java.util.stream.Collectors.joining;
> 73: import static java.util.jar.JarFile.INDEX_NAME;

Maybe move this above the java.util.streamCollectors.joining import

Also, the copyright should probably be updated to 2021

test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Probably should update the copyright year to include 2021

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

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

From lancea at openjdk.java.net  Tue Sep  7 16:33:37 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 7 Sep 2021 16:33:37 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath
In-Reply-To: <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
Message-ID: <10Ivl80m4qzRju-gdlcN6t4CA11U2m-Ngn4U7PnMHnI=.d0d5cd3f-8e52-47a4-9b01-fbfae7c70387@github.com>

On Tue, 7 Sep 2021 07:03:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
>> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
>> 
>> The PR includes:
>> 1. remove the JarIndex support in URLClassPath
>> 2. move JarIndex into  jdk.jartool module.
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 220:
> 
>> 218:      * The index file name.
>> 219:      */
>> 220:     public static final String INDEX_NAME = "META-INF/INDEX.LIST";
> 
> Adding this as a public field means it becomes part of the API, so it shouldn't be public here.

Agree

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

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

From mullan at openjdk.java.net  Tue Sep  7 17:42:36 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 7 Sep 2021 17:42:36 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath
In-Reply-To: <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
Message-ID: <7BzvoN6dbVscgZKB3U3epUjjJ_os26_P5pYPH_rysE8=.c1e499b0-dd77-41fd-b044-76942c0f33cb@github.com>

On Tue, 7 Sep 2021 07:12:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
>> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
>> 
>> The PR includes:
>> 1. remove the JarIndex support in URLClassPath
>> 2. move JarIndex into  jdk.jartool module.
>
> src/java.base/share/classes/java/util/jar/JarVerifier.java line 147:
> 
>> 145: 
>> 146:                 if (uname.equals(JarFile.MANIFEST_NAME) ||
>> 147:                         uname.equals(JarFile.INDEX_NAME)) {
> 
> It would be useful if someone from security-libs could comment on this. The interaction between signed JAR and JAR index isn't very clear. The change you have is safe but it might be that we can drop the checking for INDEX.LIST here.

I am thinking this line should not be removed for compatibility with existing JARs that have indexes.

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

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

From valeriep at openjdk.java.net  Tue Sep  7 23:39:11 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 7 Sep 2021 23:39:11 GMT
Subject: RFR: 8246797: A convenient method to read OPTIONAL element [v3]
In-Reply-To: <_cHLOZ1u7re_7AUEkVhYCPsRRf72EPjNm9SSL-3jIek=.a9158dfe-92df-46f8-a872-c60c845ce5ea@github.com>
References: <t1MsF59wViD4BecgbHTIuiJlEqhO__mZGroPab5aPxU=.459bfdaa-ffa0-4169-af82-b932c09dff0c@github.com>
 <_cHLOZ1u7re_7AUEkVhYCPsRRf72EPjNm9SSL-3jIek=.a9158dfe-92df-46f8-a872-c60c845ce5ea@github.com>
Message-ID: <Y6W2XBoZ-V5pkITJjKvkBRJfH7iNwiKdHMuDXI2RX-M=.26377e76-f1a8-45b4-bbb2-1038cb3e2bc7@github.com>

On Tue, 24 Aug 2021 22:15:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds new methods to `DerInputStream` to easily and safely read optional fields in a ASN.1 DER-encoded value. It also adds several wrapping methods to `DerValue` to avoid unnecessary memory copying when calling by an internal method.
>> 
>> The new methods are applied to `OAEPParameters` to show out how they work. A new regression test is added to show that not only the new methods are simper but they are safer and more correct.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new APIs and new examples

Changes look good to me. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

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

From svkamath at openjdk.java.net  Wed Sep  8 00:26:25 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Wed, 8 Sep 2021 00:26:25 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
Message-ID: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>

Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.

The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

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

Commit messages:
 - Merge master
 - JDK 8273297: AES/GCM non AVX512 + VAES CPU's suffer after 8267125
 - changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into aes-gcm
 - Moved declaration in vmStructs.cpp to other AESCrypt declarations
 - comment update
 - rewiew update
 - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
 - changed file property of GaloisCounterMode.java
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into aes-gcm
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/d6d6c069...4628dc3a

Changes: https://git.openjdk.java.net/jdk/pull/5402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5402&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273297
  Stats: 66 lines in 9 files changed: 18 ins; 2 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5402/head:pull/5402

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep  8 06:22:39 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 8 Sep 2021 06:22:39 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <10Ivl80m4qzRju-gdlcN6t4CA11U2m-Ngn4U7PnMHnI=.d0d5cd3f-8e52-47a4-9b01-fbfae7c70387@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
 <10Ivl80m4qzRju-gdlcN6t4CA11U2m-Ngn4U7PnMHnI=.d0d5cd3f-8e52-47a4-9b01-fbfae7c70387@github.com>
Message-ID: <aMxjBJbI8jTVnLxEFNNMNLGE_rURoZyr2jqWHPMQFD8=.e9a5d769-f7ef-4d1a-b83a-379ed56057a3@github.com>

On Tue, 7 Sep 2021 10:39:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarFile.java line 220:
>> 
>>> 218:      * The index file name.
>>> 219:      */
>>> 220:     public static final String INDEX_NAME = "META-INF/INDEX.LIST";
>> 
>> Adding this as a public field means it becomes part of the API, so it shouldn't be public here.
>
> Agree

remove public?but recover the same definition in JarIndex

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep  8 06:22:38 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 8 Sep 2021 06:22:38 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
Message-ID: <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>

> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
> 
> The PR includes:
> 1. remove the JarIndex support in URLClassPath
> 2. move JarIndex into  jdk.jartool module.

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

  Some minor changes
  
  Include:
  1. remove public for INDEX_NAME in JarFile
  2. recover the definition for INDEX_NAME in JarIndex
  3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5383/files
  - new: https://git.openjdk.java.net/jdk/pull/5383/files/7e11c607..cba9047d

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

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep  8 06:22:45 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 8 Sep 2021 06:22:45 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <YWyiF9H1kE5OABN2-IeriWtQ5d3Qn8EfnSzmT66sjfo=.7db9bae3-9008-48a1-83a5-01acdb1a0c57@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <YWyiF9H1kE5OABN2-IeriWtQ5d3Qn8EfnSzmT66sjfo=.7db9bae3-9008-48a1-83a5-01acdb1a0c57@github.com>
Message-ID: <VLwHUfiEaBmuFRVOLOkJoj34KyGfctgdatiGOckIt8I=.9779ca11-149e-4e85-8218-4c02817b3510@github.com>

On Tue, 7 Sep 2021 10:50:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> wxiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some minor changes
>>   
>>   Include:
>>   1. remove public for INDEX_NAME in JarFile
>>   2. recover the definition for INDEX_NAME in JarIndex
>>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73:
> 
>> 71: import static java.util.jar.JarFile.MANIFEST_NAME;
>> 72: import static java.util.stream.Collectors.joining;
>> 73: import static java.util.jar.JarFile.INDEX_NAME;
> 
> Maybe move this above the java.util.streamCollectors.joining import
> 
> Also, the copyright should probably be updated to 2021

update to 2021

> test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Probably should update the copyright year to include 2021

The copyright year includes 2021.

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep  8 06:22:40 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 8 Sep 2021 06:22:40 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <7BzvoN6dbVscgZKB3U3epUjjJ_os26_P5pYPH_rysE8=.c1e499b0-dd77-41fd-b044-76942c0f33cb@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
 <7BzvoN6dbVscgZKB3U3epUjjJ_os26_P5pYPH_rysE8=.c1e499b0-dd77-41fd-b044-76942c0f33cb@github.com>
Message-ID: <c07HdppK0Vgpnz1srSQ1Z2gRpw4GQLFuhasmelW-YHg=.f590d1eb-2da2-40ba-8a44-cd8c220b9cd8@github.com>

On Tue, 7 Sep 2021 17:39:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarVerifier.java line 147:
>> 
>>> 145: 
>>> 146:                 if (uname.equals(JarFile.MANIFEST_NAME) ||
>>> 147:                         uname.equals(JarFile.INDEX_NAME)) {
>> 
>> It would be useful if someone from security-libs could comment on this. The interaction between signed JAR and JAR index isn't very clear. The change you have is safe but it might be that we can drop the checking for INDEX.LIST here.
>
> I am thinking this line should not be removed for compatibility with existing JARs that have indexes.

still keep the code

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep  8 06:22:49 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 8 Sep 2021 06:22:49 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <Q_y3uR0s9p2Qua4aDpoeZmD4ZHri_vuexInWtCYkT2g=.2c2a64df-8a21-4410-8da1-7d0dac1a5d86@github.com>
Message-ID: <vNw2xzuSJdjdUOlCkMjlxS3pnC4xlwNeJdYtFVZLP3Q=.54525a18-f8ff-4458-b89f-41ebcc86d142@github.com>

On Tue, 7 Sep 2021 07:15:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> wxiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some minor changes
>>   
>>   Include:
>>   1. remove public for INDEX_NAME in JarFile
>>   2. recover the definition for INDEX_NAME in JarIndex
>>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar
>
> test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 44:
> 
>> 42: import sun.tools.jar.JarIndex;
>> 43: 
>> 44: public class JarIndexMergeTest {
> 
> Is this the one remaining test in sun/misc/JarIndex? I think it can be moved to test/jdk/java/util/jar. I think we should change the package name in the summary comment too.

This is the only test case, and I move it to test/jdk/java/util/jar.
The summary comment is also changed.

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep  8 06:33:06 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 8 Sep 2021 06:33:06 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
Message-ID: <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>

On Wed, 8 Sep 2021 06:22:38 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
>> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
>> 
>> The PR includes:
>> 1. remove the JarIndex support in URLClassPath
>> 2. move JarIndex into  jdk.jartool module.
>
> wxiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some minor changes
>   
>   Include:
>   1. remove public for INDEX_NAME in JarFile
>   2. recover the definition for INDEX_NAME in JarIndex
>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar

Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473

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

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

From yyang at openjdk.java.net  Wed Sep  8 07:47:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 8 Sep 2021 07:47:13 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
Message-ID: <bLYxaToWjnNwgaOxBJszcSEqcE0jER1Ffc8GGxPEyJQ=.9f50e06d-a72b-4fa3-8f35-6beaab53b129@github.com>

On Wed, 8 Sep 2021 06:22:38 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
>> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
>> 
>> The PR includes:
>> 1. remove the JarIndex support in URLClassPath
>> 2. move JarIndex into  jdk.jartool module.
>
> wxiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some minor changes
>   
>   Include:
>   1. remove public for INDEX_NAME in JarFile
>   2. recover the definition for INDEX_NAME in JarIndex
>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar

Hi all,

Just wondering why we remove JarIndex other than fixing it? Is there any strong motive that drives us to do this?

Judging from our internal performance testing and user feedback, JarIndex can significantly reduce the time for class/resource lookup. Although JarIndex is an ancient technology, it is still helpful for many modern scenarios such as serverless applications.

Thanks.

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

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

From alanb at openjdk.java.net  Wed Sep  8 07:53:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Sep 2021 07:53:04 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
 <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
Message-ID: <c1I20WL6TTKgHQHJRvKiWnf4S4319DrF7sZTSQffAhA=.7f635a18-c3dd-4b83-b880-04631492d8a3@github.com>

On Wed, 8 Sep 2021 06:30:34 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

> Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473

Thanks. I've updated the CSR to make it clearer what this change is about. There is still some TDB for the JAR file spec.

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

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

From serb at openjdk.java.net  Thu Sep  9 07:01:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 07:01:11 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <EVPBMmA5TPBVRdkPLE9j0pU1uWB6dQCeNq_2SjCAffE=.5e59244b-f0c5-4b12-998d-f4ae7999713d@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Looks fine

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  9 07:01:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 9 Sep 2021 07:01:10 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when converting
 stream to String
Message-ID: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>

Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

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

Commit messages:
 - [PATCH] Use ByteArrayOutputStream.toString to convert its content to the String

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

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

From bpb at openjdk.java.net  Thu Sep  9 16:04:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Sep 2021 16:04:07 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <fuyCMvosSYi2H5xDUBPUmRM_bKN2YUVv6UdPrmameV8=.398b89e2-79f1-4b93-a653-80cbb8245e2f@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by bpb (Reviewer).

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

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

From xuelei at openjdk.java.net  Thu Sep  9 16:04:07 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 9 Sep 2021 16:04:07 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <CVdGTu5leV7vfIkVNtHt5sfufvso7V0qwkFqTt3xjBE=.86a34926-0d70-49fd-b59f-5d10fd928520@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Nice catch.  The update looks safe and good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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

From serb at openjdk.java.net  Thu Sep  9 18:13:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 18:13:00 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <kRp_z1I71Yk9DqojqvpOotsYTLpq6d5XH11VajMPqb8=.c6b222a3-36a1-4ea5-a43d-9b74b33c05a4@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by serb (Reviewer).

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Sep  9 19:25:01 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: Thu, 9 Sep 2021 19:25:01 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <KFGjrHoKqNLo9a0ncy2o8c35uCZqxSROXF0Sv1gN6dw=.77bb2735-f8f9-430c-98c8-95ef143230fe@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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

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

From aivanov at openjdk.java.net  Thu Sep  9 20:08:57 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 20:08:57 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <PVMPETQF6OJIx5OK4o3iXMgLBUNksBofdSDBO0P8OGw=.04eee4ba-db8a-41ab-962c-4eefe4af0315@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by aivanov (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  9 21:51:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 9 Sep 2021 21:51:08 GMT
Subject: Integrated: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <De3deQdQDx14DwD8XwMElCVVTbmTvApVJpRl_BnCnEw=.8d47ea85-6b3a-49cd-b2cf-18fabe195e7e@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

This pull request has now been integrated.

Changeset: 2e321dc7
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e321dc782e0de9995b1772e4cee9c0304bc183d
Stats:     6 lines in 4 files changed: 0 ins; 1 del; 5 mod

8273528: Avoid ByteArrayOutputStream.toByteArray when converting stream to String

Reviewed-by: bpb, xuelei, serb, aivanov

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

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

From serb at openjdk.java.net  Thu Sep  9 22:41:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 22:41:09 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <iaAVNXN05o0iZliPGyJUwEkF1_wPi4sUij5bQgB7FvU=.6a21f75b-32b1-4a56-8b8d-18d6103ac420@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

BTW If it is not urgent I suggest to wait 24 hours from the approval before the /integrate, people have different timezones and may not be able to add a comment if any in time.

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

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

From mchung at openjdk.java.net  Thu Sep  9 22:53:01 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 9 Sep 2021 22:53:01 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>
Message-ID: <3YsvWiK0yxQFHzt8Y6zKU3ucGZbQ3FqFWJfs_PnITBY=.7442a7bf-6c49-4a58-a0eb-0f2015dc98f9@github.com>

On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Hmm I was under the impression this was removing AppContext itself but it is just removing the backdoor needed by logging
> Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ...

What is the plan to remove AppContext completely from java.desktop?   It's okay to have a separate PR to remove the logging dependency on AppContext but I'd prefer to see AppContext be removed about the same time with this PR.

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

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

From serb at openjdk.java.net  Thu Sep  9 23:01:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 23:01: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: <NLG8-_-la_YVBW-hDAXeNWzaR6m_wsEueoNQXzsrmv4=.f8dcd406-87ee-4e1a-9a27-56c34f8cfa7f@github.com>

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

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> 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.

I'll remove its used one by one from the external usage like in "java.base" here, then in Swing, then in 2D like fonts, then last in AWT.

That change should not break something other than the tests which intentionally create different appcontexts. And it's easy to review.

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

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

From aph at openjdk.java.net  Mon Sep 13 12:52:51 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 13 Sep 2021 12:52:51 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <ZD1wxPadzxn3IsePRtOphGe61YHwUXqqivQvD36eCzo=.13702178-ad9f-4eba-a49b-1495f326785d@github.com>

On Tue, 7 Sep 2021 22:31:30 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

src/hotspot/share/opto/library_call.cpp line 6796:

> 6794: 
> 6795:   Node* avx512_subkeyHtbl = new_array(klass_node, intcon(96), 0);
> 6796:   if (avx512_subkeyHtbl == NULL) return false;

This looks very Intel-specific, but it's in generic code. Please make this constant 96 a symbol and push it into a header file in the x86 back end.

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

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

From aph at openjdk.java.net  Mon Sep 13 12:52:52 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 13 Sep 2021 12:52:52 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <ZD1wxPadzxn3IsePRtOphGe61YHwUXqqivQvD36eCzo=.13702178-ad9f-4eba-a49b-1495f326785d@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <ZD1wxPadzxn3IsePRtOphGe61YHwUXqqivQvD36eCzo=.13702178-ad9f-4eba-a49b-1495f326785d@github.com>
Message-ID: <dnydhUnsmuo3lpJH6F8Xt2aFxf2E00vOn0NSA0bvdn8=.6db0a5dd-78d2-44fb-a56e-08b7596af97d@github.com>

On Mon, 13 Sep 2021 12:48:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> src/hotspot/share/opto/library_call.cpp line 6796:
> 
>> 6794: 
>> 6795:   Node* avx512_subkeyHtbl = new_array(klass_node, intcon(96), 0);
>> 6796:   if (avx512_subkeyHtbl == NULL) return false;
> 
> This looks very Intel-specific, but it's in generic code. Please make this constant 96 a symbol and push it into a header file in the x86 back end.

Likewise, the name prefix "avx512_" isn't appropriate for code that will certainly be used by other targets.

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

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

From weijun at openjdk.java.net  Mon Sep 13 18:10:20 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 13 Sep 2021 18:10:20 GMT
Subject: Integrated: 8246797: A convenient method to read OPTIONAL element
In-Reply-To: <t1MsF59wViD4BecgbHTIuiJlEqhO__mZGroPab5aPxU=.459bfdaa-ffa0-4169-af82-b932c09dff0c@github.com>
References: <t1MsF59wViD4BecgbHTIuiJlEqhO__mZGroPab5aPxU=.459bfdaa-ffa0-4169-af82-b932c09dff0c@github.com>
Message-ID: <popk4gQzIJw6chuOE0ZCkoWX2lCK9koYo677rJR45Qw=.d8778a7b-deb4-460b-9e0e-949c06f5539d@github.com>

On Mon, 23 Aug 2021 14:52:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds new methods to `DerInputStream` to easily and safely read optional fields in a ASN.1 DER-encoded value. It also adds several wrapping methods to `DerValue` to avoid unnecessary memory copying when calling by an internal method.
> 
> The new methods are applied to `OAEPParameters` to show out how they work. A new regression test is added to show that not only the new methods are simper but they are safer and more correct.

This pull request has now been integrated.

Changeset: fc0f8542
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fc0f8542c387e7f25992cc7eaa2bb45aeace3c39
Stats:     307 lines in 6 files changed: 214 ins; 34 del; 59 mod

8246797: A convenient method to read OPTIONAL element

Reviewed-by: jnimeh, valeriep

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

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

From alanb at openjdk.java.net  Tue Sep 14 12:43:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Sep 2021 12:43:08 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
 <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
Message-ID: <zYSExubCSsD6URWT3grNueIQNq3yo5kyfQkppWTOU3s=.62aac08e-4fd4-46f2-8e04-ff89b9133fc3@github.com>

On Wed, 8 Sep 2021 06:30:34 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

>> wxiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some minor changes
>>   
>>   Include:
>>   1. remove public for INDEX_NAME in JarFile
>>   2. recover the definition for INDEX_NAME in JarIndex
>>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar
>
> Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473

@shiyuexw I discussed this issue with other maintainers in this area. There was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. A system property can be used to re-enable. I've updated the CSR to reflect this proposal. Are you okay to continue with this new proposal? It would mean that we wouldn't remove the tests but instead change them to run with the system property.

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

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

From aph at openjdk.java.net  Tue Sep 14 13:34:03 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 14 Sep 2021 13:34:03 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <rBCLn8hbfilvDUwuHOvkyZ4wefiur1JtsrRm8Uclhys=.b4e76584-b3e7-4884-801e-e0ec1e8067c1@github.com>

On Tue, 7 Sep 2021 22:31:30 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

It seems to me there's a serious problem here. When you execute the galoisCounterMode_AESCrypt() intrinsic, I don't think there's a limit on the number of blocks to be encrypted. With the older intrinsic things are not so very bad because the incoming data is split into 6 segments. But if we use this intrinsic, there is no safepoint check in the inner loop, which can lead to a long time to safepoint, and this causes stalls on the other threads.
If you split the incoming data into blocks of about a megabyte you'd lose no measurable performance but you'd dramatically improve the performance of everything else, especially with a concurrent GC.

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

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

From github.com+18482851+stefan-zobel at openjdk.java.net  Tue Sep 14 19:01:29 2021
From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel)
Date: Tue, 14 Sep 2021 19:01:29 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v42]
In-Reply-To: <oORuxOAi-tXeZ2a4ndnX1PaaIFPV99_A-s-4eSMLdlk=.28984004-6ce0-4f27-bd36-15480bfe4218@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <oORuxOAi-tXeZ2a4ndnX1PaaIFPV99_A-s-4eSMLdlk=.28984004-6ce0-4f27-bd36-15480bfe4218@github.com>
Message-ID: <xy_DCy1e08qj6KVS2RD5s6T4OAhqrYHXhn5RotCfI50=.d2f15db2-6187-4c2b-8c1a-dc77b0d5ddce@github.com>

On Mon, 5 Apr 2021 14:20:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - Merge branch 'master' into 8248862
>  - Fix NotCompliantCauseTest to not rely on Random not being a bean
>  - Merge branch 'master' into 8248862
>  - Correct return type of RandomGeneratorFactory.of
>  - Merge branch 'master' into 8248862
>  - CSR review revisions
>  - CSR review updates
>  - Removed @since from nextDouble ThreadLocalRandom
>  - RandomGeneratorFactory::all(Class<T> category) @implNote was out of date
>  - Clarify all()
>  - ... and 68 more: https://git.openjdk.java.net/jdk/compare/a8005efd...ffd982b0

The package javadoc of java.util.random says that `mixLea32` is used as a mixing function in the L64 and L128 generators which doesn't seem to be correct. That should probably read `mixLea64`

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

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

From jlaskey at openjdk.java.net  Tue Sep 14 19:10:29 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 14 Sep 2021 19:10:29 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v42]
In-Reply-To: <xy_DCy1e08qj6KVS2RD5s6T4OAhqrYHXhn5RotCfI50=.d2f15db2-6187-4c2b-8c1a-dc77b0d5ddce@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <oORuxOAi-tXeZ2a4ndnX1PaaIFPV99_A-s-4eSMLdlk=.28984004-6ce0-4f27-bd36-15480bfe4218@github.com>
 <xy_DCy1e08qj6KVS2RD5s6T4OAhqrYHXhn5RotCfI50=.d2f15db2-6187-4c2b-8c1a-dc77b0d5ddce@github.com>
Message-ID: <44FW-mHCNHd1NiM9QnJZ23NtjnGmkzLxLk7CRDuYjx8=.fc3004c8-94b6-4559-853e-56e4dc0c9326@github.com>

On Tue, 14 Sep 2021 18:58:16 GMT, stefan-zobel <github.com+18482851+stefan-zobel at openjdk.org> wrote:

> The package javadoc of java.util.random says that `mixLea32` is used as a mixing function in the L64 and L128 generators which doesn't seem to be correct. That should probably read `mixLea64`

See https://bugs.openjdk.java.net/browse/JDK-8272866

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

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

From siomarapantarotto at gmail.com  Tue Sep 14 23:42:59 2021
From: siomarapantarotto at gmail.com (SIOMARA CINTIA Pantarotto)
Date: Tue, 14 Sep 2021 20:42:59 -0300
Subject: Add a digital signature in a PDF file
Message-ID: <CALV3EVJ-NCrgakrYBLkxJ8HfEUFo_dH3eaz40-8atmFNTwYUSQ@mail.gmail.com>

Hi guys!



I have developed a java/android application that should allow the logged in
user to sign a PDF file with his cloud digital certificate.



Can anyone point me to tutorials, examples, java packages that allow me to
do this from scratch? Any tips are very welcome.


Thanks

-- 
*SIOMARA CINTIA PANTAROTTO*

*siomara.com.br <http://siomara.com.br>**+55 (61) 99282-6332*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210914/fef63586/attachment.htm>

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep 15 01:48:46 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 15 Sep 2021 01:48:46 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
 <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
Message-ID: <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com>

On Wed, 8 Sep 2021 06:30:34 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

>> wxiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some minor changes
>>   
>>   Include:
>>   1. remove public for INDEX_NAME in JarFile
>>   2. recover the definition for INDEX_NAME in JarIndex
>>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar
>
> Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473

> @shiyuexw I discussed this issue with other maintainers in this area. There was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. A system property can be used to re-enable. I've updated the CSR to reflect this proposal. Are you okay to continue with this new proposal? It would mean that we wouldn't remove the tests but instead change them to run with the system property.

Yes, I will take care of it. Need I create a new PR?

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

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

From alanb at openjdk.java.net  Wed Sep 15 06:01:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 15 Sep 2021 06:01:50 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
 <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
 <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com>
Message-ID: <WicyM_F9xvhMLKTffmWoZbpOzuFRjwG7xt8VxM5qlSs=.a8614c17-eb47-49dd-a5ca-2e92ed03c5c0@github.com>

On Wed, 15 Sep 2021 01:45:49 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

> Yes, I will take care of it. Need I create a new PR?

Up to you, it's okay to continue with this one if you want, we would just need to change the description here and in JBS.

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

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

From tvoniadka at openjdk.java.net  Wed Sep 15 08:11:17 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Wed, 15 Sep 2021 08:11:17 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher
Message-ID: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>

The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. The test at present looks only at the following absolute paths for openssl (in that order):

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

Commit messages:
 - 8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Wed Sep 15 10:22:49 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Wed, 15 Sep 2021 10:22:49 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <WicyM_F9xvhMLKTffmWoZbpOzuFRjwG7xt8VxM5qlSs=.a8614c17-eb47-49dd-a5ca-2e92ed03c5c0@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
 <yy48petfZ2m4I_TKEr69n6AFhs8lYMkfYcQiTeH-C8Q=.a40c556d-ec91-4d6e-9f7a-de6d8b0fc626@github.com>
 <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com>
 <WicyM_F9xvhMLKTffmWoZbpOzuFRjwG7xt8VxM5qlSs=.a8614c17-eb47-49dd-a5ca-2e92ed03c5c0@github.com>
Message-ID: <VGKBEymUDwrw7HCnUC-b2v5qwxHFP87KmALDhZyXYT8=.f32dec7e-e15f-479b-8364-de1f35dd8f23@github.com>

On Wed, 15 Sep 2021 05:59:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Yes, I will take care of it. Need I create a new PR?
> 
> Up to you, it's okay to continue with this one if you want, we would just need to change the description here and in JBS.

I created a new PR https://github.com/openjdk/jdk/pull/5524 to disable JarIndex and update the description in JBS.

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

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

From weijun at openjdk.java.net  Wed Sep 15 21:52:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 15 Sep 2021 21:52:27 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher
In-Reply-To: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
Message-ID: <wIMVd9X427_uNR2-5AsoBh4WJCLYGVBQyTdWrvC4Q9U=.1d56ee99-de7d-4079-bca9-96749c2ff41d@github.com>

On Wed, 15 Sep 2021 08:01:30 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. Some mechanisms are used to discover openssl, among which searching through a predefined set of paths is also one. The test at present looks only at the following absolute paths (in that order):

My understanding is that the $PATH variable usually already contains `/usr/bin` and `/usr/local/bin`. If you switch to $PATH, maybe it's no more necessary to try out those 2 anymore?

Just curious, what is the full path of openssl on your Cygwin?

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

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

From tvoniadka at openjdk.java.net  Thu Sep 16 07:14:44 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Thu, 16 Sep 2021 07:14:44 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher
In-Reply-To: <wIMVd9X427_uNR2-5AsoBh4WJCLYGVBQyTdWrvC4Q9U=.1d56ee99-de7d-4079-bca9-96749c2ff41d@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
 <wIMVd9X427_uNR2-5AsoBh4WJCLYGVBQyTdWrvC4Q9U=.1d56ee99-de7d-4079-bca9-96749c2ff41d@github.com>
Message-ID: <RVMTV8vQZRFI4-zzDtso6wVsy615-hfj8QdKz66hfm0=.773909b6-ffb8-4711-bab6-af0682264209@github.com>

On Wed, 15 Sep 2021 21:49:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> My understanding is that the $PATH variable usually already contains `/usr/bin` and `/usr/local/bin`. If you switch to $PATH, maybe it's no more necessary to try out those 2 anymore?
> 
> Just curious, what is the full path of openssl on your Cygwin?

On the machine I checked, it reads as follows:

PATH='C:\\Cygwin\\usr\\local\\bin;C:\\Cygwin\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0;C:\\WINDOWS\\System32\\OpenSSH;C:\\cygwin\\bin;C:\\Users\\jpgansible\\AppData\\Local\\Microsoft\\WindowsApps;%JAVA_HOME%\\bin;C:\\Cygwin\\usr\\local\\bin' \\

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Sep 16 19:10:43 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: Thu, 16 Sep 2021 19:10:43 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: <XjBCYp6YkrOTmcHd90YOsdNAIyR96MOB1AFhe7nVHRA=.813f0a69-b3da-46b9-a2bf-9f2bd8b84c16@github.com>

On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> 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

Let's wait, bridgekeeper.

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

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

From svkamath at openjdk.java.net  Thu Sep 16 20:46:49 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Thu, 16 Sep 2021 20:46:49 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <dnydhUnsmuo3lpJH6F8Xt2aFxf2E00vOn0NSA0bvdn8=.6db0a5dd-78d2-44fb-a56e-08b7596af97d@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <ZD1wxPadzxn3IsePRtOphGe61YHwUXqqivQvD36eCzo=.13702178-ad9f-4eba-a49b-1495f326785d@github.com>
 <dnydhUnsmuo3lpJH6F8Xt2aFxf2E00vOn0NSA0bvdn8=.6db0a5dd-78d2-44fb-a56e-08b7596af97d@github.com>
Message-ID: <lMe9jRPD4bzoo2uuEzGxnUeRryeh38X6_Kj4nMaOcF8=.b51c20db-5d23-4edd-a2c1-d3831b76bc11@github.com>

On Mon, 13 Sep 2021 12:50:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 6796:
>> 
>>> 6794: 
>>> 6795:   Node* avx512_subkeyHtbl = new_array(klass_node, intcon(96), 0);
>>> 6796:   if (avx512_subkeyHtbl == NULL) return false;
>> 
>> This looks very Intel-specific, but it's in generic code. Please make this constant 96 a symbol and push it into a header file in the x86 back end.
>
> Likewise, the name prefix "avx512_" isn't appropriate for code that will certainly be used by other targets.

I'll modify the code. Thanks.

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

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

From svkamath at openjdk.java.net  Thu Sep 16 20:55:48 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Thu, 16 Sep 2021 20:55:48 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <rBCLn8hbfilvDUwuHOvkyZ4wefiur1JtsrRm8Uclhys=.b4e76584-b3e7-4884-801e-e0ec1e8067c1@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <rBCLn8hbfilvDUwuHOvkyZ4wefiur1JtsrRm8Uclhys=.b4e76584-b3e7-4884-801e-e0ec1e8067c1@github.com>
Message-ID: <jel-pUzZrxyW6o9aRQqaRxjXYwMDhzBECrqqoeUHoMQ=.cc1adf41-dd69-4d26-8a23-c4195fd00f44@github.com>

On Tue, 14 Sep 2021 13:31:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> It seems to me there's a serious problem here. When you execute the galoisCounterMode_AESCrypt() intrinsic, I don't think there's a limit on the number of blocks to be encrypted. With the older intrinsic things are not so very bad because the incoming data is split into 6 segments. But if we use this intrinsic, there is no safepoint check in the inner loop, which can lead to a long time to safepoint, and this causes stalls on the other threads.
> If you split the incoming data into blocks of about a megabyte you'd lose no measurable performance but you'd dramatically improve the performance of everything else, especially with a concurrent GC.

@theRealAph Thank you for the comment above. I will look into this issue.

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

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

From serb at openjdk.java.net  Fri Sep 17 02:42:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 02:42:52 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>
Message-ID: <JXoInLqAX1Sxkykz_N97DO4QEbf6gYjV0ul6l4vsnwY=.14f44cd8-281d-4386-968c-fdc49a9604cf@github.com>

On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to removing this legacy/unused code but I think it would be useful to useful to have the JBS issue or the PR summary provide a bit more context. As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right?

I have updated the PR and JBS

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

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

From aph-open at littlepinkcloud.com  Fri Sep 17 08:52:13 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 17 Sep 2021 09:52:13 +0100
Subject: Intrinsic methods and time to safepoint
In-Reply-To: <87czp8g0wu.fsf@redhat.com>
References: <eaf198eb-e624-a45f-1766-c72f81fbf6f0@littlepinkcloud.com>
 <87czp8g0wu.fsf@redhat.com>
Message-ID: <b6d9dbf9-fb20-f211-ebef-c6088301f23e@littlepinkcloud.com>

On 9/16/21 1:28 PM, Roland Westrelin wrote:
> 
>> I believe we should have a policy to cover how long an intrinsic can
>> delay without responding to a safepoint, and that it should be in the
>> millisecond range. It would make almost no difference to the
>> performance of encryption if chunks handles by a fast intrinsic were,
>> say, about a megabyte. The difference in performance is so small as to
>> be immeasurable, and the improvement in the performance of other threads
>> is vast.
> 
> I agree with you (seems like a no brainer) but I have a couple comments
> about implementation details.
> 
> Those intrinsics usually call some stub. It's not possible AFAICT, to
> have the safepoint in the stub itself. So we need some loop that
> repeatedly calls the stub. That loop can either be added 1) by the JIT
> as IR when the intrinsic is expanded 2) in java code, that is java
> library code needs to be refactored.
> 
> 2) would seem much easier to implement and would work for both c1 and c2
> (if some of these intrinsics end up implemented by c1).

OK. I guess the problem is that the call to the stub doesn't have an oop
map.

The tricky cases seem to be in the crypto code, which is already rather
fiddly. It's usually simple enough for intrinsics to return the amount of
work left to do, I guess.

> Also a note of caution about loop strip mining: it doesn't have a model
> for what the loop body costs. So it blindly assumes all loop bodies can
> be run for 1000 iterations (by default) between safepoints. Unless I'm
> missing something, with a stub running for 1ms, delays between safepoint
> could still be 1s.

It'd be interesting to do the experiment. I might try that, just for grins.

-- 
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 aph-open at littlepinkcloud.com  Fri Sep 17 14:09:00 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 17 Sep 2021 15:09:00 +0100
Subject: Intrinsic methods and time to safepoint
In-Reply-To: <87a6kbftu5.fsf@redhat.com>
References: <eaf198eb-e624-a45f-1766-c72f81fbf6f0@littlepinkcloud.com>
 <87czp8g0wu.fsf@redhat.com>
 <b6d9dbf9-fb20-f211-ebef-c6088301f23e@littlepinkcloud.com>
 <87a6kbftu5.fsf@redhat.com>
Message-ID: <9fc9a3ac-1108-64a2-f7ef-9be76f0e7a95@littlepinkcloud.com>

On 9/17/21 10:13 AM, Roland Westrelin wrote:
> 
>> OK. I guess the problem is that the call to the stub doesn't have an oop
>> map.
> 
> Assuming you can get the oop map in stub, deoptimization could still be
> delayed until the stub is exited. Is that considered a problem?
> 
> Actually I'm not even sure the loop synthesized from IR nodes is
> feasible: what would the JVM state at the safepoint be given that
> there's no actual java code for it? What would you deoptimize to if you
> were to deoptimize?

Ah. Perhaps you have a good point.  :-)

-- 
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 mullan at openjdk.java.net  Fri Sep 17 14:29:34 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 17 Sep 2021 14:29:34 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:

 - Add some more comments in the PKIX date() and timestamp() methods.
   Remove extra newline from debugging output.
 - Revert "Revert "Initial revision.""
   
   This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
 - Remove.
 - Revert "Initial revision."
   
   This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/626f7ed8..d797f32a

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

  Stats: 108 lines in 4 files changed: 8 ins; 96 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5320/head:pull/5320

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

From rwestrel at redhat.com  Fri Sep 17 09:13:22 2021
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 17 Sep 2021 11:13:22 +0200
Subject: Intrinsic methods and time to safepoint
In-Reply-To: <b6d9dbf9-fb20-f211-ebef-c6088301f23e@littlepinkcloud.com>
References: <eaf198eb-e624-a45f-1766-c72f81fbf6f0@littlepinkcloud.com>
 <87czp8g0wu.fsf@redhat.com>
 <b6d9dbf9-fb20-f211-ebef-c6088301f23e@littlepinkcloud.com>
Message-ID: <87a6kbftu5.fsf@redhat.com>


> OK. I guess the problem is that the call to the stub doesn't have an oop
> map.

Assuming you can get the oop map in stub, deoptimization could still be
delayed until the stub is exited. Is that considered a problem?

Actually I'm not even sure the loop synthesized from IR nodes is
feasible: what would the JVM state at the safepoint be given that
there's no actual java code for it? What would you deoptimize to if you
were to deoptimize?

Roland.


From valeriep at openjdk.java.net  Fri Sep 17 23:31:41 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 17 Sep 2021 23:31:41 GMT
Subject: RFR: 8264849: Add KW and KWP support to PKCS11 provider
Message-ID: <AN6G5ItCvLfhLTAuITEqy7Sw2X8C35Yugjm2VnLkDZ8=.cdb54e16-2fc4-42d6-ba5f-bcd83fe5cc58@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

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

Commit messages:
 - 8264849: Add KW and KWP support to PKCS11 provider

Changes: https://git.openjdk.java.net/jdk/pull/5569/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5569&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264849
  Stats: 2141 lines in 17 files changed: 2042 ins; 46 del; 53 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 svkamath at openjdk.java.net  Mon Sep 20 05:16:16 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Mon, 20 Sep 2021 05:16:16 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

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

  Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5402/files
  - new: https://git.openjdk.java.net/jdk/pull/5402/files/4628dc3a..7ea464ae

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

  Stats: 42 lines in 5 files changed: 28 ins; 1 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5402/head:pull/5402

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

From tvoniadka at openjdk.java.net  Mon Sep 20 05:30:50 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Mon, 20 Sep 2021 05:30:50 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher
In-Reply-To: <wIMVd9X427_uNR2-5AsoBh4WJCLYGVBQyTdWrvC4Q9U=.1d56ee99-de7d-4079-bca9-96749c2ff41d@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
 <wIMVd9X427_uNR2-5AsoBh4WJCLYGVBQyTdWrvC4Q9U=.1d56ee99-de7d-4079-bca9-96749c2ff41d@github.com>
Message-ID: <MCCYUkiSx4IIxvtaSwSDbZJ16Fko4d-7BOXt9jRi-jU=.956afbef-d532-4481-b438-361424e88c9f@github.com>

On Wed, 15 Sep 2021 21:49:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. Some mechanisms are used to discover openssl, among which searching through a predefined set of paths is also one. The test at present looks only at the following absolute paths (in that order):
>
> My understanding is that the $PATH variable usually already contains `/usr/bin` and `/usr/local/bin`. If you switch to $PATH, maybe it's no more necessary to try out those 2 anymore?
> 
> Just curious, what is the full path of openssl on your Cygwin?

@wangweij, just a quick follow-up to make sure this change makes sense given the value of PATH variable on some of those machines (I mentioned it in the comment above). It appears it is true that openssl is indeed found inside /usr/local/bin directory, but on Cygwin-based systems, this actually translates to something like "C:\Cygwin\usr\local\bin" system path. Since we are explicitly passing "/usr/local/bin/openssl" to the process launcher, it fails to launch on such machines. We could have probably passed "C:\Cygwin...", but that would indicate some sort of prior knowledge towards where Cygwin is installed exactly. Hence, just an additional attempt with no absolute paths could succeed.

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

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

From weijun at openjdk.java.net  Mon Sep 20 12:08:00 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 20 Sep 2021 12:08:00 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher
In-Reply-To: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
Message-ID: <iw_28_TFe03JpYBQnq2aJsjSlfJP2k2-4bt6XD1J-XI=.35f83753-2005-431a-98f1-511b1085cf3b@github.com>

On Wed, 15 Sep 2021 08:01:30 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. Some mechanisms are used to discover openssl, among which searching through a predefined set of paths is also one. The test at present looks only at the following absolute paths (in that order):

Marked as reviewed by weijun (Reviewer).

OK, I understand why the previous 2 paths are not enough. The current change looks fine to me.

One small suggestion: since you're are using openssl from $PATH, I assume it's actually unnecessary to search in `/usr/bin` anymore. Maybe `/usr/local/bin` is still useful.

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

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

From mullan at openjdk.java.net  Mon Sep 20 15:18:28 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 15:18:28 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v3]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <FTDDhQon5eFfKzmRQWWld8sWff0J0Jj7uKWbCfuQFtY=.bf1611ba-adac-451e-a5d1-6f0242612ca6@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

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

  Add back DynStatic.java test which was accidentally removed in prior commit.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/d797f32a..ae1ea608

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

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

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

From weijun at openjdk.java.net  Mon Sep 20 15:35:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 20 Sep 2021 15:35:57 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
Message-ID: <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>

On Fri, 17 Sep 2021 14:29:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
>> 
>> Some additional notes about the fix:
>> 
>> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.
>
> Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add some more comments in the PKIX date() and timestamp() methods.
>    Remove extra newline from debugging output.
>  - Revert "Revert "Initial revision.""
>    
>    This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
>  - Remove.
>  - Revert "Initial revision."
>    
>    This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.

Marked as reviewed by weijun (Reviewer).

src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line 228:

> 226:             }
> 227:             return timestampDate;
> 228:         }

Can we also add some words to the `date()` method? Something which tells the major difference between it and `timestamp()`?

src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java line 114:

> 112: 
> 113:     // extract last certificate and key from chain
> 114:     private void init(CertPath cp) {

The `init` name suggests it's only done once at the beginning, but actually it's an accumulation process. Can we find another name?

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

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

From mullan at openjdk.java.net  Mon Sep 20 15:35:56 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 15:35:56 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v4]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <aEI2KvKcHxvwu0XXHjRRPq8ycLIVod8XSDhR6R-KElA=.9b8de5c8-cb2d-4464-b8f2-8fe44fea4da4@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

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

  Remove trailing whitespace.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/ae1ea608..ee2d3080

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

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

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

From ascarpino at openjdk.java.net  Mon Sep 20 16:47:59 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 20 Sep 2021 16:47:59 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
Message-ID: <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>

On Mon, 20 Sep 2021 05:16:16 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries

I approve the jdk changes.   You'll need a hotspot reviewer to approve the other changes

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

Marked as reviewed by ascarpino (Reviewer).

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

From mullan at openjdk.java.net  Mon Sep 20 17:09:58 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 17:09:58 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
 <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
Message-ID: <x1UpCUnn27YAH61YLuyargOOKDIUzItu3s1AOGFNag0=.05ddbd95-b8bc-4168-8af6-20fe482847d9@github.com>

On Mon, 20 Sep 2021 14:28:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add some more comments in the PKIX date() and timestamp() methods.
>>    Remove extra newline from debugging output.
>>  - Revert "Revert "Initial revision.""
>>    
>>    This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
>>  - Remove.
>>  - Revert "Initial revision."
>>    
>>    This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.
>
> src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java line 114:
> 
>> 112: 
>> 113:     // extract last certificate and key from chain
>> 114:     private void init(CertPath cp) {
> 
> The `init` name suggests it's only done once at the beginning, but actually it's an accumulation process. Can we find another name?

I have renamed it to `addToCertsAndKeys`.

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

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

From mullan at openjdk.java.net  Mon Sep 20 17:26:12 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 17:26:12 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v5]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <Hy4f-DylhuKZW71A3TJtLCromRd-PXQMthdhlAETKjY=.4cfc12d4-364c-467c-bbe2-192d1ea2eefc@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

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

  Rename JarConstraintsParameter.init to addToCertsAndKeys. Add more comments
  describing PKIX date() method.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/ee2d3080..3f942e52

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

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

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

From mullan at openjdk.java.net  Mon Sep 20 17:30:49 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 17:30:49 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
 <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
Message-ID: <4iNZ_0FIYPpNq9JTCYUcuaCfZJa5vNVqljZjzmljoYk=.4c26869d-2109-487e-896e-5d88273d202b@github.com>

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

>> Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add some more comments in the PKIX date() and timestamp() methods.
>>    Remove extra newline from debugging output.
>>  - Revert "Revert "Initial revision.""
>>    
>>    This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
>>  - Remove.
>>  - Revert "Initial revision."
>>    
>>    This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.
>
> src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line 228:
> 
>> 226:             }
>> 227:             return timestampDate;
>> 228:         }
> 
> Can we also add some words to the `date()` method? Something which tells the major difference between it and `timestamp()`?

Done - see latest commit.

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

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

From svkamath at openjdk.java.net  Mon Sep 20 17:42:59 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Mon, 20 Sep 2021 17:42:59 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <rBCLn8hbfilvDUwuHOvkyZ4wefiur1JtsrRm8Uclhys=.b4e76584-b3e7-4884-801e-e0ec1e8067c1@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <rBCLn8hbfilvDUwuHOvkyZ4wefiur1JtsrRm8Uclhys=.b4e76584-b3e7-4884-801e-e0ec1e8067c1@github.com>
Message-ID: <V9idhogEeGX4gevUvHgwKiOSjQTwkEuq8Eetve-GJfc=.77586196-dcf8-495c-b2d6-bd4ce100fd56@github.com>

On Tue, 14 Sep 2021 13:31:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> It seems to me there's a serious problem here. When you execute the galoisCounterMode_AESCrypt() intrinsic, I don't think there's a limit on the number of blocks to be encrypted. With the older intrinsic things are not so very bad because the incoming data is split into 6 segments. But if we use this intrinsic, there is no safepoint check in the inner loop, which can lead to a long time to safepoint, and this causes stalls on the other threads.
> If you split the incoming data into blocks of about a megabyte you'd lose no measurable performance but you'd dramatically improve the performance of everything else, especially with a concurrent GC.

@theRealAph I have implemented changes as per your suggestions. Could you review the changes and let me know your thoughts?

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

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

From weijun at openjdk.java.net  Mon Sep 20 21:43:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 20 Sep 2021 21:43:19 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <4iNZ_0FIYPpNq9JTCYUcuaCfZJa5vNVqljZjzmljoYk=.4c26869d-2109-487e-896e-5d88273d202b@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
 <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
 <4iNZ_0FIYPpNq9JTCYUcuaCfZJa5vNVqljZjzmljoYk=.4c26869d-2109-487e-896e-5d88273d202b@github.com>
Message-ID: <--rx7zLzVnvYXqRJl6-b-I9UWEo9L0GL4EL_4mii3dw=.76673de1-d3c8-4730-a023-008f355a2a71@github.com>

On Mon, 20 Sep 2021 17:27:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line 228:
>> 
>>> 226:             }
>>> 227:             return timestampDate;
>>> 228:         }
>> 
>> Can we also add some words to the `date()` method? Something which tells the major difference between it and `timestamp()`?
>
> Done - see latest commit.

All is good. No any other comment.

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

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

From tvoniadka at openjdk.java.net  Tue Sep 21 03:18:51 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Tue, 21 Sep 2021 03:18:51 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher
In-Reply-To: <iw_28_TFe03JpYBQnq2aJsjSlfJP2k2-4bt6XD1J-XI=.35f83753-2005-431a-98f1-511b1085cf3b@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
 <iw_28_TFe03JpYBQnq2aJsjSlfJP2k2-4bt6XD1J-XI=.35f83753-2005-431a-98f1-511b1085cf3b@github.com>
Message-ID: <8ZcgtHtvzGjru0BibmXhWIjvgYEYuaT7Qpn9STVqN28=.272553d9-ac60-4e2f-a3e6-ec6a2bfa0594@github.com>

On Mon, 20 Sep 2021 12:04:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. Some mechanisms are used to discover openssl, among which searching through a predefined set of paths is also one. The test at present looks only at the following absolute paths (in that order):
>
> OK, I understand why the previous 2 paths are not enough. The current change looks fine to me.
> 
> One small suggestion: since you're are using openssl from $PATH, I assume it's actually unnecessary to search in `/usr/bin` anymore. Maybe `/usr/local/bin` is still useful.

Yes, I think your suggestion makes sense @wangweij. I will modify the patch today to remove /usr/bin/openssl, do a quick round of testing, and will re-upload.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 21 07:34:23 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 21 Sep 2021 07:34:23 GMT
Subject: RFR: 8274050: Unnecessary Vector usage in javax.crypto
Message-ID: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>

In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

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

Commit messages:
 - [PATCH] Unnecessary Vector usage in javax.crypto
 - [PATCH] Unnecessary Vector usage in javax.crypto

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

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

From github.com+54594+schlosna at openjdk.java.net  Tue Sep 21 07:34:26 2021
From: github.com+54594+schlosna at openjdk.java.net (David Schlosnagle)
Date: Tue, 21 Sep 2021 07:34:26 GMT
Subject: RFR: 8274050: Unnecessary Vector usage in javax.crypto
In-Reply-To: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
References: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
Message-ID: <E_xVansODSvVTkBDAT-vVrh_IH4secOsgamPUnhLGFk=.6040dbcb-c648-4cd9-8dc0-44899741a764@github.com>

On Thu, 26 Aug 2021 06:19:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 348:

> 346:         CryptoPermission[] ret = new CryptoPermission[permVector.size()];
> 347:         permVector.copyInto(ret);
> 348:         return ret;

Should this return the result of `toArray` for safety (though it is sized correctly so per API should return the same `ret` array).

Suggestion:

        CryptoPermission[] ret = new CryptoPermission[permList.size()];
        return permList.toArray(ret);


Separate perf nit would be to use size zero array as arg to `toArray` per https://shipilev.net/blog/2016/arrays-wisdom-ancients/

Suggestion:

        return permList.toArray(new CryptoPermission[0]);

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 21 07:34:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 21 Sep 2021 07:34:28 GMT
Subject: RFR: 8274050: Unnecessary Vector usage in javax.crypto
In-Reply-To: <E_xVansODSvVTkBDAT-vVrh_IH4secOsgamPUnhLGFk=.6040dbcb-c648-4cd9-8dc0-44899741a764@github.com>
References: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
 <E_xVansODSvVTkBDAT-vVrh_IH4secOsgamPUnhLGFk=.6040dbcb-c648-4cd9-8dc0-44899741a764@github.com>
Message-ID: <7Edt1X_SD_pyOhC8i5mONvTwGfaPl0IQ0wlEpFxFy10=.45b2394c-13ec-4586-8fdd-36bdf63b511d@github.com>

On Wed, 8 Sep 2021 02:10:36 GMT, David Schlosnagle <github.com+54594+schlosna at openjdk.org> wrote:

>> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.
>
> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 348:
> 
>> 346:         CryptoPermission[] ret = new CryptoPermission[permVector.size()];
>> 347:         permVector.copyInto(ret);
>> 348:         return ret;
> 
> Should this return the result of `toArray` for safety (though it is sized correctly so per API should return the same `ret` array).
> 
> Suggestion:
> 
>         CryptoPermission[] ret = new CryptoPermission[permList.size()];
>         return permList.toArray(ret);
> 
> 
> Separate perf nit would be to use size zero array as arg to `toArray` per https://shipilev.net/blog/2016/arrays-wisdom-ancients/
> 
> Suggestion:
> 
>         return permList.toArray(new CryptoPermission[0]);

Thank for suggestion. Updated.

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

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

From tvoniadka at openjdk.java.net  Tue Sep 21 08:07:18 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Tue, 21 Sep 2021 08:07:18 GMT
Subject: RFR: 8273646: Add openssl from path variable also in to Default
 System Openssl Path in OpensslArtifactFetcher [v2]
In-Reply-To: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
Message-ID: <zuzodL0QvghbHESywbYqcdMZaPD1f0faoxRQ-IPKDag=.8252df83-3905-4726-a3a4-22b647eb3623@github.com>

> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. Some mechanisms are used to discover openssl, among which searching through a predefined set of paths is also one. The test at present looks only at the following absolute paths (in that order):

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

  8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5523/files
  - new: https://git.openjdk.java.net/jdk/pull/5523/files/b1767767..3556e3ec

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

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

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

From kizune at openjdk.java.net  Tue Sep 21 09:02:53 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 21 Sep 2021 09:02:53 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: <ZM4mZ3AxOmywSXnOnNwY-evQuqo3gOjGx_ehjEnhZTM=.efd35f37-dbd4-4d16-b0b7-771e94b2e6aa@github.com>

On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> 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 kizune (Reviewer).

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

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

From tvoniadka at openjdk.java.net  Tue Sep 21 09:04:51 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Tue, 21 Sep 2021 09:04:51 GMT
Subject: Integrated: 8273646: Add openssl from path variable also in to
 Default System Openssl Path in OpensslArtifactFetcher
In-Reply-To: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
References: <sNI_f8_UDLBAgyiJg0_AhMtXQoxNwJ1eeOY-UwrZXng=.40484fac-c108-41d3-a6ef-0634eae009c5@github.com>
Message-ID: <5lmi2ZsQsTPuJWpAa5iFYMDjKI9UUHrk_2J54sTqeqE=.9384451e-870d-4163-b5e8-149957e2e875@github.com>

On Wed, 15 Sep 2021 08:01:30 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs interoperability checks between JDK and openssl with respect to certain keystore operations. The test requires a suitable version of openssl to be available on the machine it runs. Some mechanisms are used to discover openssl, among which searching through a predefined set of paths is also one. The test at present looks only at the following absolute paths (in that order):

This pull request has now been integrated.

Changeset: a5108a60
Author:    Thejasvi Voniadka <tvoniadka at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a5108a605e6a1e427d90dbeeb8630a3d01d6b405
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

Reviewed-by: weijun

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

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

From prappo at openjdk.java.net  Tue Sep 21 12:36:57 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 12:36:57 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base
Message-ID: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>

8274075: Fix miscellaneous typos in java.base

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

Commit messages:
 - Initial commit

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

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

From dfuchs at openjdk.java.net  Tue Sep 21 12:50:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 21 Sep 2021 12:50:52 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base
In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
Message-ID: <njc1ezTA4hC1M__rceJVWLJO4ZuQj9A9b9zoICSl8kw=.1502b2d4-b30f-4b2e-b002-1af67f88ba9b@github.com>

On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8274075: Fix miscellaneous typos in java.base

Marked as reviewed by dfuchs (Reviewer).

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

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

From prappo at openjdk.java.net  Tue Sep 21 13:16:02 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 13:16:02 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
Message-ID: <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>

> 8274075: Fix miscellaneous typos in java.base

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

  Tweak wording for Throwable constructor parameters

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5610/files
  - new: https://git.openjdk.java.net/jdk/pull/5610/files/2db8525d..19b6f496

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 21 13:28:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 21 Sep 2021 13:28:26 GMT
Subject: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in
 java.base module
Message-ID: <yT2Auvz6F8-c5nHnfMb5rIfI7Q42sNyOHsyMFANd1jk=.5797dd93-89fd-4c53-9259-ec82fda1b387@github.com>

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

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

Commit messages:
 - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.base module

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

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

From mullan at openjdk.java.net  Tue Sep 21 13:49:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 21 Sep 2021 13:49:35 GMT
Subject: Integrated: 8269039: Disable SHA-1 Signed JARs
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <CBCQBBUQuz9TQb2V4_dhINWaJYlo-Y9_OLkaLgKpA4A=.59952170-c2a2-4d1e-beb8-d233d8b97018@github.com>

On Tue, 31 Aug 2021 18:53:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

This pull request has now been integrated.

Changeset: 6d91a3eb
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7
Stats:     666 lines in 27 files changed: 314 ins; 214 del; 138 mod

8269039: Disable SHA-1 Signed JARs

Reviewed-by: weijun

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

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

From prappo at openjdk.java.net  Tue Sep 21 13:57:37 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 13:57:37 GMT
Subject: RFR: 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: <AoXEmK_4i4YP_NqliYcB8OOLOWHWiHXbxWJAMKaWus8=.2483cbfc-bf3e-4590-8559-bd9b5dcd7087@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 will need to be thoroughly tested to make sure there were no implicit dependencies on now-removed happens-before edges (`initCause` is synchronized). That said, the idea behind this clean-up looks good.

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

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

From weijun at openjdk.java.net  Tue Sep 21 14:12:31 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 21 Sep 2021 14:12:31 GMT
Subject: RFR: 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: <XyaA05LupX8cVf2QYhqwK9SRP3UI3W2H_eXFfMqNuFo=.4fe7835f-715b-4bac-a8f7-130a26c27b90@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.

Looks fine. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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

From darcy at openjdk.java.net  Tue Sep 21 15:59:34 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 21 Sep 2021 15:59:34 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
Message-ID: <xoNGJXS5XwEYs9zesEQYKXJpXW8vJQLs0KoC_PqBnkg=.2af72d30-8de7-4a9a-ae11-e6ae60407c55@github.com>

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Marked as reviewed by darcy (Reviewer).

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

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

From sviswanathan at openjdk.java.net  Tue Sep 21 16:42:35 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 21 Sep 2021 16:42:35 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
Message-ID: <LU5wpVHw_maH_nGMobK6-lL3F6H8WlTf6m-cs43A30s=.e6f292b1-a995-47e4-a51d-20a230c46365@github.com>

On Mon, 20 Sep 2021 05:16:16 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 588:

> 586:                     ctOfs+len, out, outOfs+len, gctr, ghash);
> 587:                 len+= partlen;
> 588:                 inLen-= len;

This should be inLen -= partlen;

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

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

From iris at openjdk.java.net  Tue Sep 21 16:45:31 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 21 Sep 2021 16:45:31 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
Message-ID: <K3Ug5e2vFA1phSUoWqCm4hl123bWR0WvPUR243euGbo=.9a9dc05e-3073-4344-ae95-3a59ed8b62d0@github.com>

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Marked as reviewed by iris (Reviewer).

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

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

From bpb at openjdk.java.net  Tue Sep 21 16:51:35 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 21 Sep 2021 16:51:35 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
Message-ID: <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

src/java.base/share/classes/java/lang/Throwable.java line 68:

> 66:  * Further, doing so would tie the API of the upper layer to the details of
> 67:  * its implementation, assuming the lower layer's exception was a checked
> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception containing a

Are we sure that this should be "wrapping" and not "wrapped?" See also for example `java.security.cert.CertPathValidatorException.`

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

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

From lancea at openjdk.java.net  Tue Sep 21 17:00:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 21 Sep 2021 17:00:31 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
Message-ID: <3CAzfIqzIJ33D1yXtmb_kt_0Qm2gl0BJ48VnsUi9JTA=.6dad803d-4330-46ab-bd99-7e5a0a53da22@github.com>

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Overall looks like a good clean up.  just not sure of "wrapping" vs. "wrapped" given the sentence starts with "Throwing".

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

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

From lancea at openjdk.java.net  Tue Sep 21 17:00:32 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 21 Sep 2021 17:00:32 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
Message-ID: <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>

On Tue, 21 Sep 2021 16:48:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak wording for Throwable constructor parameters
>
> src/java.base/share/classes/java/lang/Throwable.java line 68:
> 
>> 66:  * Further, doing so would tie the API of the upper layer to the details of
>> 67:  * its implementation, assuming the lower layer's exception was a checked
>> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception containing a
> 
> Are we sure that this should be "wrapping" and not "wrapped?" See also for example `java.security.cert.CertPathValidatorException.`

It does seem a bit strange to say "Throwing a wrapping...."

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

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

From prappo at openjdk.java.net  Tue Sep 21 17:13:28 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 17:13:28 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
Message-ID: <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>

On Tue, 21 Sep 2021 16:56:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Throwable.java line 68:
>> 
>>> 66:  * Further, doing so would tie the API of the upper layer to the details of
>>> 67:  * its implementation, assuming the lower layer's exception was a checked
>>> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception containing a
>> 
>> Are we sure that this should be "wrapping" and not "wrapped?" See also for example `java.security.cert.CertPathValidatorException.`
>
> It does seem a bit strange to say "Throwing a wrapping...."

If we have two exceptions A and B, such that B is the cause of A, then A is the wrapping exception (the one that wraps or the wrapper) and B is the wrapped exception (the one that is being wrapped or the wrappee).

I noticed that the sentence was conflicting: it started with the "wrapped" exception, but then in the "i.e." commentary in parentheses proceeded with the wrappee exception. To resolve that conflict, I proposed to rephrase the first part of that sentence. FWIW, my original suggestion elsewhere was to use "wrapper".

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

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

From bpb at openjdk.java.net  Tue Sep 21 17:13:28 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 21 Sep 2021 17:13:28 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
Message-ID: <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>

On Tue, 21 Sep 2021 17:07:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> It does seem a bit strange to say "Throwing a wrapping...."
>
> If we have two exceptions A and B, such that B is the cause of A, then A is the wrapping exception (the one that wraps or the wrapper) and B is the wrapped exception (the one that is being wrapped or the wrappee).
> 
> I noticed that the sentence was conflicting: it started with the "wrapped" exception, but then in the "i.e." commentary in parentheses proceeded with the wrappee exception. To resolve that conflict, I proposed to rephrase the first part of that sentence. FWIW, my original suggestion elsewhere was to use "wrapper".

Subjectively, "wrapping exception" would seem to be an exception in the process of wrapping something.

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

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

From prappo at openjdk.java.net  Tue Sep 21 17:17:31 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 17:17:31 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
 <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
Message-ID: <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>

On Tue, 21 Sep 2021 17:10:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> If we have two exceptions A and B, such that B is the cause of A, then A is the wrapping exception (the one that wraps or the wrapper) and B is the wrapped exception (the one that is being wrapped or the wrappee).
>> 
>> I noticed that the sentence was conflicting: it started with the "wrapped" exception, but then in the "i.e." commentary in parentheses proceeded with the wrappee exception. To resolve that conflict, I proposed to rephrase the first part of that sentence. FWIW, my original suggestion elsewhere was to use "wrapper".
>
> Subjectively, "wrapping exception" would seem to be an exception in the process of wrapping something.

Would "wrappER" be better?

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

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

From prappo at openjdk.java.net  Tue Sep 21 17:42:35 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 17:42:35 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
 <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
 <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>
Message-ID: <B0nuyuH5rXu7eWV_UwetsjV-CzUhtSeEv4qWwL978fQ=.c30e5197-89af-410c-9c17-7148a24ece30@github.com>

On Tue, 21 Sep 2021 17:14:31 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Subjectively, "wrapping exception" would seem to be an exception in the process of wrapping something.
>
> Would "wrappER" be better?

We can either revert this part of the change or rephrase it. Mind you, rephrasing might prove tricky because of non-local changes it might introduce. There's one more occurrence of "wrapped exception" in this file: https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554

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

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

From bpb at openjdk.java.net  Tue Sep 21 17:55:30 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 21 Sep 2021 17:55:30 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <B0nuyuH5rXu7eWV_UwetsjV-CzUhtSeEv4qWwL978fQ=.c30e5197-89af-410c-9c17-7148a24ece30@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
 <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
 <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>
 <B0nuyuH5rXu7eWV_UwetsjV-CzUhtSeEv4qWwL978fQ=.c30e5197-89af-410c-9c17-7148a24ece30@github.com>
Message-ID: <TH6I77SS1kKwEmUg2IK7GgPVqdo9uD_pdY5DRypNdPk=.6a9d0735-1257-4291-b8f4-2a4650f203da@github.com>

On Tue, 21 Sep 2021 17:39:41 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Would "wrappER" be better?
>
> We can either revert this part of the change or rephrase it. Mind you, rephrasing might prove tricky because of non-local changes it might introduce. There's one more occurrence of "wrapped exception" in this file: https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554

Instead of "common case where a wrapped exception is thrown from same method" could one write "common case where an enclosing exception is thrown from the same method"?

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

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

From svkamath at openjdk.java.net  Tue Sep 21 18:31:12 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 21 Sep 2021 18:31:12 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v3]
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <Wj9960cQ2rswfKpv7ek6Z5ePWWn9Z4XihoQYzJIUR0E=.1937dbbb-6cc2-4bd5-8385-d4c619ffe7b0@github.com>

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

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

  Fixed length decrement issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5402/files
  - new: https://git.openjdk.java.net/jdk/pull/5402/files/7ea464ae..19b0d547

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

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

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

From svkamath at openjdk.java.net  Tue Sep 21 18:31:14 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 21 Sep 2021 18:31:14 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <LU5wpVHw_maH_nGMobK6-lL3F6H8WlTf6m-cs43A30s=.e6f292b1-a995-47e4-a51d-20a230c46365@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
 <LU5wpVHw_maH_nGMobK6-lL3F6H8WlTf6m-cs43A30s=.e6f292b1-a995-47e4-a51d-20a230c46365@github.com>
Message-ID: <kIVt_ysJsVh138Jwsh7OxpKIlIe6uXb442IWxm7msDg=.ca8e7e34-da34-47a1-9ec6-baa4849130ad@github.com>

On Tue, 21 Sep 2021 16:37:49 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 588:
> 
>> 586:                     ctOfs+len, out, outOfs+len, gctr, ghash);
>> 587:                 len+= partlen;
>> 588:                 inLen-= len;
> 
> This should be inLen -= partlen;

Done. Thank you for pointing this out.

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

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

From sviswanathan at openjdk.java.net  Tue Sep 21 19:10:34 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 21 Sep 2021 19:10:34 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v3]
In-Reply-To: <Wj9960cQ2rswfKpv7ek6Z5ePWWn9Z4XihoQYzJIUR0E=.1937dbbb-6cc2-4bd5-8385-d4c619ffe7b0@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <Wj9960cQ2rswfKpv7ek6Z5ePWWn9Z4XihoQYzJIUR0E=.1937dbbb-6cc2-4bd5-8385-d4c619ffe7b0@github.com>
Message-ID: <PZeyr32LEbteXHWo3sc5JwfWwi2_R7pPblxD-HI1TOM=.9428d183-a0dd-49bc-b5b8-bcd41cc37297@github.com>

On Tue, 21 Sep 2021 18:31:12 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed length decrement issue

Marked as reviewed by sviswanathan (Reviewer).

The patch looks good to me.

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

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

From svkamath at openjdk.java.net  Tue Sep 21 19:43:15 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 21 Sep 2021 19:43:15 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
 <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
Message-ID: <CE0N5srWJAHzFKLHA_JgSQv4XbQlU3CTSukoqMaDQpM=.a6151003-d06d-47b5-87b1-9dcaf340b5e8@github.com>

On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries
>
> I approve the jdk changes.   You'll need a hotspot reviewer to approve the other changes

@ascarpino Could you please run tier 1-3 tests? We have two reviewers for the patch.

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

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

From anthony.scarpino at oracle.com  Tue Sep 21 20:12:18 2021
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 21 Sep 2021 13:12:18 -0700
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <CE0N5srWJAHzFKLHA_JgSQv4XbQlU3CTSukoqMaDQpM=.a6151003-d06d-47b5-87b1-9dcaf340b5e8@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
 <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
 <CE0N5srWJAHzFKLHA_JgSQv4XbQlU3CTSukoqMaDQpM=.a6151003-d06d-47b5-87b1-9dcaf340b5e8@github.com>
Message-ID: <9e21f013-f408-ffca-3c70-93216c0d4b80@oracle.com>

I'll run them.. Did you seem my comments?  They are just code-style comments

thanks

Tony

On 9/21/21 12:43 PM, Smita Kamath wrote:
> On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:
> 
>>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries
>>
>> I approve the jdk changes.   You'll need a hotspot reviewer to approve the other changes
> 
> @ascarpino Could you please run tier 1-3 tests? We have two reviewers for the patch.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5402
> 

From svkamath at openjdk.java.net  Tue Sep 21 20:20:06 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 21 Sep 2021 20:20:06 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
 <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
Message-ID: <x8rmMPcl1xIrADGJCfivmt2MkIy_1LfQMDniAoxKG1s=.c789f020-abf0-4243-b92e-656c22072eb7@github.com>

On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries
>
> I approve the jdk changes.   You'll need a hotspot reviewer to approve the other changes

@ascarpino I dont see your comments on this PR. Could you please post them again?

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

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

From dholmes at openjdk.java.net  Tue Sep 21 22:03:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Sep 2021 22:03:57 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <TH6I77SS1kKwEmUg2IK7GgPVqdo9uD_pdY5DRypNdPk=.6a9d0735-1257-4291-b8f4-2a4650f203da@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
 <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
 <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>
 <B0nuyuH5rXu7eWV_UwetsjV-CzUhtSeEv4qWwL978fQ=.c30e5197-89af-410c-9c17-7148a24ece30@github.com>
 <TH6I77SS1kKwEmUg2IK7GgPVqdo9uD_pdY5DRypNdPk=.6a9d0735-1257-4291-b8f4-2a4650f203da@github.com>
Message-ID: <tvr2txgcqa7wfalrATy91xDxLBH3-FZV-gRnCcqXXpI=.45685d5e-4475-42e4-810b-e17f83541fff@github.com>

On Tue, 21 Sep 2021 17:52:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> We can either revert this part of the change or rephrase it. Mind you, rephrasing might prove tricky because of non-local changes it might introduce. There's one more occurrence of "wrapped exception" in this file: https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554
>
> Instead of "common case where a wrapped exception is thrown from same method" could one write "common case where an enclosing exception is thrown from the same method"?

Note that we don't throw the "wrapped exception" we throw the exception that wraps it. The "wrapped exception" is the original cause. The wording as presented now is correct in that regard. You could also say "Throwing a wrapper exception (i.e. one that has a cause)" - I think both are grammatically correct.

The later text "where a wrapped exception is thrown from the same method" is again incorrect because the wrapped exception (the cause) is not what gets thrown. But I find that whole sentence rather jarring anyway - I'm not certain exactly what it means.

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

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

From svkamath at openjdk.java.net  Tue Sep 21 22:16:37 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 21 Sep 2021 22:16:37 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v4]
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <nHeePrFaQZpEnOLAxCuJW36qe03Mf48Nsolklv-3VvY=.9a0d9a09-2635-488d-bc51-d7f8bb0e8bab@github.com>

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

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

  Fixed code-style standard to have a space between plus, minus and combo operators

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5402/files
  - new: https://git.openjdk.java.net/jdk/pull/5402/files/19b0d547..8756d301

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

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

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

From svkamath at openjdk.java.net  Tue Sep 21 22:16:40 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 21 Sep 2021 22:16:40 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
 <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
Message-ID: <PrmPMdqcjZ01N5SNxmN1N9Bt44qXdZXYuWHWkQKBj7c=.28c6dd34-f0ff-43b1-908d-54f07f6a7d4b@github.com>

On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries
>
> I approve the jdk changes.   You'll need a hotspot reviewer to approve the other changes

@ascarpino I've modified the code style. Thank you.

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

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

From prappo at openjdk.java.net  Wed Sep 22 10:27:09 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 10:27:09 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <tvr2txgcqa7wfalrATy91xDxLBH3-FZV-gRnCcqXXpI=.45685d5e-4475-42e4-810b-e17f83541fff@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
 <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
 <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>
 <B0nuyuH5rXu7eWV_UwetsjV-CzUhtSeEv4qWwL978fQ=.c30e5197-89af-410c-9c17-7148a24ece30@github.com>
 <TH6I77SS1kKwEmUg2IK7GgPVqdo9uD_pdY5DRypNdPk=.6a9d0735-1257-4291-b8f4-2a4650f203da@github.com>
 <tvr2txgcqa7wfalrATy91xDxLBH3-FZV-gRnCcqXXpI=.45685d5e-4475-42e4-810b-e17f83541fff@github.com>
Message-ID: <Oq-RED_BEyPNrZHjhS4hODigNICjxcBZlCZIXz-H1-Q=.95fefe9f-cd1b-4593-9ffd-641cedcbf4d1@github.com>

On Tue, 21 Sep 2021 22:00:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Instead of "common case where a wrapped exception is thrown from same method" could one write "common case where an enclosing exception is thrown from the same method"?
>
> Note that we don't throw the "wrapped exception" we throw the exception that wraps it. The "wrapped exception" is the original cause. The wording as presented now is correct in that regard. You could also say "Throwing a wrapper exception (i.e. one that has a cause)" - I think both are grammatically correct.
> 
> The later text "where a wrapped exception is thrown from the same method" is again incorrect because the wrapped exception (the cause) is not what gets thrown. But I find that whole sentence rather jarring anyway - I'm not certain exactly what it means.

I'm inclined to revert this change on Throwable.java:68, because of the lack of consensus. It clearly is not a simple typo.

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

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

From jpai at openjdk.java.net  Wed Sep 22 10:45:24 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 22 Sep 2021 10:45:24 GMT
Subject: RFR: 8273894: ConcurrentModificationException raised every time
 ReferralsCache drops referral
Message-ID: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>

Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8273894?

Given the nature of the code in `ReferralsCache`, I haven't been able to add a new jtreg test case to reproduce the issue and verify this fix. Just to be sure that this change indeed fixes a reproducible issue, I replicated that code in a pretty trivial Java application and then verified a similar fix.

Existing tests in `test/jdk/sun/security/krb5/auto/` continue to pass after this change.

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

Commit messages:
 - 8273894: ConcurrentModificationException raised every time ReferralsCache drops referral

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

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

From shade at openjdk.java.net  Wed Sep 22 11:10:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 22 Sep 2021 11:10:54 GMT
Subject: RFR: 8273894: ConcurrentModificationException raised every time
 ReferralsCache drops referral
In-Reply-To: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
References: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
Message-ID: <ZDK2rNjWqNqQA_RICM3aWjxQrx54I9McOTam-9-f0IU=.288edf67-32f2-402e-8a33-7d792ea0a2da@github.com>

On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
> 
> Given the nature of the code in `ReferralsCache`, I haven't been able to add a new jtreg test case to reproduce the issue and verify this fix. Just to be sure that this change indeed fixes a reproducible issue, I replicated that code in a pretty trivial Java application and then verified a similar fix.
> 
> Existing tests in `test/jdk/sun/security/krb5/auto/` continue to pass after this change.

This seems to trace back all the way to initial integration with JDK-8215032. The bug and the fix are understandable. Looks good! @martinuy, who I think is the original author, should ack too.

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

Marked as reviewed by shade (Reviewer).

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

From prappo at openjdk.java.net  Wed Sep 22 13:01:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 13:01:34 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v3]
In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
Message-ID: <V9NoBqX989uyGJMehOKHM4DuqdiL1jhlhhQAnpI6x3k=.e824792c-08dc-4201-89e9-088ac30a706c@github.com>

> 8274075: Fix miscellaneous typos in java.base

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

 - Fix "non-white space"
   
   JDK predominantly uses "non-whitespace". There's only one more use of "non-white space", in com/sun/tools/javac/tree/DocTreeMaker.java:716, which will go away soon.
 - Undo "wrapped" -> "wrapping"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5610/files
  - new: https://git.openjdk.java.net/jdk/pull/5610/files/19b6f496..05505d97

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

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

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

From prappo at openjdk.java.net  Wed Sep 22 13:01:37 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 13:01:37 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
Message-ID: <VhJX5dogLLrZLpCOFo9369LFUZAA3hPw13X2BmKUxpQ=.2d2a4fe2-721e-424d-ab5f-67523dd0d989@github.com>

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Please re-review this change since I've added two commits.

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

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

From prappo at openjdk.java.net  Wed Sep 22 13:01:39 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 13:01:39 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2]
In-Reply-To: <Oq-RED_BEyPNrZHjhS4hODigNICjxcBZlCZIXz-H1-Q=.95fefe9f-cd1b-4593-9ffd-641cedcbf4d1@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <vDG4_So8MMX1xxWZoRuTi8gkchBr8vURmpHLWDIH1DI=.1b133813-e6fc-4034-81e5-a6b032ad5cd9@github.com>
 <fAScsBsC9lBa6XW4JzEBYoLMZ6QaEdzcoeolGWSUMF4=.9040b073-f36b-4b2a-8dd0-0946e2a83820@github.com>
 <N2laDudrdARu8ASDNTl7zhHdtqQGrqmCvQYVMiTvoyw=.f741dae4-d63a-4123-93fa-b32ad00b0550@github.com>
 <O0o46cXaoaoHcfnrWEOE53enGtlth59640EV-GfwAmo=.d7288bde-92f5-436d-afae-891a7388f126@github.com>
 <Re3iFZl_NMiiwAFWXqswYDO71aXUhTA6XbD0CY1gM3k=.a03d6d00-43cf-477a-b4e5-10efa23331e1@github.com>
 <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com>
 <B0nuyuH5rXu7eWV_UwetsjV-CzUhtSeEv4qWwL978fQ=.c30e5197-89af-410c-9c17-7148a24ece30@github.com>
 <TH6I77SS1kKwEmUg2IK7GgPVqdo9uD_pdY5DRypNdPk=.6a9d0735-1257-4291-b8f4-2a4650f203da@github.com>
 <tvr2txgcqa7wfalrATy91xDxLBH3-FZV-gRnCcqXXpI=.45685d5e-4475-42e4-810b-e17f83541fff@github.com>
 <Oq-RED_BEyPNrZHjhS4hODigNICjxcBZlCZ
 IXz-H1-Q=.95fefe9f-cd1b-4593-9ffd-641cedcbf4d1@github.com>
Message-ID: <G13rVWY6TOOraXok0EuH8vk9F4aEgdnN-jI5BdAOwmY=.ed336f1d-633f-4186-8edd-24a2a400c02e@github.com>

On Wed, 22 Sep 2021 10:24:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Note that we don't throw the "wrapped exception" we throw the exception that wraps it. The "wrapped exception" is the original cause. The wording as presented now is correct in that regard. You could also say "Throwing a wrapper exception (i.e. one that has a cause)" - I think both are grammatically correct.
>> 
>> The later text "where a wrapped exception is thrown from the same method" is again incorrect because the wrapped exception (the cause) is not what gets thrown. But I find that whole sentence rather jarring anyway - I'm not certain exactly what it means.
>
> I'm inclined to revert this change on Throwable.java:68, because of the lack of consensus. It clearly is not a simple typo.

Reverted in 57b71c5.

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

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

From lancea at openjdk.java.net  Wed Sep 22 13:09:54 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 22 Sep 2021 13:09:54 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v3]
In-Reply-To: <V9NoBqX989uyGJMehOKHM4DuqdiL1jhlhhQAnpI6x3k=.e824792c-08dc-4201-89e9-088ac30a706c@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <V9NoBqX989uyGJMehOKHM4DuqdiL1jhlhhQAnpI6x3k=.e824792c-08dc-4201-89e9-088ac30a706c@github.com>
Message-ID: <x6KilRsfiNP8c4WMBwXoapOxCcKvBCNWwglMOIreTqk=.e87b2ef7-db2c-4662-b4ba-52d9ccaa8973@github.com>

On Wed, 22 Sep 2021 13:01:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix "non-white space"
>    
>    JDK predominantly uses "non-whitespace". There's only one more use of "non-white space", in com/sun/tools/javac/tree/DocTreeMaker.java:716, which will go away soon.
>  - Undo "wrapped" -> "wrapping"

Marked as reviewed by lancea (Reviewer).

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

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

From mbalao at openjdk.java.net  Wed Sep 22 13:12:51 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Wed, 22 Sep 2021 13:12:51 GMT
Subject: RFR: 8273894: ConcurrentModificationException raised every time
 ReferralsCache drops referral
In-Reply-To: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
References: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
Message-ID: <QFd3JL0ZVbud74BfdlE6rk0yK7so1brjGqs8uJWQCtM=.ee31c65a-f558-4bad-a804-569bd9d99fa9@github.com>

On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
> 
> Given the nature of the code in `ReferralsCache`, I haven't been able to add a new jtreg test case to reproduce the issue and verify this fix. Just to be sure that this change indeed fixes a reproducible issue, I replicated that code in a pretty trivial Java application and then verified a similar fix.
> 
> Existing tests in `test/jdk/sun/security/krb5/auto/` continue to pass after this change.

Hi,

Thanks for contributing this fix. I'm not an official Reviewer for JDK main line but your fix looks good to me.

Martin.-

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

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

From prappo at openjdk.java.net  Wed Sep 22 15:38:33 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 15:38:33 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4]
In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
Message-ID: <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>

> 8274075: Fix miscellaneous typos in java.base

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

  Add missing "the"
  
  (Spotted by Brian Burkhalter.)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5610/files
  - new: https://git.openjdk.java.net/jdk/pull/5610/files/05505d97..fa81cacd

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

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

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

From lancea at openjdk.java.net  Wed Sep 22 15:38:39 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 22 Sep 2021 15:38:39 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4]
In-Reply-To: <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>
Message-ID: <TPnqW33jHlMjwEuVw-jB_6WrN78AMb8N7sgJEDLejrE=.983430d9-b8cb-44a7-83e9-8928ff2b9ebd@github.com>

On Wed, 22 Sep 2021 15:35:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing "the"
>   
>   (Spotted by Brian Burkhalter.)

Marked as reviewed by lancea (Reviewer).

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

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

From bpb at openjdk.java.net  Wed Sep 22 16:42:56 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 22 Sep 2021 16:42:56 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4]
In-Reply-To: <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>
Message-ID: <ZpzGLUslyyjxcOVi7Ep3EmdcqCpJEOpcKqSqigQYzT0=.2556a5dd-5428-41e3-a1f2-88be6b1442ff@github.com>

On Wed, 22 Sep 2021 15:38:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing "the"
>   
>   (Spotted by Brian Burkhalter.)

Marked as reviewed by bpb (Reviewer).

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

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

From kabirmustafa10 at gmail.com  Tue Sep 21 21:58:54 2021
From: kabirmustafa10 at gmail.com (Mustafa Kabir)
Date: Wed, 22 Sep 2021 03:58:54 +0600
Subject: [9] RFR 8137068: Tests added in JDK-8048604 fail to
 compile/https://www.facebook.com/mustafakabir.5815
Message-ID: <CAPGka4VQB1s3BsaVckxcW9=72gfZooAOv=__xd8NZDAjv-m2eA@mail.gmail.com>

mustafakabir at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210922/59d42d38/attachment.htm>

From iris at openjdk.java.net  Wed Sep 22 18:00:56 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 22 Sep 2021 18:00:56 GMT
Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4]
In-Reply-To: <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
 <qBl6YRGP4Jg9T-fAAJkVS0uQ6XhuRryTj4HLXXv6yI0=.0ba210da-9897-4f3f-8be2-c0ac41788712@github.com>
Message-ID: <d1MYdB4I3XB_iadobPri_EzCX6UoID3-YLinjbATSdY=.5dc77bd4-8f66-4759-b684-fb4d61efa765@github.com>

On Wed, 22 Sep 2021 15:38:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing "the"
>   
>   (Spotted by Brian Burkhalter.)

Marked as reviewed by iris (Reviewer).

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

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

From svkamath at openjdk.java.net  Wed Sep 22 22:48:32 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Wed, 22 Sep 2021 22:48:32 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v5]
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

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

  Added htbl_entries constant to other architectures

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5402/files
  - new: https://git.openjdk.java.net/jdk/pull/5402/files/8756d301..59b1b910

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

  Stats: 16 lines in 6 files changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5402/head:pull/5402

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

From jpai at openjdk.java.net  Thu Sep 23 05:37:50 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 23 Sep 2021 05:37:50 GMT
Subject: RFR: 8273894: ConcurrentModificationException raised every time
 ReferralsCache drops referral
In-Reply-To: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
References: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
Message-ID: <5yhp8Q-a0K3JtM3PLYSzwJ8AnVkIgDDaSjsXhGrw6eA=.d47631c8-6ed7-465d-9bd2-5985f1add78f@github.com>

On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
> 
> Given the nature of the code in `ReferralsCache`, I haven't been able to add a new jtreg test case to reproduce the issue and verify this fix. Just to be sure that this change indeed fixes a reproducible issue, I replicated that code in a pretty trivial Java application and then verified a similar fix.
> 
> Existing tests in `test/jdk/sun/security/krb5/auto/` continue to pass after this change.

Thank you Martin and Aleksey for the reviews.

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

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

From jpai at openjdk.java.net  Thu Sep 23 05:40:58 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 23 Sep 2021 05:40:58 GMT
Subject: Integrated: 8273894: ConcurrentModificationException raised every
 time ReferralsCache drops referral
In-Reply-To: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
References: <E7dLwYVblQYHNnQw1oKiyotWNxhMroUGfl-z_D9iTQk=.f77c2f75-7ba3-48f7-96d3-248956a1df09@github.com>
Message-ID: <Y0YOLI-eNGjufeRZ_Xr0LO5onrhrpYz1EBVrkj90uME=.bcde5e93-9bfb-46e4-b4fc-a35ff4373e0a@github.com>

On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
> 
> Given the nature of the code in `ReferralsCache`, I haven't been able to add a new jtreg test case to reproduce the issue and verify this fix. Just to be sure that this change indeed fixes a reproducible issue, I replicated that code in a pretty trivial Java application and then verified a similar fix.
> 
> Existing tests in `test/jdk/sun/security/krb5/auto/` continue to pass after this change.

This pull request has now been integrated.

Changeset: 2166ed13
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2166ed136917bb68f8155a25e4f4a6c5c7115566
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8273894: ConcurrentModificationException raised every time ReferralsCache drops referral

Reviewed-by: shade

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

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

From prappo at openjdk.java.net  Thu Sep 23 08:12:58 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 23 Sep 2021 08:12:58 GMT
Subject: Integrated: 8274075: Fix miscellaneous typos in java.base
In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com>
Message-ID: <VYVW1QltK_jT0EOcI8AG0FwviboMkfqmGOw8N2fvFRA=.205c1c02-b44d-4a01-ba6d-3a64477ca192@github.com>

On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8274075: Fix miscellaneous typos in java.base

This pull request has now been integrated.

Changeset: 87998565
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8799856528f5804b616b734caed3fc4ba9811bfa
Stats:     26 lines in 9 files changed: 0 ins; 1 del; 25 mod

8274075: Fix miscellaneous typos in java.base

Reviewed-by: dfuchs, darcy, iris, lancea, bpb

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

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

From weijun at openjdk.java.net  Thu Sep 23 14:39:21 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 23 Sep 2021 14:39:21 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
Message-ID: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@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.

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

Commit messages:
 - 8273670: Remove weak etypes from default krb5 etype list

Changes: https://git.openjdk.java.net/jdk/pull/5654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273670
  Stats: 186 lines in 7 files changed: 86 ins; 61 del; 39 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 abakhtin at openjdk.java.net  Thu Sep 23 17:02:09 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 23 Sep 2021 17:02:09 GMT
Subject: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
Message-ID: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>

The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
sun/security/krb5 tests passed

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

Commit messages:
 - 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC

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

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

From weijun at openjdk.java.net  Thu Sep 23 18:21:56 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 23 Sep 2021 18:21:56 GMT
Subject: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
In-Reply-To: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
References: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
Message-ID: <IgxDf_gVUH3d0KklVJV6suKdrc-gFSMrTKrjH64OVg0=.40f1ca00-11c6-4faa-80e7-92bcec185bd2@github.com>

On Thu, 23 Sep 2021 16:52:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
> sun/security/krb5 tests passed

The code change looks fine to me. I'd like to contribute a regression test. Please wait for several hours.

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

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

From weijun at openjdk.java.net  Thu Sep 23 19:34:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 23 Sep 2021 19:34:58 GMT
Subject: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
In-Reply-To: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
References: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
Message-ID: <p7jekV-eDvcDxk6zw10nBDw9mNhkeM_2XoY_BLXD8TM=.7e6c3ff7-73fe-4b73-8d7e-238671acc46a@github.com>

On Thu, 23 Sep 2021 16:52:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
> sun/security/krb5 tests passed

Here it is. Feel free to modify it.`test/jdk/sun/security/krb5/auto/Unavailable.java`:


/*
 * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * @test
 * @bug 8274205
 * @summary Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
 * @library /test/lib
 * @compile -XDignore.symbol.file Unavailable.java
 * @run main jdk.test.lib.FileInstaller TestHosts TestHosts
 * @run main/othervm -Djdk.net.hosts.file=TestHosts Unavailable
 */

import sun.security.krb5.Config;
import sun.security.krb5.PrincipalName;
import sun.security.krb5.internal.KRBError;
import sun.security.krb5.internal.KerberosTime;

import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Locale;

public class Unavailable {

    public static void main(String[] args) throws Exception {

        // Good KDC
        KDC kdc1 = KDC.create(OneKDC.REALM);
        kdc1.addPrincipal(OneKDC.USER, OneKDC.PASS);
        kdc1.addPrincipalRandKey("krbtgt/" + OneKDC.REALM);

        // The "not available" KDC
        KDC kdc2 = new KDC(OneKDC.REALM, "kdc." + OneKDC.REALM.toLowerCase(Locale.US), 0, true) {
            @Override
            protected byte[] processAsReq(byte[] in) throws Exception {
                KRBError err = new KRBError(null, null, null,
                        KerberosTime.now(), 0,
                        29, // KDC_ERR_SVC_UNAVAILABLE
                        null, new PrincipalName("krbtgt/" + OneKDC.REALM),
                        null, null);
                return err.asn1Encode();
            }
        };

        Files.write(Path.of(OneKDC.KRB5_CONF), String.format("""
                [libdefaults]
                default_realm = RABBIT.HOLE

                [realms]
                RABBIT.HOLE = {
                    kdc = kdc.rabbit.hole:%d
                    kdc = kdc.rabbit.hole:%d
                }
                """, kdc2.getPort(), kdc1.getPort()).getBytes());
        System.setProperty("java.security.krb5.conf", OneKDC.KRB5_CONF);
        Config.refresh();

        Context.fromUserPass(OneKDC.USER, OneKDC.PASS, false);
    }
}

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 20:03:51 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 20:03:51 GMT
Subject: RFR: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <_e35T5mXP9KYSsJNgNSXAwhj7yHLofOe5gG3PuGe7fs=.6f3c7f2d-b7ac-4bab-a791-c2841248c082@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

Can someone sponsor changes, please? I believe we have enough approvals.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 20:08:58 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 20:08:58 GMT
Subject: Integrated: 8273261: Replace 'while' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com>
Message-ID: <WwQHYISzzPdgEeU5WqYcCzqxBTPmPAhCunv37Fcgf-c=.0d0f2b41-095a-4c97-97c4-6b0d3169df83@github.com>

On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual while loop is used with Iterator to iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

This pull request has now been integrated.

Changeset: 56b8b352
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/56b8b35286634f2d2224ca445bc9f32ff284ae74
Stats:     93 lines in 11 files changed: 1 ins; 50 del; 42 mod

8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

Reviewed-by: dfuchs, rriggs, iris, mullan

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 20:31:16 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 20:31:16 GMT
Subject: RFR: 8273299: Unnecessary Vector usage in java.security.jgss [v2]
In-Reply-To: <EMUNYZNhFdusvuiNNDyfnC50C_7R9__pCJOS7B5N3dI=.3f7382a9-4bfb-4f2a-92f5-5c3f9c537c08@github.com>
References: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>
 <DMaevKvXPZ7hsTkfi1MIK3ZuHWu7plUfjPfF7SlP61M=.a7787910-cd3d-4fea-8549-770769b88819@github.com>
 <EMUNYZNhFdusvuiNNDyfnC50C_7R9__pCJOS7B5N3dI=.3f7382a9-4bfb-4f2a-92f5-5c3f9c537c08@github.com>
Message-ID: <pkdV2SgeindAmxsbe2TL9o8SSkmhEKb8kAVBwUwmb_E=.41ada598-b3f6-450f-a700-233e2a39cf40@github.com>

On Thu, 26 Aug 2021 20:37:59 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java line 574:
>> 
>>> 572:             v.add(st.nextToken());
>>> 573:         }
>>> 574:         final String[] command = new String[v.size()];
>> 
>> Could probably simplify most of these .toArray to simply `var variable = myarraylist.toArray(new ArrayType[0])`
>
> I think it's better to leave it to separate cleanup issue.

Simplified

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 20:31:16 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 20:31:16 GMT
Subject: RFR: 8273299: Unnecessary Vector usage in java.security.jgss [v2]
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: <t1NKC5wdFp9QuxDo81pcZxKaXoE93wOCl0HN45FeUN4=.3a955afe-3c62-4893-827f-eaf33b9d665b@github.com>

> Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.

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

  8273299: Unnecessary Vector usage in java.security.jgss
  use result of toArray to make sure our array is properly filled

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5264/files
  - new: https://git.openjdk.java.net/jdk/pull/5264/files/6ce045aa..91bfda89

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 20:52:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 20:52:09 GMT
Subject: RFR: 8274237: Replace 'for' cycles with iterator with enhanced-for in
 java.base
Message-ID: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>

There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
Sometimes we even don't need cycle at all: we can just create one ArrayList as a copy of another.
It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
This is continuation of [JDK-8273261](https://bugs.openjdk.java.net/browse/JDK-8273261)

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

Commit messages:
 - [PATCH] Replace 'for' cycles with iterator with enhanced-for in java.base

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

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

From svkamath at openjdk.java.net  Thu Sep 23 22:23:52 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Thu, 23 Sep 2021 22:23:52 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v2]
In-Reply-To: <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <mpZwNtfhh7BLve3lIdC0bzrSt3oGBFDyNUA1xunDMQc=.d1e93d93-00ff-4565-946b-6fcc5036bcc0@github.com>
 <MYnPsvQwG0cR2pdcx_O58kUfb2j0Ug3vdVeMEa4-aMM=.43b16003-da36-45c4-b876-e49a20dec7fb@github.com>
Message-ID: <BrPXMy_msvocJRjLmotQ4zU-AvQOdf_yMVe_QWHHZko=.e1b95b39-f72e-46f6-b3d7-089bdb7fc967@github.com>

On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain and added a new constant for htbl entries
>
> I approve the jdk changes.   You'll need a hotspot reviewer to approve the other changes

@ascarpino Is it okay to integrate this patch?

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

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

From sviswanathan at openjdk.java.net  Thu Sep 23 22:23:52 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 23 Sep 2021 22:23:52 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v5]
In-Reply-To: <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>
Message-ID: <wE9krv_Cbl4TrLx53CZeJix6uJ6dqYAm-WGATGYzCJU=.ec9676c2-2b42-4071-bf65-346ff13181df@github.com>

On Wed, 22 Sep 2021 22:48:32 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added htbl_entries constant to other architectures

Hotspot changes look good.

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

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

From valeriep at openjdk.java.net  Fri Sep 24 00:04:56 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 24 Sep 2021 00:04:56 GMT
Subject: RFR: 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: <67MoXLm6Z0mcVK-G_V6p_8mL1um97CGUWhupRJysnao=.3f03ffe4-afad-40a3-8079-10e7669c62b8@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.

I will take a look, thanks~

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

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

From abakhtin at openjdk.java.net  Fri Sep 24 05:33:46 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Sep 2021 05:33:46 GMT
Subject: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
 [v2]
In-Reply-To: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
References: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
Message-ID: <srI8G0BMYf7bQzNB6drqaCpl14_AKEuL3ClXpBTcPXs=.d314eb44-0b61-41fe-bef4-365ddd695e03@github.com>

> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
> sun/security/krb5 tests passed

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

  Added Unavailable test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5658/files
  - new: https://git.openjdk.java.net/jdk/pull/5658/files/6bf7dfc0..96774140

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

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

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

From abakhtin at openjdk.java.net  Fri Sep 24 05:33:47 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Sep 2021 05:33:47 GMT
Subject: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
In-Reply-To: <p7jekV-eDvcDxk6zw10nBDw9mNhkeM_2XoY_BLXD8TM=.7e6c3ff7-73fe-4b73-8d7e-238671acc46a@github.com>
References: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
 <p7jekV-eDvcDxk6zw10nBDw9mNhkeM_2XoY_BLXD8TM=.7e6c3ff7-73fe-4b73-8d7e-238671acc46a@github.com>
Message-ID: <o7wBBvHBbWj6WWhcq6RBRtCNJhRYW3VpP2irEeSFWFE=.900e2214-1ecb-4cfd-81b2-354d85a64fbf@github.com>

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

>> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
>> sun/security/krb5 tests passed
>
> Here it is. Feel free to modify it.`test/jdk/sun/security/krb5/auto/Unavailable.java`:
> 
> 
> /*
>  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
> 
> /*
>  * @test
>  * @bug 8274205
>  * @summary Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
>  * @library /test/lib
>  * @compile -XDignore.symbol.file Unavailable.java
>  * @run main jdk.test.lib.FileInstaller TestHosts TestHosts
>  * @run main/othervm -Djdk.net.hosts.file=TestHosts Unavailable
>  */
> 
> import sun.security.krb5.Config;
> import sun.security.krb5.PrincipalName;
> import sun.security.krb5.internal.KRBError;
> import sun.security.krb5.internal.KerberosTime;
> 
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.util.Locale;
> 
> public class Unavailable {
> 
>     public static void main(String[] args) throws Exception {
> 
>         // Good KDC
>         KDC kdc1 = KDC.create(OneKDC.REALM);
>         kdc1.addPrincipal(OneKDC.USER, OneKDC.PASS);
>         kdc1.addPrincipalRandKey("krbtgt/" + OneKDC.REALM);
> 
>         // The "not available" KDC
>         KDC kdc2 = new KDC(OneKDC.REALM, "kdc." + OneKDC.REALM.toLowerCase(Locale.US), 0, true) {
>             @Override
>             protected byte[] processAsReq(byte[] in) throws Exception {
>                 KRBError err = new KRBError(null, null, null,
>                         KerberosTime.now(), 0,
>                         29, // KDC_ERR_SVC_UNAVAILABLE
>                         null, new PrincipalName("krbtgt/" + OneKDC.REALM),
>                         null, null);
>                 return err.asn1Encode();
>             }
>         };
> 
>         Files.write(Path.of(OneKDC.KRB5_CONF), String.format("""
>                 [libdefaults]
>                 default_realm = RABBIT.HOLE
> 
>                 [realms]
>                 RABBIT.HOLE = {
>                     kdc = kdc.rabbit.hole:%d
>                     kdc = kdc.rabbit.hole:%d
>                 }
>                 """, kdc2.getPort(), kdc1.getPort()).getBytes());
>         System.setProperty("java.security.krb5.conf", OneKDC.KRB5_CONF);
>         Config.refresh();
> 
>         Context.fromUserPass(OneKDC.USER, OneKDC.PASS, false);
>     }
> }

@wangweij Thank you a lot for the quick review and test

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

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

From github.com+30433125+djelinski at openjdk.java.net  Fri Sep 24 08:15:10 2021
From: github.com+30433125+djelinski at openjdk.java.net (djelinski)
Date: Fri, 24 Sep 2021 08:15:10 GMT
Subject: RFR: 8274143 Disable "invalid entry for security.provider.X" error
 message in log file when security.provider.X is empty
Message-ID: <KBOYaYxVU__Ha5CPHTGT4vNoITVKORXz2gmjwFBVuVw=.bc3d28c4-df52-4527-bfb4-4789694d7817@github.com>

The default list of providers defined in java.security file can be overridden with a custom file, declared with `-Djava.security.properties=/path/to/custom.security` command line parameter.
If the new list of providers is shorter than the original one, it is necessary to add an empty entry to terminate the list, like:

security.provider.1=BCFIPS C:HYBRID;ENABLE{All}
security.provider.2=SUN
security.provider.3=BCJSSE fips:BCFIPS
security.provider.4=

otherwise some providers from the default list will still be used.

Currently Java outputs an error message on standard error when it encounters an empty entry on the provider list. This PR silences that message.

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

Commit messages:
 - Hide "invalid entry" error message

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

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

From dfuchs at openjdk.java.net  Fri Sep 24 10:30:51 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 24 Sep 2021 10:30:51 GMT
Subject: RFR: 8274237: Replace 'for' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
References: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
Message-ID: <NbtkqvjJXW5sSoGADKuJS0tQe6sK3YAVPmIFBPaowD4=.3cf07fea-b52b-4128-af8c-5cbdb7be7824@github.com>

On Thu, 23 Sep 2021 20:42:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> Sometimes we even don't need cycle at all: we can just create one ArrayList as a copy of another.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8273261](https://bugs.openjdk.java.net/browse/JDK-8273261)

Looks good to me in general. Changes to `sun.net` look very good. Thanks for the simplification!
Please have someone from security-dev give approval before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

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

From weijun at openjdk.java.net  Fri Sep 24 11:26:59 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 11:26:59 GMT
Subject: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC
 [v2]
In-Reply-To: <srI8G0BMYf7bQzNB6drqaCpl14_AKEuL3ClXpBTcPXs=.d314eb44-0b61-41fe-bef4-365ddd695e03@github.com>
References: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
 <srI8G0BMYf7bQzNB6drqaCpl14_AKEuL3ClXpBTcPXs=.d314eb44-0b61-41fe-bef4-365ddd695e03@github.com>
Message-ID: <p6vIf139NkR81MEqdqsBPEtHIxtIn4u0bFSydel_NOc=.a5bb23c5-2e8a-438a-b081-cd6243355b04@github.com>

On Fri, 24 Sep 2021 05:33:46 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
>> sun/security/krb5 tests passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added Unavailable test

Marked as reviewed by weijun (Reviewer).

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

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

From abakhtin at openjdk.java.net  Fri Sep 24 12:13:05 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Sep 2021 12:13:05 GMT
Subject: Integrated: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from
 KDC
In-Reply-To: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
References: <VmZsGatSQuxoYCsjhEAtxN7nppl43Jk0wnZI7xkk-Ss=.ce57bffd-5c63-47a5-b6d1-81ec7079f529@github.com>
Message-ID: <qhxzPECCS8uZqR3OHk4gPnZ20zQLZCqSG9orP1boYs8=.27d0314f-bae8-4615-ad55-940ccb2677f2@github.com>

On Thu, 23 Sep 2021 16:52:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from KDC and resends the initial request to the next KDC in the list. It aligns error code handling with the MIT Kerberos implementation.
> sun/security/krb5 tests passed

This pull request has now been integrated.

Changeset: 5ba0d09f
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ba0d09fe47439880daf913f4ff0b978ed9c1ac6
Stats:     88 lines in 3 files changed: 86 ins; 0 del; 2 mod

8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC

Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: weijun

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

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

From weijun at openjdk.java.net  Fri Sep 24 13:35:01 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 13:35:01 GMT
Subject: RFR: 8274143 Disable "invalid entry for security.provider.X"
 error message in log file when security.provider.X is empty
In-Reply-To: <KBOYaYxVU__Ha5CPHTGT4vNoITVKORXz2gmjwFBVuVw=.bc3d28c4-df52-4527-bfb4-4789694d7817@github.com>
References: <KBOYaYxVU__Ha5CPHTGT4vNoITVKORXz2gmjwFBVuVw=.bc3d28c4-df52-4527-bfb4-4789694d7817@github.com>
Message-ID: <bwfUo2NZNtCT5VSxOnczUou6Ujbm4vK9cWzsjTV4fmE=.ed974884-97fc-48e7-a8eb-4902bc56a15c@github.com>

On Fri, 24 Sep 2021 08:01:07 GMT, Daniel Jeli?ski <github.com+30433125+djelinski at openjdk.org> wrote:

> The default list of providers defined in java.security file can be overridden with a custom file, declared with `-Djava.security.properties=/path/to/custom.security` command line parameter.
> If the new list of providers is shorter than the original one, it is necessary to add an empty entry to terminate the list, like:
> 
> security.provider.1=BCFIPS C:HYBRID;ENABLE{All}
> security.provider.2=SUN
> security.provider.3=BCJSSE fips:BCFIPS
> security.provider.4=
> 
> otherwise some providers from the default list will still be used.
> 
> Currently Java outputs an error message on standard error when it encounters an empty entry on the provider list. This PR silences that message.

Changes looks fine. I've also added a `noreg-trivial` label to the JBS bug.

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

Marked as reviewed by weijun (Reviewer).

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

From weijun at openjdk.java.net  Fri Sep 24 13:37:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 13:37:52 GMT
Subject: RFR: 8274237: Replace 'for' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
References: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
Message-ID: <vs3vvXwLrNdzKDXN-05cABQWZGdj0Udy9LqvDlsGmUI=.ee9dabaf-b858-4ab1-a420-49ddfa7f2a2f@github.com>

On Thu, 23 Sep 2021 20:42:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> Sometimes we even don't need cycle at all: we can just create one ArrayList as a copy of another.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8273261](https://bugs.openjdk.java.net/browse/JDK-8273261)

Changes in the 3 security-related files also look fine. Thanks.

I've also added a `noreg-cleanup` label to the JBS bug.

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

Marked as reviewed by weijun (Reviewer).

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

From weijun at openjdk.java.net  Fri Sep 24 13:45:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 13:45:02 GMT
Subject: RFR: 8273299: Unnecessary Vector usage in java.security.jgss [v2]
In-Reply-To: <t1NKC5wdFp9QuxDo81pcZxKaXoE93wOCl0HN45FeUN4=.3a955afe-3c62-4893-827f-eaf33b9d665b@github.com>
References: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>
 <t1NKC5wdFp9QuxDo81pcZxKaXoE93wOCl0HN45FeUN4=.3a955afe-3c62-4893-827f-eaf33b9d665b@github.com>
Message-ID: <opu1ICHjhJYKSNP1IAJJ1q74_EYqHNqSye1FtaEQ-8U=.1928a52d-be9e-41de-aedf-2087bc81cc3e@github.com>

On Thu, 23 Sep 2021 20:31:16 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273299: Unnecessary Vector usage in java.security.jgss
>   use result of toArray to make sure our array is properly filled

Looks fine to me. I'll run a round of test now.

And BTW, I've added a `noreg-cleanup` label to the bug.

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

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

From dfuchs at openjdk.java.net  Fri Sep 24 14:41:33 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 24 Sep 2021 14:41:33 GMT
Subject: RFR: 8274237: Replace 'for' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
References: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
Message-ID: <OjRseJTz-1Lpq5A4Kl5yL8fcfrzHNjnqdDEjFiFymuo=.a02c0b02-44f1-49af-bf82-409268e05ad2@github.com>

On Thu, 23 Sep 2021 20:42:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> Sometimes we even don't need cycle at all: we can just create one ArrayList as a copy of another.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8273261](https://bugs.openjdk.java.net/browse/JDK-8273261)

I can sponsor the change if you integrate it.

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

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

From ascarpino at openjdk.java.net  Fri Sep 24 16:06:54 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 24 Sep 2021 16:06:54 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v5]
In-Reply-To: <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>
Message-ID: <-WygjWwDsLnk3pjW6ukRb_TukFOY20t_Y7JHQM2rG4U=.6e401872-ce13-411b-bcd3-9a986e8ce45a@github.com>

On Wed, 22 Sep 2021 22:48:32 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added htbl_entries constant to other architectures

I think it's ready to integrate

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

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

From weijun at openjdk.java.net  Fri Sep 24 16:48:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 16:48:02 GMT
Subject: RFR: 8273299: Unnecessary Vector usage in java.security.jgss [v2]
In-Reply-To: <t1NKC5wdFp9QuxDo81pcZxKaXoE93wOCl0HN45FeUN4=.3a955afe-3c62-4893-827f-eaf33b9d665b@github.com>
References: <v5iDK1b2vA9fFiwuuXyrNXWhFGiMh2-EXgyv6_y1bR4=.3d3c1afa-8afc-427f-a3d9-7dd080be3908@github.com>
 <t1NKC5wdFp9QuxDo81pcZxKaXoE93wOCl0HN45FeUN4=.3a955afe-3c62-4893-827f-eaf33b9d665b@github.com>
Message-ID: <BwcRwqYqSsmWoiGxxNwazu9IH0PjrI9DZTwKbkmHU6Q=.f3a649a6-98d9-4b43-8b93-7d5b9e75adba@github.com>

On Thu, 23 Sep 2021 20:31:16 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList if a thread-safe implementation is not needed.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273299: Unnecessary Vector usage in java.security.jgss
>   use result of toArray to make sure our array is properly filled

Marked as reviewed by weijun (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Sep 24 16:49:59 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 24 Sep 2021 16:49:59 GMT
Subject: Integrated: 8274237: Replace 'for' cycles with iterator with
 enhanced-for in java.base
In-Reply-To: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
References: <LZIo64IvDFaO18XceivOCl0lxJcc-GMb3olt5wbClbA=.f1cadb44-8ddc-4c3b-b25e-1da327e5a588@github.com>
Message-ID: <TvXW2r0yQRYe9W2_n4mfvd43ikFvyKoy0XwIx0O4iRk=.9afa5b67-a093-438e-a588-9e41edee0e75@github.com>

On Thu, 23 Sep 2021 20:42:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> Sometimes we even don't need cycle at all: we can just create one ArrayList as a copy of another.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8273261](https://bugs.openjdk.java.net/browse/JDK-8273261)

This pull request has now been integrated.

Changeset: baafa605
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/baafa6059e7aa50978b0b29946fddb8b198a28d2
Stats:     32 lines in 4 files changed: 0 ins; 14 del; 18 mod

8274237: Replace 'for' cycles with iterator with enhanced-for in java.base

Reviewed-by: dfuchs, weijun

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

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

From aph at openjdk.java.net  Fri Sep 24 17:07:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 24 Sep 2021 17:07:56 GMT
Subject: RFR: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
 [v5]
In-Reply-To: <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
 <-FJux8XZG1ra8W4DNa31PEP_pWxoIkVvf9qHyYRSEBM=.5b57d887-c321-4fd0-9c64-9ea2202ac774@github.com>
Message-ID: <Coiq8xlSXRP1j6Vw9WEdBmNktSFYgo1mOPDAfOXfBCw=.784c9990-dd2d-404e-8c95-fd4c394cbc9a@github.com>

On Wed, 22 Sep 2021 22:48:32 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>> 
>> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added htbl_entries constant to other architectures

Marked as reviewed by aph (Reviewer).

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

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

From svkamath at openjdk.java.net  Fri Sep 24 19:25:57 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Fri, 24 Sep 2021 19:25:57 GMT
Subject: Integrated: 8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125
In-Reply-To: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
References: <OX34cy439w0Z7eN48Co7VEum9nKeORO685rCEpzuUyE=.50309ed0-bc2d-47f8-b3b0-4e30e101292b@github.com>
Message-ID: <nOumpaOa7Z-RmWvsSJBqRLMFlUA29nPB8EEs8QWtwOg=.176af8ff-8e49-49e1-806c-61dae60cc9da@github.com>

On Tue, 7 Sep 2021 22:31:30 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
> 
> The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used. This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty. This issue also affects non-Intel CPUs too.

This pull request has now been integrated.

Changeset: 13e9ea9e
Author:    Smita Kamath <svkamath at openjdk.org>
Committer: Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/13e9ea9e922030927775345b1abde1313a6ec03f
Stats:     116 lines in 16 files changed: 60 ins; 2 del; 54 mod

8273297: AES/GCM non-AVX512+VAES CPUs suffer after 8267125

Reviewed-by: ascarpino, sviswanathan, aph

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

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

From mullan at openjdk.java.net  Fri Sep 24 19:54:55 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 24 Sep 2021 19:54:55 GMT
Subject: RFR: 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: <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@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.

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 101:

> 99:         if (allowWeakCrypto) {
> 100:             result[num++] = EncryptedData.ETYPE_DES3_CBC_HMAC_SHA1_KD;
> 101:             result[num++] = EncryptedData.ETYPE_ARCFOUR_HMAC;

MIT still has arcfour-hmac-md5 in the enabled list - do you think there is any reason (compatibility) we should do the same? Note that I think it is better that we don't though. See "permitted_enctypes" at https://web.mit.edu/Kerberos/krb5-1.19/doc/admin/conf_files/krb5_conf.html#libdefaults.

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 242:

> 240:     // used in Config
> 241:     public static int[] getBuiltInDefaults() {
> 242:         return defaultETypes;

It might be safer to return a clone here since it is mutable. The previous code always returned a new array. This array gets passed back to calling code via Etype.getDefaults(), returning a clone would prevent the configured value from being accidentally modified.

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

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

From weijun at openjdk.java.net  Fri Sep 24 21:27:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 21:27:52 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@github.com>
Message-ID: <ADd5oEeJBbIMUDXG2SRvlH6xOORCMuJa_PxEWgNQzD4=.1aa20b37-f0e6-4ff1-b8cc-f15d4b465c4f@github.com>

On Fri, 24 Sep 2021 19:49:14 GMT, Sean Mullan <mullan 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.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 242:
> 
>> 240:     // used in Config
>> 241:     public static int[] getBuiltInDefaults() {
>> 242:         return defaultETypes;
> 
> It might be safer to return a clone here since it is mutable. The previous code always returned a new array. This array gets passed back to calling code via Etype.getDefaults(), returning a clone would prevent the configured value from being accidentally modified.

OK.

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

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

From weijun at openjdk.java.net  Fri Sep 24 21:41:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 24 Sep 2021 21:41:51 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@github.com>
Message-ID: <5uLb66cw3Tn0LCx7zACssSdl1wPKvjWu8iome1k8Ylg=.84a1c4f2-223d-4ab8-b3fd-6a8d976f85d5@github.com>

On Fri, 24 Sep 2021 19:33:12 GMT, Sean Mullan <mullan 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.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 101:
> 
>> 99:         if (allowWeakCrypto) {
>> 100:             result[num++] = EncryptedData.ETYPE_DES3_CBC_HMAC_SHA1_KD;
>> 101:             result[num++] = EncryptedData.ETYPE_ARCFOUR_HMAC;
> 
> MIT still has arcfour-hmac-md5 in the enabled list - do you think there is any reason (compatibility) we should do the same? Note that I think it is better that we don't though. See "permitted_enctypes" at https://web.mit.edu/Kerberos/krb5-1.19/doc/admin/conf_files/krb5_conf.html#libdefaults.

This is because MIT krb5 treats DES as weak and RC4 as deprecated. In Java, we treat both as weak after JDK-8139348 (the title is "Deprecate 3DES and RC4 in Kerberos" but this "deprecate" is not the same as the one in MIT krb5). This means when "allow_weak_crypto = true" we've already removed RC4. Since this code change is about removing weak etypes from the default "permitted_enctypes", we should be consistent.

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

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

From valeriep at openjdk.java.net  Fri Sep 24 21:58:58 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 24 Sep 2021 21:58:58 GMT
Subject: RFR: 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: <7rjxx5qaBEbEmYZDH4DXW1N4WECk-qZ_yS1J0o02go8=.e9fba90d-6ab7-4a76-9e63-e0f64970c8f2@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.

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 85:

> 83: 
> 84:         // By default, only AES etypes are enabled
> 85:         defaultETypes = Arrays.copyOf(result, num);

nit: why not just do:
`        defaultETypes = (maxKeyLength >= 256?
                new int[] {
                    EncryptedData.ETYPE_AES256_CTS_HMAC_SHA1_96,
                    EncryptedData.ETYPE_AES128_CTS_HMAC_SHA1_96,
                    EncryptedData.ETYPE_AES256_CTS_HMAC_SHA384_192,
                    EncryptedData.ETYPE_AES128_CTS_HMAC_SHA256_128,
                } : new int[] {
                    EncryptedData.ETYPE_AES128_CTS_HMAC_SHA1_96,
                    EncryptedData.ETYPE_AES128_CTS_HMAC_SHA256_128,
                });
`

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

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

From valeriep at openjdk.java.net  Fri Sep 24 22:09:56 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 24 Sep 2021 22:09:56 GMT
Subject: RFR: 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: <KllsrTxrhApaO-BccvQMpsum_KRx9j6QeuysBVblFMM=.f1ae0297-4a8f-4f19-ad62-8642cf260d17@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.

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 90:

> 88:         try {
> 89:             Config cfg = Config.getInstance();
> 90:             allowWeakCrypto = cfg.getBooleanObject("libdefaults", "allow_weak_crypto")

nit: exceeds 80 chars?

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 111:

> 109:         } else {
> 110:             supportedETypes = Arrays.copyOf(result, num);
> 111:         }

nit: it seems clearer to base supportedETypes on defaultETypes, e.g.
<pre>        if (allowWeakCrypto) {
            supportedETypes = Arrays.copyOf(defaultETypes,
                defaultETypes.length + 4);
            supportedETypes[defaultETypes.length] =
                    EncryptedData.ETYPE_DES3_CBC_HMAC_SHA1_KD;
            supportedETypes[defaultETypes.length + 1] =
                    EncryptedData.ETYPE_ARCFOUR_HMAC;
            supportedETypes[defaultETypes.length + 2] =
                    EncryptedData.ETYPE_DES_CBC_CRC;
            supportedETypes[defaultETypes.length + 3] =
                    EncryptedData.ETYPE_DES_CBC_MD5;
        } else {
            supportedETypes = defaultETypes;
        }
</pre>

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

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

From valeriep at openjdk.java.net  Fri Sep 24 22:09:56 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 24 Sep 2021 22:09:56 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <5uLb66cw3Tn0LCx7zACssSdl1wPKvjWu8iome1k8Ylg=.84a1c4f2-223d-4ab8-b3fd-6a8d976f85d5@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@github.com>
 <5uLb66cw3Tn0LCx7zACssSdl1wPKvjWu8iome1k8Ylg=.84a1c4f2-223d-4ab8-b3fd-6a8d976f85d5@github.com>
Message-ID: <sD9RktwQOlZXVn01m_v2O58kURFgQKyojRCs4-oqJaU=.224561f7-a25a-4af1-8469-b59991b4f8ac@github.com>

On Fri, 24 Sep 2021 21:38:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 101:
>> 
>>> 99:         if (allowWeakCrypto) {
>>> 100:             result[num++] = EncryptedData.ETYPE_DES3_CBC_HMAC_SHA1_KD;
>>> 101:             result[num++] = EncryptedData.ETYPE_ARCFOUR_HMAC;
>> 
>> MIT still has arcfour-hmac-md5 in the enabled list - do you think there is any reason (compatibility) we should do the same? Note that I think it is better that we don't though. See "permitted_enctypes" at https://web.mit.edu/Kerberos/krb5-1.19/doc/admin/conf_files/krb5_conf.html#libdefaults.
>
> This is because MIT krb5 treats DES as weak and RC4 as deprecated. In Java, we treat both as weak after JDK-8139348 (the title is "Deprecate 3DES and RC4 in Kerberos" but this "deprecate" is not the same as the one in MIT krb5). This means when "allow_weak_crypto = true" we've already removed RC4. Since this code change is about removing weak etypes from the default "permitted_enctypes", we should be consistent.

Perhaps you meant "false" in the sentence below?

> when "allow_weak_crypto = true" we've already removed RC4.

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

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

From valeriep at openjdk.java.net  Fri Sep 24 23:57:53 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 24 Sep 2021 23:57:53 GMT
Subject: RFR: 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: <oE96ZFMAU-jEG9gbTVx__tffFj3kHuNe9CrzgO2feK8=.5ae4cab0-85b1-4a4c-a0f3-1758201694b0@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.

I've reviewed the CSR and made some edit changes. Thanks.

test/jdk/sun/security/krb5/etype/WeakCrypto.java line 54:

> 52:                 18, 17, 20, 19);    // the defaults
> 53: 
> 54:         test(null, "aes256-cts aes128-cts aes256-sha2 aes128-sha2 des3-hmac-sha1 arcfour-hmac des-cbc-crc des-cbc-md5",

nit: save this into a local String variable, e.g. strongAndWeak or allETypes, and reuse this.

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

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

From weijun at openjdk.java.net  Sat Sep 25 00:20:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 25 Sep 2021 00:20:55 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <7rjxx5qaBEbEmYZDH4DXW1N4WECk-qZ_yS1J0o02go8=.e9fba90d-6ab7-4a76-9e63-e0f64970c8f2@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <7rjxx5qaBEbEmYZDH4DXW1N4WECk-qZ_yS1J0o02go8=.e9fba90d-6ab7-4a76-9e63-e0f64970c8f2@github.com>
Message-ID: <XoniNzvtiqv8EGkfM3PZFq-vDYqQ59iY3ezpTIjdXuI=.625744f7-5d8e-43cb-9143-63e92050a7b5@github.com>

On Fri, 24 Sep 2021 21:55:44 GMT, Valerie Peng <valeriep 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.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 85:
> 
>> 83: 
>> 84:         // By default, only AES etypes are enabled
>> 85:         defaultETypes = Arrays.copyOf(result, num);
> 
> nit: why not just do:
> <pre>        defaultETypes = (maxKeyLength >= 256?
>                 new int[] {
>                     EncryptedData.ETYPE_AES256_CTS_HMAC_SHA1_96,
>                     EncryptedData.ETYPE_AES128_CTS_HMAC_SHA1_96,
>                     EncryptedData.ETYPE_AES256_CTS_HMAC_SHA384_192,
>                     EncryptedData.ETYPE_AES128_CTS_HMAC_SHA256_128,
>                 } : new int[] {
>                     EncryptedData.ETYPE_AES128_CTS_HMAC_SHA1_96,
>                     EncryptedData.ETYPE_AES128_CTS_HMAC_SHA256_128,
>                 });
> </pre>

OK, I can code this way.

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

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

From weijun at openjdk.java.net  Sat Sep 25 00:27:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 25 Sep 2021 00:27:53 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <KllsrTxrhApaO-BccvQMpsum_KRx9j6QeuysBVblFMM=.f1ae0297-4a8f-4f19-ad62-8642cf260d17@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <KllsrTxrhApaO-BccvQMpsum_KRx9j6QeuysBVblFMM=.f1ae0297-4a8f-4f19-ad62-8642cf260d17@github.com>
Message-ID: <JYyQ3k1FcOgZRoH92hBbVEQN1L1Uhrlq6vnScwOrA0g=.a37e5c64-ed13-488f-b8d0-73d2fe97c3ab@github.com>

On Fri, 24 Sep 2021 21:59:04 GMT, Valerie Peng <valeriep 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.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 90:
> 
>> 88:         try {
>> 89:             Config cfg = Config.getInstance();
>> 90:             allowWeakCrypto = cfg.getBooleanObject("libdefaults", "allow_weak_crypto")
> 
> nit: exceeds 80 chars?

A little. I've learnt to accept lines a little bit longer than 80.

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

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

From weijun at openjdk.java.net  Sat Sep 25 01:30:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 25 Sep 2021 01:30:53 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <sD9RktwQOlZXVn01m_v2O58kURFgQKyojRCs4-oqJaU=.224561f7-a25a-4af1-8469-b59991b4f8ac@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <0-X6R3_4Dbu6aMbEiMh6oKgyLG6pXQJNsV6am4CF2-Y=.e0c550c7-1405-48af-9dd4-8a002b486c3f@github.com>
 <5uLb66cw3Tn0LCx7zACssSdl1wPKvjWu8iome1k8Ylg=.84a1c4f2-223d-4ab8-b3fd-6a8d976f85d5@github.com>
 <sD9RktwQOlZXVn01m_v2O58kURFgQKyojRCs4-oqJaU=.224561f7-a25a-4af1-8469-b59991b4f8ac@github.com>
Message-ID: <DiZuXuq1ynvy0FlsOKtsBnUiM39A5l1QPDxPE1Smmb8=.4625559f-4f9c-48c6-9e7b-3dc5ddb607c0@github.com>

On Fri, 24 Sep 2021 22:06:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This is because MIT krb5 treats DES as weak and RC4 as deprecated. In Java, we treat both as weak after JDK-8139348 (the title is "Deprecate 3DES and RC4 in Kerberos" but this "deprecate" is not the same as the one in MIT krb5). This means when "allow_weak_crypto = true" we've already removed RC4. Since this code change is about removing weak etypes from the default "permitted_enctypes", we should be consistent.
>
> Perhaps you meant "false" in the sentence below?
> 
>> when "allow_weak_crypto = true" we've already removed RC4.

Yes. Typo.

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

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

From weijun at openjdk.java.net  Sat Sep 25 01:30:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 25 Sep 2021 01:30:54 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list
In-Reply-To: <KllsrTxrhApaO-BccvQMpsum_KRx9j6QeuysBVblFMM=.f1ae0297-4a8f-4f19-ad62-8642cf260d17@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <KllsrTxrhApaO-BccvQMpsum_KRx9j6QeuysBVblFMM=.f1ae0297-4a8f-4f19-ad62-8642cf260d17@github.com>
Message-ID: <p6rWWqw8-N5MrBxtbEO7jJ0nEVmCI3gOeSfawy6IZlM=.5a228171-fbfe-443d-8381-517e66cf1815@github.com>

On Fri, 24 Sep 2021 22:01:26 GMT, Valerie Peng <valeriep 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.
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 111:
> 
>> 109:         } else {
>> 110:             supportedETypes = Arrays.copyOf(result, num);
>> 111:         }
> 
> nit: it seems clearer to base supportedETypes on defaultETypes, e.g.
> <pre>        if (allowWeakCrypto) {
>             supportedETypes = Arrays.copyOf(defaultETypes,
>                 defaultETypes.length + 4);
>             supportedETypes[defaultETypes.length] =
>                     EncryptedData.ETYPE_DES3_CBC_HMAC_SHA1_KD;
>             supportedETypes[defaultETypes.length + 1] =
>                     EncryptedData.ETYPE_ARCFOUR_HMAC;
>             supportedETypes[defaultETypes.length + 2] =
>                     EncryptedData.ETYPE_DES_CBC_CRC;
>             supportedETypes[defaultETypes.length + 3] =
>                     EncryptedData.ETYPE_DES_CBC_MD5;
>         } else {
>             supportedETypes = defaultETypes;
>         }
> </pre>

Yes.

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

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

From weijun at openjdk.java.net  Sat Sep 25 02:38:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 25 Sep 2021 02:38:30 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v2]
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: <QOMVYGUnnCbZ8X50b4GeERJxASRL5KA-QGsi_PDW2lg=.f617dcff-4765-4350-825f-6364ac3cda92@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:

  some rewrite

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5654/files
  - new: https://git.openjdk.java.net/jdk/pull/5654/files/6abcd5bf..7937b069

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

  Stats: 55 lines in 2 files changed: 11 ins; 24 del; 20 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 github.com+30433125+djelinski at openjdk.java.net  Sat Sep 25 15:00:56 2021
From: github.com+30433125+djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 25 Sep 2021 15:00:56 GMT
Subject: RFR: 8274143 Disable "invalid entry for security.provider.X"
 error message in log file when security.provider.X is empty
In-Reply-To: <bwfUo2NZNtCT5VSxOnczUou6Ujbm4vK9cWzsjTV4fmE=.ed974884-97fc-48e7-a8eb-4902bc56a15c@github.com>
References: <KBOYaYxVU__Ha5CPHTGT4vNoITVKORXz2gmjwFBVuVw=.bc3d28c4-df52-4527-bfb4-4789694d7817@github.com>
 <bwfUo2NZNtCT5VSxOnczUou6Ujbm4vK9cWzsjTV4fmE=.ed974884-97fc-48e7-a8eb-4902bc56a15c@github.com>
Message-ID: <XYjp6L0iLTAklufeFP9VlvyO0gojvtYIxOs7uBzRrQ0=.9cf28ea5-f5f2-4b29-8427-27c754781080@github.com>

On Fri, 24 Sep 2021 13:32:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The default list of providers defined in java.security file can be overridden with a custom file, declared with `-Djava.security.properties=/path/to/custom.security` command line parameter.
>> If the new list of providers is shorter than the original one, it is necessary to add an empty entry to terminate the list, like:
>> 
>> security.provider.1=BCFIPS C:HYBRID;ENABLE{All}
>> security.provider.2=SUN
>> security.provider.3=BCJSSE fips:BCFIPS
>> security.provider.4=
>> 
>> otherwise some providers from the default list will still be used.
>> 
>> Currently Java outputs an error message on standard error when it encounters an empty entry on the provider list. This PR silences that message.
>
> Changes looks fine. I've also added a `noreg-trivial` label to the JBS bug.

Thank you @wangweij for the review and JBS changes. Could you sponsor this patch?

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

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

From github.com+30433125+djelinski at openjdk.java.net  Sat Sep 25 15:40:57 2021
From: github.com+30433125+djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 25 Sep 2021 15:40:57 GMT
Subject: Integrated: 8274143 Disable "invalid entry for security.provider.X"
 error message in log file when security.provider.X is empty
In-Reply-To: <KBOYaYxVU__Ha5CPHTGT4vNoITVKORXz2gmjwFBVuVw=.bc3d28c4-df52-4527-bfb4-4789694d7817@github.com>
References: <KBOYaYxVU__Ha5CPHTGT4vNoITVKORXz2gmjwFBVuVw=.bc3d28c4-df52-4527-bfb4-4789694d7817@github.com>
Message-ID: <ZbVdbNvfeTy_ugP6K_hot-0DqMM3XDJMe8-vCNeHVcE=.23e4b0c9-59a0-418d-ac2d-96c74ade8935@github.com>

On Fri, 24 Sep 2021 08:01:07 GMT, Daniel Jeli?ski <github.com+30433125+djelinski at openjdk.org> wrote:

> The default list of providers defined in java.security file can be overridden with a custom file, declared with `-Djava.security.properties=/path/to/custom.security` command line parameter.
> If the new list of providers is shorter than the original one, it is necessary to add an empty entry to terminate the list, like:
> 
> security.provider.1=BCFIPS C:HYBRID;ENABLE{All}
> security.provider.2=SUN
> security.provider.3=BCJSSE fips:BCFIPS
> security.provider.4=
> 
> otherwise some providers from the default list will still be used.
> 
> Currently Java outputs an error message on standard error when it encounters an empty entry on the provider list. This PR silences that message.

This pull request has now been integrated.

Changeset: 4838a2ca
Author:    Daniel Jelinski <daniel.jelinski at dynatrace.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4838a2ca7c8e75b95c1c68ada7523e2a94815f45
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8274143: Disable "invalid entry for security.provider.X" error message in log file when security.provider.X is empty

Reviewed-by: weijun

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

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

From Ning.Zhang at team.neustar  Sun Sep 26 05:22:09 2021
From: Ning.Zhang at team.neustar (Zhang, Ning)
Date: Sun, 26 Sep 2021 05:22:09 +0000
Subject: Incorrect encoding of the DistributionPointName object in
 IssuingDistributionPointExtension
Message-ID: <0B20C331-0CBF-4959-943C-DECF3A9B0888@team.neustar>

Here is the test program for demonstrating the issue. Thanks.

/*
 * This java program demonstrates the encoding bug related to the
 * DistributionPointName object in
 *
 *   sun/security/x509/IssuingDistributionPointExtension.java
 *
 * The fix would be:
 *
 * ***************
 * *** 395,397 ****
 *     distributionPoint.encode(tmp);
 * !   tagged.writeImplicit(DerValue.createTag(DerValue.TAG_CONTEXT, true,
 *         TAG_DISTRIBUTION_POINT), tmp);
 * --- 395,397 ----
 *     distributionPoint.encode(tmp);
 * !   tagged.write(DerValue.createTag(DerValue.TAG_CONTEXT, true,
 *         TAG_DISTRIBUTION_POINT), tmp);
 *
 * ***************
 *
 * Encoded data sample
 *
 * Correctly encoded IssuingDistributionPointExtension object:
 *
 * 000000 30 1d 06 03 55 1d 1c 01  01 ff 04 13 30 11 a0 0c
 * 000010 a0 0a 86 08 68 74 74 70  3a 2f 2f 63 84 01 ff
 *
 * Incorectly encoded IssuingDistributionPointExtension object:
 *
 * 000000 30 1b 06 03 55 1d 1c 01  01 ff 04 11 30 0f a0 0a
 * 000010 86 08 68 74 74 70 3a 2f  2f 63 84 01 ff
 *
 */
import java.util.Arrays;
import sun.security.x509.IssuingDistributionPointExtension;
import sun.security.util.DerOutputStream;

public class TestIdpExtBug {
  private static byte[] expected = {
    0x30,      0x1d,      0x06, 0x03,      0x55, 0x1d,       0x1c, 0x01,
    0x01,(byte)0xff,      0x04, 0x13,      0x30, 0x11,(byte) 0xa0, 0x0c,
    (byte)0xa0,0x0a,(byte)0x86, 0x08,      0x68, 0x74,       0x74, 0x70,
    0x3a,      0x2f,      0x2f, 0x63,(byte)0x84, 0x01,(byte) 0xff };

  public static void main(String[] args) throws Exception {
    byte[] rawData = Arrays.copyOfRange(expected, 12, expected.length);
    IssuingDistributionPointExtension idp;
    idp = new IssuingDistributionPointExtension(true, rawData);
    System.out.println("IssuingDistributionPointExtension " + idp);
    checkData(idp);
    // trigger re-encoding and demonstrate the bug
    idp.set(IssuingDistributionPointExtension.INDIRECT_CRL, true);
    checkData(idp);
  }

  public static void checkData( IssuingDistributionPointExtension idp )
    throws Exception {
    DerOutputStream out = new DerOutputStream();
    idp.encode(out);
    byte[] encData = out.toByteArray();
    if (encData.length != expected.length) {
      System.out.println("Encoded data length mismatch - "
        + expected.length + " != " + encData.length);
      return;
    }
    for (int i = 0; i < encData.length; i++) {
      if (encData[i] != expected[i]) {
        System.out.println("Encoded data mismatches at index " + i);
        return;
      }
    }
    System.out.println("Encoded data matches as expected");
  }
}


From weijun.wang at oracle.com  Sun Sep 26 13:32:32 2021
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Sun, 26 Sep 2021 13:32:32 +0000
Subject: Incorrect encoding of the DistributionPointName object in
 IssuingDistributionPointExtension
In-Reply-To: <0B20C331-0CBF-4959-943C-DECF3A9B0888@team.neustar>
References: <0B20C331-0CBF-4959-943C-DECF3A9B0888@team.neustar>
Message-ID: <D87C3B92-A673-42E8-962B-651AA81D3B50@oracle.com>

Hi Ning,

Thanks for the report. It is indeed a bug.

I've filed a PR at https://github.com/openjdk/jdk/pull/5706.

Best wishes,
Weijun

> On Sep 26, 2021, at 1:22 AM, Zhang, Ning <Ning.Zhang at team.neustar> wrote:
> 
> Here is the test program for demonstrating the issue. Thanks.
> 
> /*
> * This java program demonstrates the encoding bug related to the
> * DistributionPointName object in
> *
> *   sun/security/x509/IssuingDistributionPointExtension.java
> *
> * The fix would be:
> *
> * ***************
> * *** 395,397 ****
> *     distributionPoint.encode(tmp);
> * !   tagged.writeImplicit(DerValue.createTag(DerValue.TAG_CONTEXT, true,
> *         TAG_DISTRIBUTION_POINT), tmp);
> * --- 395,397 ----
> *     distributionPoint.encode(tmp);
> * !   tagged.write(DerValue.createTag(DerValue.TAG_CONTEXT, true,
> *         TAG_DISTRIBUTION_POINT), tmp);
> *
> * ***************
> *

From weijun at openjdk.java.net  Mon Sep 27 01:28:29 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 27 Sep 2021 01:28:29 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]
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: <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@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:

  disable weak checksums as well

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5654/files
  - new: https://git.openjdk.java.net/jdk/pull/5654/files/7937b069..24b6d91e

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

  Stats: 145 lines in 4 files changed: 59 ins; 51 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 github.com+53162078+shiyuexw at openjdk.java.net  Mon Sep 27 01:42:05 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Mon, 27 Sep 2021 01:42:05 GMT
Subject: Withdrawn: 8273401: Remove JarIndex support in URLClassPath
In-Reply-To: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
Message-ID: <XCkigbG7w8hGzxER0kH8kgzIa9zOD4Joj5RzkuNsMEc=.93380775-54d7-4e21-bd28-b7a4df0f5322@github.com>

On Tue, 7 Sep 2021 03:34:27 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
> 
> The PR includes:
> 1. remove the JarIndex support in URLClassPath
> 2. move JarIndex into  jdk.jartool module.

This pull request has been closed without being integrated.

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

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

From github.com+53162078+shiyuexw at openjdk.java.net  Mon Sep 27 01:42:05 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Mon, 27 Sep 2021 01:42:05 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]
In-Reply-To: <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
References: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>
 <TpXTofmameWypOtftKs9oMPfWKifJ7TGqj_KGwnmIdQ=.0e9c990d-8956-4dd2-b81b-4bde59343058@github.com>
Message-ID: <j2PTFY3h2TPnHni06KmtwG2Db1ncvLV0xgkVYl5gB-g=.d1335db6-d347-4a78-bfb9-e5383156b7e2@github.com>

On Wed, 8 Sep 2021 06:22:38 GMT, wxiang <github.com+53162078+shiyuexw at openjdk.org> wrote:

>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
>> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 
>> 
>> The PR includes:
>> 1. remove the JarIndex support in URLClassPath
>> 2. move JarIndex into  jdk.jartool module.
>
> wxiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some minor changes
>   
>   Include:
>   1. remove public for INDEX_NAME in JarFile
>   2. recover the definition for INDEX_NAME in JarIndex
>   3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar

Firstly, disable JarIndex support in URLClassPath. So close the PR.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 27 09:21:31 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 27 Sep 2021 09:21:31 GMT
Subject: RFR: 8274333: Redundant null comparison after Pattern.split
Message-ID: <QVxu1mFQodoyGApD7AH8hlJxySLVCwbV0YljXrkFPbM=.1eccd9f9-b132-4967-85d5-5e33c6e54c8b@github.com>

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.

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

Commit messages:
 - [PATCH] Remove redundant 'null' comparison after Pattern.split

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

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

From darcy at openjdk.java.net  Mon Sep 27 09:29:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 09:29:09 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields
Message-ID: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>

This is an initial PR for expanded lint warnings done under two bugs:

8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type

to get feedback on the general approach and test strategy before further polishing the implementation.

The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.

Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.

Please also review the corresponding CSRs:

https://bugs.openjdk.java.net/browse/JDK-8274335
https://bugs.openjdk.java.net/browse/JDK-8274336

Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.

The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.

In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

Commit messages:
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - Clean build with instance field checks in place.
 - Merge branch 'master' into JDK-8202056
 - Put Externalizable checks last.
 - Add checks for constructor access in Serializable classes.
 - Add no-arg ctor check for Externalizable classes.
 - Improve Externalization warnings.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5756385c...d498ff5f

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202056
  Stats: 1519 lines in 79 files changed: 1511 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From weijun at openjdk.java.net  Mon Sep 27 09:47:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 27 Sep 2021 09:47:43 GMT
Subject: RFR: 8274330: Incorrect encoding of the DistributionPointName object
 in IssuingDistributionPointExtension
Message-ID: <KmuU-wrTmX4V9T6BcgvxMgQVQMB9ZZNdnfKLWHhlvkM=.b4d00855-90c1-484c-abfd-75c922450eca@github.com>

`DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE and should not be encoded as IMPLICIT.

Please note that the parsing side (at https://github.com/openjdk/jdk/blob/a9db70418f7bc6b2f95afdd36a36024f865c04bf/src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java#L195) is aware of this and has not called `resetTag()`.

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

Commit messages:
 - 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension

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

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

From erikj at openjdk.java.net  Mon Sep 27 13:01:58 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 27 Sep 2021 13:01:58 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <fleMwIh15sptLebA-p9240UO1uEZArpMzJ2LzaeAOms=.a8932c58-a9ea-45f4-a532-696aecdea5d3@github.com>

On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

Build change looks ok.

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

Marked as reviewed by erikj (Reviewer).

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

From mullan at openjdk.java.net  Mon Sep 27 13:18:26 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 27 Sep 2021 13:18:26 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: <wzXblUbrRif4xLLjQo3heqh10cXrUKY4oK2lCfLx-xQ=.415523ee-fd78-4249-910f-0258be30bc71@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.

The AlgorithmDecomposer change looks fine to me.

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

Marked as reviewed by mullan (Reviewer).

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

From valeriep at openjdk.java.net  Mon Sep 27 18:05:56 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 27 Sep 2021 18:05:56 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]
In-Reply-To: <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
Message-ID: <xQQLNn8nn0g8SX5Fv1o4jPnQq4dvVGBVYGpANSWYPFM=.9b08a7d5-a1ba-4a0f-861d-192df6754e52@github.com>

On Mon, 27 Sep 2021 01:28:29 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:
> 
>   disable weak checksums as well

Updates look good. Thanks.

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

Marked as reviewed by valeriep (Reviewer).

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

From darcy at openjdk.java.net  Mon Sep 27 19:36:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 19:36:46 GMT
Subject: RFR: 8274393: Suppress more warnings on non-serializable
 non-transient instance fields in security libs
Message-ID: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>

Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks.

The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

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

Commit messages:
 - 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

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

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

From dblevins at tomitribe.com  Mon Sep 27 21:22:26 2021
From: dblevins at tomitribe.com (David Blevins)
Date: Mon, 27 Sep 2021 15:22:26 -0600
Subject: Understanding elliptic curve spec limitations
Message-ID: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>

I've been putting a significant amount of work into compiling a large set of elliptic curve parameters/names/oids for an open source library and a related closed source security product we have.  We need to be able to support any of the curves that OpenSSL/LibreSSL support.

The trick is this is currently impossible due to hardcoding in OpenJDK 16.  Though you supply valid parameters via ECParameterSpec, when you attempt to construct an instance of ECPrivateKey or ECPublicKey you hit code in sun.security.util.CurveDB that does a "reverse lookup" of sorts to find the curve name.  If it's not a curve CurveDB knows about, you can't use it.

Is there willingness to accept contributions that would remove this limitation?


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

From anthony.scarpino at oracle.com  Mon Sep 27 22:32:49 2021
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 27 Sep 2021 15:32:49 -0700
Subject: Understanding elliptic curve spec limitations
In-Reply-To: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>
References: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>
Message-ID: <6d805395-e3cb-6bc0-36ae-7416655454e4@oracle.com>



On 9/27/21 2:22 PM, David Blevins wrote:
> I've been putting a significant amount of work into compiling a large set of elliptic curve parameters/names/oids for an open source library and a related closed source security product we have.  We need to be able to support any of the curves that OpenSSL/LibreSSL support.
> 
> The trick is this is currently impossible due to hardcoding in OpenJDK 16.  Though you supply valid parameters via ECParameterSpec, when you attempt to construct an instance of ECPrivateKey or ECPublicKey you hit code in sun.security.util.CurveDB that does a "reverse lookup" of sorts to find the curve name.  If it's not a curve CurveDB knows about, you can't use it.
> 
> Is there willingness to accept contributions that would remove this limitation?

We haven't heard such issues since native obsolete curves were removed 
from 16.  We are will to take contributions upon review.  If you're 
going to formally contribute the code, you should check out 
https://openjdk.java.net/contribute/

TOny

From dblevins at tomitribe.com  Tue Sep 28 07:49:26 2021
From: dblevins at tomitribe.com (David Blevins)
Date: Tue, 28 Sep 2021 00:49:26 -0700
Subject: Understanding elliptic curve spec limitations
In-Reply-To: <6d805395-e3cb-6bc0-36ae-7416655454e4@oracle.com>
References: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>
 <6d805395-e3cb-6bc0-36ae-7416655454e4@oracle.com>
Message-ID: <C6C56561-9489-4CB6-B1B7-EC2CE49FA7BE@tomitribe.com>

> On Sep 27, 2021, at 3:32 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> On 9/27/21 2:22 PM, David Blevins wrote:
>> I've been putting a significant amount of work into compiling a large set of elliptic curve parameters/names/oids for an open source library and a related closed source security product we have.  We need to be able to support any of the curves that OpenSSL/LibreSSL support.
>> The trick is this is currently impossible due to hardcoding in OpenJDK 16.  Though you supply valid parameters via ECParameterSpec, when you attempt to construct an instance of ECPrivateKey or ECPublicKey you hit code in sun.security.util.CurveDB that does a "reverse lookup" of sorts to find the curve name.  If it's not a curve CurveDB knows about, you can't use it.
>> Is there willingness to accept contributions that would remove this limitation?
> 
> We haven't heard such issues since native obsolete curves were removed from 16.  We are will to take contributions upon review.  If you're going to formally contribute the code, you should check out https://openjdk.java.net/contribute/

Thanks, Tony.

It also appears that of the 60 curves supported only 3 of them can be used to sign/verify.  Any insight as to why?


-David


From mullan at openjdk.java.net  Tue Sep 28 14:11:34 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 28 Sep 2021 14:11:34 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]
In-Reply-To: <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
Message-ID: <EQkGijxiJ4vZk16iuHgfs-wlOjFytNm3IF01CqrMUkU=.705c7416-f024-466e-b7ed-de1c774e4d4a@github.com>

On Mon, 27 Sep 2021 01:28:29 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:
> 
>   disable weak checksums as well

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 57:

> 55:     private static int[] defaultETypes;
> 56:     // allow_weak_crypto in krb5.conf
> 57:     public static boolean allowWeakCrypto;

Can you make this package-private instead? I think it is only accessed by `sun.security.krb5.internal.crypto.Cksum`.

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

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

From weijun at openjdk.java.net  Tue Sep 28 14:19:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 28 Sep 2021 14:19:32 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]
In-Reply-To: <EQkGijxiJ4vZk16iuHgfs-wlOjFytNm3IF01CqrMUkU=.705c7416-f024-466e-b7ed-de1c774e4d4a@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
 <EQkGijxiJ4vZk16iuHgfs-wlOjFytNm3IF01CqrMUkU=.705c7416-f024-466e-b7ed-de1c774e4d4a@github.com>
Message-ID: <Xr-pHQFf_6fV7fu7UL1cgRjDg_HroquSmsKDQtp3obA=.f4dec349-8a87-4ba6-b0bc-f03e1e1a4bfb@github.com>

On Tue, 28 Sep 2021 14:08:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   disable weak checksums as well
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java line 57:
> 
>> 55:     private static int[] defaultETypes;
>> 56:     // allow_weak_crypto in krb5.conf
>> 57:     public static boolean allowWeakCrypto;
> 
> Can you make this package-private instead? I think it is only accessed by `sun.security.krb5.internal.crypto.Cksum`.

OK.

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

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

From weijun at openjdk.java.net  Tue Sep 28 14:24:01 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 28 Sep 2021 14:24:01 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v4]
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: <O357WrPNQ2movbXEwHx5mZE-JciWoJxgLCPHoCAUB2U=.f87a9c70-b503-43e5-b8c3-63db85ff4b35@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:

  restrict availability

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

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

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 mullan at openjdk.java.net  Tue Sep 28 14:56:33 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 28 Sep 2021 14:56:33 GMT
Subject: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]
In-Reply-To: <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
References: <8riZXsI2hujdk0CMDRn856-Am5CQtjsuEN_cnNhaoNg=.03da33f1-7d8a-41af-8da3-88598fd1e410@github.com>
 <uCl7Bq1svCaJ1ldjy_p6DtpFethM3qYpJmpVSM29cRc=.ebf8657e-a8cf-40d2-b0ae-a2bcbbd9ab8c@github.com>
Message-ID: <OQEv0QXLkff3pWQOjkRTQHQRoM46yIIMv3L8MXIBP3k=.72fa45f6-9c46-4e56-94a1-4dec1a3f9c80@github.com>

On Mon, 27 Sep 2021 01:28:29 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:
> 
>   disable weak checksums as well

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/CksumType.java line 111:

> 109:         }
> 110:         if (cksumType == null) {
> 111:             throw new KdcErrException(Krb5.KDC_ERR_SUMTYPE_NOSUPP);

Could we add the checksum type that is disabled/not supported to this exception message?

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

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

From cancomert at gmail.com  Tue Sep 28 15:17:00 2021
From: cancomert at gmail.com (can comert)
Date: Tue, 28 Sep 2021 17:17:00 +0200
Subject: Verification of OCSP Responses signed with RSASSA-PSS fails with Java
 11 LTS
Message-ID: <CAPnQxbZvF_hi=3uYUYG_1HGzsC6_HN57coVk1MCoEPk0gRUKQw@mail.gmail.com>

Hello everyone,

I am trying to verify Certificate Revocation Status by using JDK and the
preferred way is the OCSP request. I came across certificates provided by a
certain Certificate Authority (Procilion) which I can not verify the
Revocation Status by using the JDK (I tried with the latest 11 LTS and 16).
Openssl on the other hand can verify the OCSP responses.

Here is the call for the openssl library:
openssl ocsp -CAfile ROOT.cer -issuer INTERMEDIATE.cer -cert
APPLICATION.cer -text -url http://ocsp.spi-cloud.com/status/

which gives results such as:
APPLICATION.cer: good
 This Update: Sep 21 15:31:32 2021 GMT
 Next Update: Sep 21 16:31:32 2021 GMT
Response verify OK

With the Wireshark I can also read the OCSP Request and Response and
Response contains status SUCCESSFUL.

Java runtime throws an exception with message "Parameters required for
RSASSA-PSS signatures" during trying to verify the signature of the OCSP
Response.

CA is using a separate certificate with Subject "OCSP Signer" to sign the
OCSP Response. This certificate is delivered in the OCSP response and the
signer certificate is signed by the same root as the issuer certificate of
the certificate under test. Java seems to accept the signer certificate but
fails to verify the signature.
Here is the debug output snaps from the Java Program I wrote to test the
revocation check and executed with flag
-Djava.security.auth.debug=certpath,ocsp:

start program
...
certpath: KeySizeConstraints.permits(): RSA
certpath: Responder's certificate includes the extension
id-pkix-ocsp-nocheck.
certpath: OCSP response is signed by an Authorized Responder
...
certpath: RevocationChecker.check() java.security.SignatureException:
Parameters required for RSASSA-PSS signatures
certpath: RevocationChecker.check() preparing to failover
...CRL check also fails due to some other reasons.....
Parameters required for RSASSA-PSS signatures
end program

I have also created a Bug Report for the Open JDK with internal review
id:9071579 since I could not find any related issues on the Bug database.

Root certificate is: procilonGROUPCustomerRootCA02.cer
Intermediate certificate is: procilonGROUPCustomerCAEDIFACT02.cer
Both available under https://pki.spi-cloud.com/issuer (packed as p7b)

I can provide the example certificates and the Java program which is
basically calling CertPathValidator.validate method to validate the
revocation status if you need to reproduce the issue.

Kind Regards,
Can C?mert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210928/d9e23246/attachment-0001.htm>

From dblevins at tomitribe.com  Tue Sep 28 15:32:36 2021
From: dblevins at tomitribe.com (David Blevins)
Date: Tue, 28 Sep 2021 08:32:36 -0700
Subject: Understanding elliptic curve spec limitations
In-Reply-To: <C6C56561-9489-4CB6-B1B7-EC2CE49FA7BE@tomitribe.com>
References: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>
 <6d805395-e3cb-6bc0-36ae-7416655454e4@oracle.com>
 <C6C56561-9489-4CB6-B1B7-EC2CE49FA7BE@tomitribe.com>
Message-ID: <4AD65B10-282A-44CF-B0FF-0DDBDA84ED28@tomitribe.com>

> On Sep 28, 2021, at 12:49 AM, David Blevins <dblevins at tomitribe.com> wrote:
> 
>> On Sep 27, 2021, at 3:32 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>> 
>> On 9/27/21 2:22 PM, David Blevins wrote:
>>> I've been putting a significant amount of work into compiling a large set of elliptic curve parameters/names/oids for an open source library and a related closed source security product we have.  We need to be able to support any of the curves that OpenSSL/LibreSSL support.
>>> The trick is this is currently impossible due to hardcoding in OpenJDK 16.  Though you supply valid parameters via ECParameterSpec, when you attempt to construct an instance of ECPrivateKey or ECPublicKey you hit code in sun.security.util.CurveDB that does a "reverse lookup" of sorts to find the curve name.  If it's not a curve CurveDB knows about, you can't use it.
>>> Is there willingness to accept contributions that would remove this limitation?
>> 
>> We haven't heard such issues since native obsolete curves were removed from 16.  We are will to take contributions upon review.  If you're going to formally contribute the code, you should check out https://openjdk.java.net/contribute/
> 
> Thanks, Tony.
> 
> It also appears that of the 60 curves supported only 3 of them can be used to sign/verify.  Any insight as to why?

Found my own answer on this second question.

 - https://bugs.openjdk.java.net/browse/JDK-8251547


-David


From anthony.scarpino at oracle.com  Tue Sep 28 15:53:48 2021
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 28 Sep 2021 15:53:48 +0000
Subject: [External] : Re: Understanding elliptic curve spec limitations
In-Reply-To: <4AD65B10-282A-44CF-B0FF-0DDBDA84ED28@tomitribe.com>
References: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>
 <6d805395-e3cb-6bc0-36ae-7416655454e4@oracle.com>
 <C6C56561-9489-4CB6-B1B7-EC2CE49FA7BE@tomitribe.com>
 <4AD65B10-282A-44CF-B0FF-0DDBDA84ED28@tomitribe.com>
Message-ID: <D75F4684-2257-4003-9410-B19A703CA6FF@oracle.com>

When I read your first message I thought you were unable to use them using OpenSSL. 

Yes, the curves you are most likely looking for have been removed as the CSR describes. 

Tony

> On Sep 28, 2021, at 8:32 AM, David Blevins <dblevins at tomitribe.com> wrote:
> 
> ?
>> 
>>> On Sep 28, 2021, at 12:49 AM, David Blevins <dblevins at tomitribe.com> wrote:
>>> 
>>>> On Sep 27, 2021, at 3:32 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>> 
>>> On 9/27/21 2:22 PM, David Blevins wrote:
>>>> I've been putting a significant amount of work into compiling a large set of elliptic curve parameters/names/oids for an open source library and a related closed source security product we have.  We need to be able to support any of the curves that OpenSSL/LibreSSL support.
>>>> The trick is this is currently impossible due to hardcoding in OpenJDK 16.  Though you supply valid parameters via ECParameterSpec, when you attempt to construct an instance of ECPrivateKey or ECPublicKey you hit code in sun.security.util.CurveDB that does a "reverse lookup" of sorts to find the curve name.  If it's not a curve CurveDB knows about, you can't use it.
>>>> Is there willingness to accept contributions that would remove this limitation?
>>> 
>>> We haven't heard such issues since native obsolete curves were removed from 16.  We are will to take contributions upon review.  If you're going to formally contribute the code, you should check out https://openjdk.java.net/contribute/
>> 
>> Thanks, Tony.
>> 
>> It also appears that of the 60 curves supported only 3 of them can be used to sign/verify.  Any insight as to why?
> 
> Found my own answer on this second question.
> 
> - https://bugs.openjdk.java.net/browse/JDK-8251547
> 
> 
> -David
> 

From ecki at zusammenkunft.net  Tue Sep 28 16:16:33 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 28 Sep 2021 18:16:33 +0200
Subject: Understanding elliptic curve spec limitations
In-Reply-To: <4AD65B10-282A-44CF-B0FF-0DDBDA84ED28@tomitribe.com>
References: <0327BDFC-0C3D-4F4C-9071-99E4F345E276@tomitribe.com>
 <6d805395-e3cb-6bc0-36ae-7416655454e4@oracle.com>
 <C6C56561-9489-4CB6-B1B7-EC2CE49FA7BE@tomitribe.com>,
 <4AD65B10-282A-44CF-B0FF-0DDBDA84ED28@tomitribe.com>
Message-ID: <A578A548-1C10-4FE3-8286-CC1BF8F418F1@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210928/b72e55d4/attachment-0001.htm>

From weijun at openjdk.java.net  Tue Sep 28 18:31:36 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 28 Sep 2021 18:31:36 GMT
Subject: RFR: 8270380: Change the default value of the
 java.security.manager system property to disallow
In-Reply-To: <MvXXDpgyowHE1urNp6ryFFvBDAoOX7-H7djdqQChdfU=.5e7c18fd-c1ae-4d04-b9ea-b28fa95dc7fa@github.com>
References: <A89zsUHwN1IIQ0s8MoeOSUQO8tXRmwlSN-thiw5ss0U=.fe47f215-531d-4239-95fa-3c50f3bae3eb@github.com>
 <MvXXDpgyowHE1urNp6ryFFvBDAoOX7-H7djdqQChdfU=.5e7c18fd-c1ae-4d04-b9ea-b28fa95dc7fa@github.com>
Message-ID: <GSJ-60lErjhuYiftpGyd5LUsY7bmxXLe6tQ2BCaWxK4=.29f0d9d4-b95e-44bd-abd4-b1a46767fc27@github.com>

On Tue, 31 Aug 2021 02:05:06 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.
>> 
>> 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.
>> 
>> Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990).
>
> New commit pushed. Sections added.

> @wangweij This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Still waiting for jtreg upgraded to 6.1.

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

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

From valeriep at openjdk.java.net  Tue Sep 28 19:16:46 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 28 Sep 2021 19:16:46 GMT
Subject: RFR: 8274050: Unnecessary Vector usage in javax.crypto
In-Reply-To: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
References: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
Message-ID: <Oh0n0V-CK4uREhVeJRJ-k0QIEgxN_EkxyDDeMavL3W4=.fe90c572-dac7-4b93-9c75-43527f1bd4e1@github.com>

On Thu, 26 Aug 2021 06:19:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

Just some nit. Rest looks fine. Thanks.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 347:

> 345: 
> 346:         CryptoPermission[] ret = permList.toArray(new CryptoPermission[0]);
> 347:         return ret;

nit: no need for local variable, can just do return permList.toArray(new CryptoPermission[0]) call. Same goes for line 390-391.

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

> 489: 
> 490:         CryptoPermission[] ret = result.toArray(new CryptoPermission[0]);
> 491:         return ret;

Same nit, no need for local variable here.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 28 21:01:20 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 28 Sep 2021 21:01:20 GMT
Subject: RFR: 8274050: Unnecessary Vector usage in javax.crypto [v2]
In-Reply-To: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
References: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
Message-ID: <j-TeG7HGOCsg96LgCyoTGhuYu1ru2iOMG5ZsF5le7Wg=.b6457258-caa9-4b35-8c4d-40333bdf8925@github.com>

> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

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

  8274050: Unnecessary Vector usage in javax.crypto

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5261/files
  - new: https://git.openjdk.java.net/jdk/pull/5261/files/6ac642fe..9e01a41f

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

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

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

From valeriep at openjdk.java.net  Tue Sep 28 21:11:37 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 28 Sep 2021 21:11:37 GMT
Subject: RFR: 8274050: Unnecessary Vector usage in javax.crypto [v2]
In-Reply-To: <j-TeG7HGOCsg96LgCyoTGhuYu1ru2iOMG5ZsF5le7Wg=.b6457258-caa9-4b35-8c4d-40333bdf8925@github.com>
References: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
 <j-TeG7HGOCsg96LgCyoTGhuYu1ru2iOMG5ZsF5le7Wg=.b6457258-caa9-4b35-8c4d-40333bdf8925@github.com>
Message-ID: <JbREiVAVbEZO9SassUzzD58-UR0hgfCnHSOU34nh33k=.f218f2f3-4f85-4896-9922-6644d932a14f@github.com>

On Tue, 28 Sep 2021 21:01:20 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274050: Unnecessary Vector usage in javax.crypto

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.java.net  Tue Sep 28 21:26:30 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 28 Sep 2021 21:26:30 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: <_y6cUqD55XN_L7EjHJO_u4Ey2Gd1uazbHgiJlZ3yme4=.0736dbf2-5d9a-4e92-94f0-92ad00266375@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

Please also review CSR at: https://bugs.openjdk.java.net/browse/JDK-8274174
Thanks.

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

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

From github.com+75672469+larry-n at openjdk.java.net  Wed Sep 29 10:55:06 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Wed, 29 Sep 2021 10:55:06 GMT
Subject: RFR: 8273026: Slow LoginContext.login() on multi threading application
Message-ID: <cCJTH3nlcWc4IwsiV_yF4R-qBotFqn_oWREXPCzSU3Y=.de97bc98-f172-4ca7-9697-ade34a2ea3f4@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.

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

Commit messages:
 - 8273026: Slow LoginContext.login() on multi threading application

Changes: https://git.openjdk.java.net/jdk/pull/5748/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5748&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273026
  Stats: 35 lines in 1 file changed: 23 ins; 3 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 ascarpino at openjdk.java.net  Wed Sep 29 15:35:39 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 29 Sep 2021 15:35:39 GMT
Subject: RFR: 8274330: Incorrect encoding of the DistributionPointName
 object in IssuingDistributionPointExtension
In-Reply-To: <KmuU-wrTmX4V9T6BcgvxMgQVQMB9ZZNdnfKLWHhlvkM=.b4d00855-90c1-484c-abfd-75c922450eca@github.com>
References: <KmuU-wrTmX4V9T6BcgvxMgQVQMB9ZZNdnfKLWHhlvkM=.b4d00855-90c1-484c-abfd-75c922450eca@github.com>
Message-ID: <M2yAdEkoI1H4ZsbhrBuKN6W2QDfc4nADb7Ns0N9TycI=.e45db8e6-4c2a-4295-8876-4207367d7e8e@github.com>

On Sun, 26 Sep 2021 13:27:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE and should not be encoded as IMPLICIT.
> 
> Please note that the parsing side (at https://github.com/openjdk/jdk/blob/a9db70418f7bc6b2f95afdd36a36024f865c04bf/src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java#L195) is aware of this and has not called `resetTag()`.

looks find to me

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

Marked as reviewed by ascarpino (Reviewer).

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

From weijun at openjdk.java.net  Wed Sep 29 15:42:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 29 Sep 2021 15:42:42 GMT
Subject: Integrated: 8274330: Incorrect encoding of the DistributionPointName
 object in IssuingDistributionPointExtension
In-Reply-To: <KmuU-wrTmX4V9T6BcgvxMgQVQMB9ZZNdnfKLWHhlvkM=.b4d00855-90c1-484c-abfd-75c922450eca@github.com>
References: <KmuU-wrTmX4V9T6BcgvxMgQVQMB9ZZNdnfKLWHhlvkM=.b4d00855-90c1-484c-abfd-75c922450eca@github.com>
Message-ID: <iGxRfGYE-I7eLOrhrV8erXPCVN8a3Tfb26Xy7sQ-Jo0=.938d35b9-26a1-4f3c-aa22-665c3a320414@github.com>

On Sun, 26 Sep 2021 13:27:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE and should not be encoded as IMPLICIT.
> 
> Please note that the parsing side (at https://github.com/openjdk/jdk/blob/a9db70418f7bc6b2f95afdd36a36024f865c04bf/src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java#L195) is aware of this and has not called `resetTag()`.

This pull request has now been integrated.

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

8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension

Reviewed-by: ascarpino

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

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

From darcy at openjdk.java.net  Wed Sep 29 18:13:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 18:13:14 GMT
Subject: RFR: 8274393: Suppress more warnings on non-serializable
 non-transient instance fields in security libs [v2]
In-Reply-To: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
References: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
Message-ID: <gGjMtzLz5VeePKzFhSVQwAd3QaA5JQw9hGhlGmxEdPs=.a5f8bb60-bd7d-41c4-ba93-eeec52cef116@github.com>

> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

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

 - Add explanatory comments for SuppressWarnings annotations.
 - Merge branch 'master' into JDK-8274393
 - 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5720/files
  - new: https://git.openjdk.java.net/jdk/pull/5720/files/5d95dea7..08718270

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

  Stats: 4821 lines in 185 files changed: 3414 ins; 967 del; 440 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5720/head:pull/5720

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 29 18:25:44 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 29 Sep 2021 18:25:44 GMT
Subject: Integrated: 8274050: Unnecessary Vector usage in javax.crypto
In-Reply-To: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
References: <PqNpdmjI1b9eKvhX5rfx36IjcDj14AhiCB57oyfwovk=.307c552e-c7d0-451d-82e9-c04558abd0f1@github.com>
Message-ID: <MtjS6Bc08OaHIfh9rHdZXFvtsht_6Brx4xSXGLZh_CU=.28fdf72e-daed-46e8-b6bf-c8b0998aacfe@github.com>

On Thu, 26 Aug 2021 06:19:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a few places, where Vector could be replaced with ArrayList.
> 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: 79cebe2c
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79cebe2c1b1e7f43377633b62c970528cac0a786
Stats:     31 lines in 2 files changed: 2 ins; 9 del; 20 mod

8274050: Unnecessary Vector usage in javax.crypto

Reviewed-by: valeriep

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

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

From darcy at openjdk.java.net  Wed Sep 29 18:35:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 18:35:37 GMT
Subject: RFR: 8274393: Suppress more warnings on non-serializable
 non-transient instance fields in security libs [v2]
In-Reply-To: <gGjMtzLz5VeePKzFhSVQwAd3QaA5JQw9hGhlGmxEdPs=.a5f8bb60-bd7d-41c4-ba93-eeec52cef116@github.com>
References: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
 <gGjMtzLz5VeePKzFhSVQwAd3QaA5JQw9hGhlGmxEdPs=.a5f8bb60-bd7d-41c4-ba93-eeec52cef116@github.com>
Message-ID: <n-BsCQ4-3E6oPRI1gzt13Olhvz4FypH1DenZUA3Ciog=.6c0a0bb0-d59c-436b-880e-845829260312@github.com>

On Wed, 29 Sep 2021 18:13:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add explanatory comments for SuppressWarnings annotations.
>  - Merge branch 'master' into JDK-8274393
>  - 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

I added explanatory comments alongside the SuppressWarnings annotations to explain their presence.

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

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

From abakhtin at openjdk.java.net  Wed Sep 29 19:37:48 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 29 Sep 2021 19:37:48 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the ssl
 handshake
Message-ID: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@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

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

Commit messages:
 - 8274524: SSLSocket.close() hangs if it is called during the ssl handshake

Changes: https://git.openjdk.java.net/jdk/pull/5760/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5760&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274524
  Stats: 26 lines in 1 file changed: 17 ins; 0 del; 9 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 sean.mullan at oracle.com  Wed Sep 29 19:43:43 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 29 Sep 2021 15:43:43 -0400
Subject: Verification of OCSP Responses signed with RSASSA-PSS fails with
 Java 11 LTS
In-Reply-To: <CAPnQxbZvF_hi=3uYUYG_1HGzsC6_HN57coVk1MCoEPk0gRUKQw@mail.gmail.com>
References: <CAPnQxbZvF_hi=3uYUYG_1HGzsC6_HN57coVk1MCoEPk0gRUKQw@mail.gmail.com>
Message-ID: <6f3ece64-9169-1591-451a-88b8bc580350@oracle.com>

Thank you for reporting this issue. As far as I can tell, it looks like 
the JDK OCSP implementation has not yet been enhanced to support 
RSASSA-PSS signatures.

We will keep an eye out for the bug report you filed but I think it is 
still making its way through our system as I have not seen it yet.

--Sean

On 9/28/21 11:17 AM, can comert wrote:
> Hello everyone,
> 
> I am trying to verify Certificate Revocation Status by using JDK and the 
> preferred?way is the OCSP request. I came across certificates provided 
> by a certain Certificate Authority (Procilion) which?I can not verify 
> the Revocation Status by using the JDK (I tried with the latest 11 LTS 
> and 16). Openssl on the other hand can verify the OCSP responses.
> 
> Here is the call for the openssl library:
> openssl ocsp -CAfile ROOT.cer -issuer INTERMEDIATE.cer -cert 
> APPLICATION.cer -text -url http://ocsp.spi-cloud.com/status/ 
> <http://ocsp.spi-cloud.com/status/>
> 
> which gives results such as:
> APPLICATION.cer: good
>  ?This Update: Sep 21 15:31:32 2021 GMT
>  ?Next Update: Sep 21 16:31:32 2021 GMT
> Response verify OK
> 
> With the Wireshark I can also read the OCSP Request and Response and 
> Response contains status SUCCESSFUL.
> 
> Java runtime throws an exception with message "Parameters required for 
> RSASSA-PSS signatures" during trying to verify the signature of the OCSP 
> Response.
> 
> CA is using a separate certificate with Subject "OCSP Signer" to sign 
> the OCSP Response. This certificate is delivered in the OCSP response 
> and the signer certificate is signed by the same root as the issuer 
> certificate of the certificate under test. Java seems to accept the 
> signer certificate but fails to verify the signature.
> Here is the debug output snaps from the Java Program I wrote to test the 
> revocation check and executed with flag 
> -Djava.security.auth.debug=certpath,ocsp:
> 
> start program
> ...
> certpath: KeySizeConstraints.permits(): RSA
> certpath: Responder's certificate includes the extension 
> id-pkix-ocsp-nocheck.
> certpath: OCSP response is signed by an Authorized Responder
> ...
> certpath: RevocationChecker.check() java.security.SignatureException: 
> Parameters required for RSASSA-PSS signatures
> certpath: RevocationChecker.check() preparing to failover
> ...CRL check also fails due to some other reasons.....
> Parameters required for RSASSA-PSS signatures
> end program
> 
> I have also created a Bug Report for the Open JDK with internal review 
> id:9071579 since I could not find any related issues on the Bug database.
> 
> Root certificate is:?procilonGROUPCustomerRootCA02.cer
> Intermediate?certificate is:?procilonGROUPCustomerCAEDIFACT02.cer
> Both available under https://pki.spi-cloud.com/issuer 
> <https://pki.spi-cloud.com/issuer> (packed as p7b)
> 
> I can provide the example certificates and the Java program which is 
> basically calling?CertPathValidator.validate method to validate the 
> revocation status if you need to reproduce the?issue.
> 
> Kind Regards,
> Can C?mert
> 

From serb at openjdk.java.net  Wed Sep 29 20:09:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 20:09:36 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: <0CGQo0Xsjz8WEKH4AonQJMAhYK3Bhc4wqrIQCSawfJk=.f414c9ed-bf36-4eae-bc37-372ccc8bcee1@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 wetmore at openjdk.java.net  Thu Sep 30 01:31:45 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 30 Sep 2021 01:31:45 GMT
Subject: RFR: 8274528: Add comment to explain an HKDF optimization in
 SSLSecretDerivation
Message-ID: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>

See comment, + a couple minor cleanups.

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

Commit messages:
 - Minor cleanup.

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

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

From jnimeh at openjdk.java.net  Thu Sep 30 04:48:38 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 30 Sep 2021 04:48:38 GMT
Subject: RFR: 8274528: Add comment to explain an HKDF optimization in
 SSLSecretDerivation
In-Reply-To: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
References: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
Message-ID: <LAVsdJMs6RBc2x8MGPZ2i0s8nutVQvVdkwcKtvCySz0=.d2c8dc62-9f25-486e-b460-7d4924509ffb@github.com>

On Thu, 30 Sep 2021 01:22:56 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> See comment, + a couple minor cleanups.

src/java.base/share/classes/sun/security/ssl/SSLSecretDerivation.java line 153:

> 151:         private final byte[] label;
> 152: 
> 153:         SecretSchedule(String label) {

Why are we opening the visibility on this enum?  As far as I can tell it is only ever referenced within the SSLSecretDerivation class and could remain private if it hasn't been causing any problems up to now.

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

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

From cancomert at gmail.com  Thu Sep 30 13:44:14 2021
From: cancomert at gmail.com (can comert)
Date: Thu, 30 Sep 2021 15:44:14 +0200
Subject: Verification of OCSP Responses signed with RSASSA-PSS fails with
 Java 11 LTS
In-Reply-To: <6f3ece64-9169-1591-451a-88b8bc580350@oracle.com>
References: <CAPnQxbZvF_hi=3uYUYG_1HGzsC6_HN57coVk1MCoEPk0gRUKQw@mail.gmail.com>
 <6f3ece64-9169-1591-451a-88b8bc580350@oracle.com>
Message-ID: <CAPnQxbaDQBLmmiPJpLbFgcLaAQg_gLbMpOsKr7c-_ik5POtgGg@mail.gmail.com>

I have recently received a Notification Email about the acceptance of the
Bug report.
It says the Bug is accepted and available under:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274471

Hier is also the JIRA Issue for OpenJDK:
https://bugs.openjdk.java.net/browse/JDK-8274471

Thanks for your interest and fast response.

Best regards,
Can

Sean Mullan <sean.mullan at oracle.com>, 29 Eyl 2021 ?ar, 22:36 tarihinde ?unu
yazd?:

> Thank you for reporting this issue. As far as I can tell, it looks like
> the JDK OCSP implementation has not yet been enhanced to support
> RSASSA-PSS signatures.
>
> We will keep an eye out for the bug report you filed but I think it is
> still making its way through our system as I have not seen it yet.
>
> --Sean
>
> On 9/28/21 11:17 AM, can comert wrote:
> > Hello everyone,
> >
> > I am trying to verify Certificate Revocation Status by using JDK and the
> > preferred way is the OCSP request. I came across certificates provided
> > by a certain Certificate Authority (Procilion) which I can not verify
> > the Revocation Status by using the JDK (I tried with the latest 11 LTS
> > and 16). Openssl on the other hand can verify the OCSP responses.
> >
> > Here is the call for the openssl library:
> > openssl ocsp -CAfile ROOT.cer -issuer INTERMEDIATE.cer -cert
> > APPLICATION.cer -text -url http://ocsp.spi-cloud.com/status/
> > <http://ocsp.spi-cloud.com/status/>
> >
> > which gives results such as:
> > APPLICATION.cer: good
> >   This Update: Sep 21 15:31:32 2021 GMT
> >   Next Update: Sep 21 16:31:32 2021 GMT
> > Response verify OK
> >
> > With the Wireshark I can also read the OCSP Request and Response and
> > Response contains status SUCCESSFUL.
> >
> > Java runtime throws an exception with message "Parameters required for
> > RSASSA-PSS signatures" during trying to verify the signature of the OCSP
> > Response.
> >
> > CA is using a separate certificate with Subject "OCSP Signer" to sign
> > the OCSP Response. This certificate is delivered in the OCSP response
> > and the signer certificate is signed by the same root as the issuer
> > certificate of the certificate under test. Java seems to accept the
> > signer certificate but fails to verify the signature.
> > Here is the debug output snaps from the Java Program I wrote to test the
> > revocation check and executed with flag
> > -Djava.security.auth.debug=certpath,ocsp:
> >
> > start program
> > ...
> > certpath: KeySizeConstraints.permits(): RSA
> > certpath: Responder's certificate includes the extension
> > id-pkix-ocsp-nocheck.
> > certpath: OCSP response is signed by an Authorized Responder
> > ...
> > certpath: RevocationChecker.check() java.security.SignatureException:
> > Parameters required for RSASSA-PSS signatures
> > certpath: RevocationChecker.check() preparing to failover
> > ...CRL check also fails due to some other reasons.....
> > Parameters required for RSASSA-PSS signatures
> > end program
> >
> > I have also created a Bug Report for the Open JDK with internal review
> > id:9071579 since I could not find any related issues on the Bug database.
> >
> > Root certificate is: procilonGROUPCustomerRootCA02.cer
> > Intermediate certificate is: procilonGROUPCustomerCAEDIFACT02.cer
> > Both available under https://pki.spi-cloud.com/issuer
> > <https://pki.spi-cloud.com/issuer> (packed as p7b)
> >
> > I can provide the example certificates and the Java program which is
> > basically calling CertPathValidator.validate method to validate the
> > revocation status if you need to reproduce the issue.
> >
> > Kind Regards,
> > Can C?mert
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210930/daf00c02/attachment.htm>

From wetmore at openjdk.java.net  Thu Sep 30 14:19:35 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 30 Sep 2021 14:19:35 GMT
Subject: RFR: 8274528: Add comment to explain an HKDF optimization in
 SSLSecretDerivation
In-Reply-To: <LAVsdJMs6RBc2x8MGPZ2i0s8nutVQvVdkwcKtvCySz0=.d2c8dc62-9f25-486e-b460-7d4924509ffb@github.com>
References: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
 <LAVsdJMs6RBc2x8MGPZ2i0s8nutVQvVdkwcKtvCySz0=.d2c8dc62-9f25-486e-b460-7d4924509ffb@github.com>
Message-ID: <rP6B5C465LvpnetH_G0fZUe2Cbf2a94piGycoKRu8KQ=.8a0fead5-9386-48d7-b88c-2291cfb7a7de@github.com>

On Thu, 30 Sep 2021 04:45:15 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> See comment, + a couple minor cleanups.
>
> src/java.base/share/classes/sun/security/ssl/SSLSecretDerivation.java line 153:
> 
>> 151:         private final byte[] label;
>> 152: 
>> 153:         SecretSchedule(String label) {
> 
> Why are we opening the visibility on this enum?  As far as I can tell it is only ever referenced within the SSLSecretDerivation class and could remain private if it hasn't been causing any problems up to now.

>From the JLS ?8.8.3:  https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.8.3

`
If no access modifier is specified for the constructor of an enum type, the constructor is private. 
'

It's kind of like adding 'public' to interfaces.  They're not necessary.

Does that alleviate your concern?

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

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

From jnimeh at openjdk.java.net  Thu Sep 30 14:24:34 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 30 Sep 2021 14:24:34 GMT
Subject: RFR: 8274528: Add comment to explain an HKDF optimization in
 SSLSecretDerivation
In-Reply-To: <rP6B5C465LvpnetH_G0fZUe2Cbf2a94piGycoKRu8KQ=.8a0fead5-9386-48d7-b88c-2291cfb7a7de@github.com>
References: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
 <LAVsdJMs6RBc2x8MGPZ2i0s8nutVQvVdkwcKtvCySz0=.d2c8dc62-9f25-486e-b460-7d4924509ffb@github.com>
 <rP6B5C465LvpnetH_G0fZUe2Cbf2a94piGycoKRu8KQ=.8a0fead5-9386-48d7-b88c-2291cfb7a7de@github.com>
Message-ID: <BGxs2q3ywEhHNFCGjbBqeiIhNBU4Q9yRNLSY8zBAdSA=.5eca7efa-1882-475b-a474-4bb8ca12fb5a@github.com>

On Thu, 30 Sep 2021 14:15:59 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSecretDerivation.java line 153:
>> 
>>> 151:         private final byte[] label;
>>> 152: 
>>> 153:         SecretSchedule(String label) {
>> 
>> Why are we opening the visibility on this enum?  As far as I can tell it is only ever referenced within the SSLSecretDerivation class and could remain private if it hasn't been causing any problems up to now.
>
> From the JLS ?8.8.3:  https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.8.3
> 
> `
> If no access modifier is specified for the constructor of an enum type, the constructor is private. 
> '
> 
> It's kind of like adding 'public' to interfaces.  They're not necessary.
> 
> Does that alleviate your concern?

Yes it does.  I forgot that enums are private when there's no visibility explicitly stated.  So given that the whole thing looks good to me.

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

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

From jnimeh at openjdk.java.net  Thu Sep 30 15:12:36 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 30 Sep 2021 15:12:36 GMT
Subject: RFR: 8274528: Add comment to explain an HKDF optimization in
 SSLSecretDerivation
In-Reply-To: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
References: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
Message-ID: <ygIpyUCGuWLOXHo6BI4d8Hp8dbbbXrNEGTITe-q67TE=.bfd2fce2-8bf2-4862-ab01-1667d41669d7@github.com>

On Thu, 30 Sep 2021 01:22:56 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> See comment, + a couple minor cleanups.

Looks good.

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

Marked as reviewed by jnimeh (Reviewer).

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

From wetmore at openjdk.java.net  Thu Sep 30 15:49:41 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 30 Sep 2021 15:49:41 GMT
Subject: Integrated: 8274528: Add comment to explain an HKDF optimization in
 SSLSecretDerivation
In-Reply-To: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
References: <s0m2LCSZSBUR1zJ9R26bzQl5S5Yq3IP_0HbtsivkIno=.78512a86-40ac-485c-91fe-15b68808b8b2@github.com>
Message-ID: <smuUnPAZBmOoy9nFFFGZzyeBvD6KxeCFWnJCgwALcMA=.88f3ef93-5d62-4467-aa90-b55c78504f0d@github.com>

On Thu, 30 Sep 2021 01:22:56 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> See comment, + a couple minor cleanups.

This pull request has now been integrated.

Changeset: c57ed22e
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c57ed22e779e7efc8ff7f3c7ec08ce2cb1a738cb
Stats:     13 lines in 1 file changed: 10 ins; 1 del; 2 mod

8274528: Add comment to explain an HKDF optimization in SSLSecretDerivation

Reviewed-by: jnimeh

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

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

From weijun at openjdk.java.net  Thu Sep 30 15:53:16 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 30 Sep 2021 15:53:16 GMT
Subject: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS
 fails
Message-ID: <Gsr6cU7Lz9efqE_SZ3vkiwJokeaRZGVmftKcorWfOZA=.3f98633b-5fe6-45e4-94ef-a681399d5334@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.

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

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

Changes: https://git.openjdk.java.net/jdk/pull/5778/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5778&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274471
  Stats: 39 lines in 6 files changed: 7 ins; 16 del; 16 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  Thu Sep 30 17:23:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 30 Sep 2021 17:23:46 GMT
Subject: RFR: 8274393: Suppress more warnings on non-serializable
 non-transient instance fields in security libs [v2]
In-Reply-To: <gGjMtzLz5VeePKzFhSVQwAd3QaA5JQw9hGhlGmxEdPs=.a5f8bb60-bd7d-41c4-ba93-eeec52cef116@github.com>
References: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
 <gGjMtzLz5VeePKzFhSVQwAd3QaA5JQw9hGhlGmxEdPs=.a5f8bb60-bd7d-41c4-ba93-eeec52cef116@github.com>
Message-ID: <ZTPnHNPD5Fd5wqJy_aXtIRa65I5rhu6RhhBCARFF1FI=.effb2a64-3921-4d43-8826-6bb60895b9cc@github.com>

On Wed, 29 Sep 2021 18:13:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add explanatory comments for SuppressWarnings annotations.
>  - Merge branch 'master' into JDK-8274393
>  - 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

Looks fine.

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

Marked as reviewed by weijun (Reviewer).

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

From darcy at openjdk.java.net  Thu Sep 30 17:43:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 30 Sep 2021 17:43:12 GMT
Subject: RFR: 8274393: Suppress more warnings on non-serializable
 non-transient instance fields in security libs [v3]
In-Reply-To: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
References: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
Message-ID: <hIYsJ7f9YzgwY8BWQE4rqN9sX0YOgm5cKkd8TZBJFrQ=.27e64e63-1c05-4182-b462-b0ca5c8268ae@github.com>

> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

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

 - Update copyrigths.
 - Merge branch 'master' into JDK-8274393
 - Add explanatory comments for SuppressWarnings annotations.
 - Merge branch 'master' into JDK-8274393
 - 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5720/files
  - new: https://git.openjdk.java.net/jdk/pull/5720/files/08718270..dcb48a0a

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

  Stats: 815 lines in 52 files changed: 604 ins; 55 del; 156 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5720/head:pull/5720

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

From darcy at openjdk.java.net  Thu Sep 30 17:43:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 30 Sep 2021 17:43:14 GMT
Subject: Integrated: 8274393: Suppress more warnings on non-serializable
 non-transient instance fields in security libs
In-Reply-To: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
References: <DzdgYxKs2uY5drgfWLkLeAC21NhuUO1yMfrkXhV_m4s=.04da902b-8735-40b7-94d2-f5fcaf817908@github.com>
Message-ID: <53Rap2Er58S-cYUsyzPEiBVol3o_U9CPEPtUGmp9GCQ=.15a5c065-1f09-4931-9366-e2d15a067139@github.com>

On Mon, 27 Sep 2021 19:24:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

This pull request has now been integrated.

Changeset: 73264811
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7326481143c1321700cbf2caa9e068c5077e22c4
Stats:     41 lines in 12 files changed: 38 ins; 0 del; 3 mod

8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

Reviewed-by: weijun

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

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

From ascarpino at openjdk.java.net  Thu Sep 30 18:44:28 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 30 Sep 2021 18:44:28 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: <fAsPfyL8LId2f-3yiVZZfkymv0cItFOrjHVN2-Oho6Q=.2dbc988a-7d66-4e3a-b1ab-06d2c47558d3@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

>From a high level, why does P11KeyWrapCipher support ENCRYPT and DECRYPT modes?  I expected to only see UNWRAP and WRAP mode supported.  Along those same lines I expected to only see C_WrapKey and C_UnwrapKey, and not encryption/decryption pkcs11 calls.  Is there some additional support here that I'm not seeing?

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

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

From valeriep at openjdk.java.net  Thu Sep 30 20:00:30 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 30 Sep 2021 20:00:30 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: <HRf8DG37Euz_bXybpfvrMS2CtlFl1RnBjrrmKex4kPg=.db0de47f-40ac-43d9-abee-2352bba22752@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

The corresponding PKCS11 mechanisms impl in NSS supports enc/dec/wrap/unwrap. In NIST spec 800-38F, these two modes, i.e. KW and KWP, are approved for both key wrapping as well as the protection of general data. Thus, they are implemented to support both enc/dec and wrap/unwrap.
> 
> 
> From a high level, why does P11KeyWrapCipher support ENCRYPT and DECRYPT modes? I expected to only see UNWRAP and WRAP mode supported. Along those same lines I expected to only see C_WrapKey and C_UnwrapKey, and not encryption/decryption pkcs11 calls. Is there some additional support here that I'm not seeing?

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

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

From ascarpino at openjdk.java.net  Thu Sep 30 20:00:31 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 30 Sep 2021 20:00:31 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: <0KVR5532GaoDXm9G6ErxqZZ-lKm-FvLtRzF0xlSOHb8=.3beeae0b-9386-4784-8701-2ae7b1f36edd@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

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?

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?

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?

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

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?

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

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

From cverghese at openjdk.java.net  Thu Sep 30 23:07:30 2021
From: cverghese at openjdk.java.net (Clive Verghese)
Date: Thu, 30 Sep 2021 23:07:30 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
Message-ID: <YuOE_kqJ5Im6tz6ubc9fntSb3RkSz1Ofh6y5JEGYHPs=.92f6a99f-2578-4e6e-9d4d-c2eb5912a20f@github.com>

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

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

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?

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

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

From hchao at openjdk.java.net  Thu Sep 30 23:18:36 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 30 Sep 2021 23:18:36 GMT
Subject: RFR: 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: <GGsIK9s-37Dyee0-x5XxiIcGg_Gfd0_TDKqWuXMSrrs=.7d5741bb-1cb2-40aa-b97b-53ee1606449e@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.

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

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

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