From bhuang at openjdk.org  Wed Feb  1 01:12:10 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 1 Feb 2023 01:12:10 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v3]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <QZp6qCcVISsTilYS14cUoWRCS6-siVnPC2EPhgZYviY=.203fd96b-3914-4b77-8ad3-9a97c48b4199@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

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

  Check root privilege with user id instead of user name.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/60096f09..3b736036

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

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

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


From duke at openjdk.org  Wed Feb  1 13:53:58 2023
From: duke at openjdk.org (Ryan Wallace)
Date: Wed, 1 Feb 2023 13:53:58 GMT
Subject: Integrated: 8294527: Some java.security.debug options missing from
 security docs
In-Reply-To: <XrMUy2qT1TB39fWqNPLdJK--FJtGebwsDgBRTdXOQQM=.51314761-04b9-4d3b-9467-2f6f346d746e@github.com>
References: <XrMUy2qT1TB39fWqNPLdJK--FJtGebwsDgBRTdXOQQM=.51314761-04b9-4d3b-9467-2f6f346d746e@github.com>
Message-ID: <fdJQgXr1lHUs_nPiL6H7DL_FOApX80_7Q4br2T2gyJo=.a1a19409-18f6-486d-bd4a-7a6b87d9b637@github.com>

On Mon, 30 Jan 2023 10:23:59 GMT, Ryan Wallace <duke at openjdk.org> wrote:

> Hi, small change to the java.security.debug to enhance help() with missing options.

This pull request has now been integrated.

Changeset: bc750f70
Author:    ryawalla <ryan.w.wallace at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc750f70f2ac1f14f5b8e6236c593dcbe99cb12f
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8294527: Some java.security.debug options missing from security docs

Reviewed-by: mullan

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

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


From mullan at openjdk.org  Wed Feb  1 14:57:39 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 1 Feb 2023 14:57:39 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
Message-ID: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>

This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

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

Commit messages:
 - Remove whitespace.
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/12365/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12365&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301260
  Stats: 149 lines in 4 files changed: 143 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12365.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12365/head:pull/12365

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


From duke at openjdk.org  Wed Feb  1 15:16:52 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 1 Feb 2023 15:16:52 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones
In-Reply-To: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
Message-ID: <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>

On Tue, 31 Jan 2023 16:54:03 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

test/jdk/java/security/MessageDigest/TestCloneable.java line 95:

> 93: 
> 94:         System.out.println(": Shared data check");
> 95:         if (!Arrays.equals(d1.digest(), d2.digest())) {

If d1 and d2 don't share memory and each thread processes random bytes, how can the digests be equal?

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

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


From duke at openjdk.org  Wed Feb  1 17:23:59 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 1 Feb 2023 17:23:59 GMT
Subject: Integrated: 8298874: Update TestAllSuites.java for TLS v1.2 and 1.3
In-Reply-To: <vNwQ6EUHIarE-ckuoWktruvCu8BU83nbZQgxdi0YIsE=.7cd7e412-d870-4a91-a6f8-f7131cd827d5@github.com>
References: <vNwQ6EUHIarE-ckuoWktruvCu8BU83nbZQgxdi0YIsE=.7cd7e412-d870-4a91-a6f8-f7131cd827d5@github.com>
Message-ID: <mVGfT24ZsKBJUjGU-_TQy73El2CmOfN0BATn9yFN8s8=.970b3bd1-2d97-430f-bad0-4e30ab4e0b7d@github.com>

On Fri, 23 Dec 2022 17:08:03 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * updated test for new TLS protocols and ciphersuites
> * code cleanup

This pull request has now been integrated.

Changeset: 3361a26d
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3361a26df4dafa134181263cc5c81bda6ba8d21e
Stats:     175 lines in 3 files changed: 39 ins; 35 del; 101 mod

8298874: Update TestAllSuites.java for TLS v1.2 and 1.3

Reviewed-by: rhalade

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

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


From mpowers at openjdk.org  Wed Feb  1 17:58:52 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 1 Feb 2023 17:58:52 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones
In-Reply-To: <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
Message-ID: <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>

On Wed, 1 Feb 2023 15:13:41 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8300416
>
> test/jdk/java/security/MessageDigest/TestCloneable.java line 95:
> 
>> 93: 
>> 94:         System.out.println(": Shared data check");
>> 95:         if (!Arrays.equals(d1.digest(), d2.digest())) {
> 
> If d1 and d2 don't share memory and each thread processes random bytes, how can the digests be equal?

In the case where ByteBuffer has allocated a direct buffer, a new internal byte array gets allocated. This is the shared memory that's causing the problem. See MessageDigestSpi.java line 220.

Oops got to update the copyright.

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

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


From jnimeh at openjdk.org  Wed Feb  1 18:18:38 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 1 Feb 2023 18:18:38 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors
Message-ID: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>

Hello all,

This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.

This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.

- JBS: https://bugs.openjdk.org/browse/JDK-8300939

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

Commit messages:
 - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
 - Merge with main
 - Restore policy Root.java lost during merge
 - Merge with main
 - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
 - Remove dead commented code
 - Throw exception directly from non 200 HTTP response codes
 - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
 - 8296343: CPVE thrown on missing content-length in OCSP response

Changes: https://git.openjdk.org/jdk/pull/12370/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12370&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300939
  Stats: 55 lines in 3 files changed: 39 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12370.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12370/head:pull/12370

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


From rhalade at openjdk.org  Wed Feb  1 19:03:00 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 1 Feb 2023 19:03:00 GMT
Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS
 implementation [v4]
In-Reply-To: <tgxkIetkGwM1or7V_l2yMsEEUDVjHAZhkIWZS8gA4ek=.69ff8e22-50d9-4bcf-a3da-44cf5a0ffdc9@github.com>
References: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
 <tgxkIetkGwM1or7V_l2yMsEEUDVjHAZhkIWZS8gA4ek=.69ff8e22-50d9-4bcf-a3da-44cf5a0ffdc9@github.com>
Message-ID: <K9y2kfU-KSUAA6PZjsT8uaj4utCwhDO1arj1_VvLlHk=.2b61ab5f-8d5b-41ba-bc8a-e39b0d9940f7@github.com>

On Fri, 27 Jan 2023 13:13:04 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated the test for TLS 1.2 and removed from ProblemList.txt
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into check-status
>  - reverted ConnectionTest.java; added newline at end of CheckStatus.java
>  - updated copyright to correct year
>  - updated copyright year
>  - removed extra whitespace
>  - 8298872: Update CheckStatus.java for changes to TLS implementation

test/jdk/javax/net/ssl/SSLEngine/CheckStatus.java line 43:

> 41: import java.security.*;
> 42: import java.nio.*;
> 43: 

I think this test needs more enhancements. The test is run with jsse.enableCBCProtection disabled and you updated it run with TLSv1.2. Can you think of better test name/summary depending on the test scenario?

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

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


From rhalade at openjdk.org  Wed Feb  1 19:04:55 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 1 Feb 2023 19:04:55 GMT
Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation [v2]
In-Reply-To: <lReQ5pxGwQzqigTQrB7COa_kfZ9AiHV7kdU-JCXnwlE=.def2b77e-1e73-4cd1-af5c-92c1e9589aac@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
 <hwXh3QBNGRdN6pCHi-XzpB18LAZwAvsm0rY9zb0sl3Y=.b1e37571-b820-4f7d-b036-74a8ec304659@github.com>
 <lReQ5pxGwQzqigTQrB7COa_kfZ9AiHV7kdU-JCXnwlE=.def2b77e-1e73-4cd1-af5c-92c1e9589aac@github.com>
Message-ID: <Y7RiYU0artPkCjjVJ2DaK3rqf34iaIs_GMFr6TZUGzU=.d54b6811-1342-448f-a364-81998c871094@github.com>

On Fri, 27 Jan 2023 13:01:01 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/SSLEngine/EngineCloseOnAlert.java line 67:
>> 
>>> 65: 
>>> 66:     public static void main(String[] args) throws Exception {
>>> 67:         SecurityUtils.removeFromDisabledTlsAlgs("TLSv1");
>> 
>> Is this still needed? Test is using TLSv1.2 only.
>
> removed

Test should also be updated to remove SecurityUtils import and library.

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

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


From rhalade at openjdk.org  Wed Feb  1 19:23:50 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 1 Feb 2023 19:23:50 GMT
Subject: RFR: 8180266: Convert sun/security/provider/KeyStore/DKSTest.sh to
 Java Jtreg Test
In-Reply-To: <-fzHD4qcvDTKuvG4pjLFsKjS06mw_eCYxNU0txrQx5M=.de561d23-44bb-4378-b423-8ee81c7bb0bd@github.com>
References: <-fzHD4qcvDTKuvG4pjLFsKjS06mw_eCYxNU0txrQx5M=.de561d23-44bb-4378-b423-8ee81c7bb0bd@github.com>
Message-ID: <xIUZ4FD6Xb0ED-UKP9wNnUDGWRLWbQJteYkQX5b-bJg=.92eb2f54-4d37-453a-ae33-ba00b367c645@github.com>

On Fri, 27 Jan 2023 15:20:09 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Convert sun/security/provider/KeyStore/DKSTest.sh to Java Jtreg Test.

Marked as reviewed by rhalade (Reviewer).

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

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


From weijun at openjdk.org  Wed Feb  1 20:09:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Feb 2023 20:09:40 GMT
Subject: RFR: 8301299: Wrong class spec on sun.security.util.Pem
Message-ID: <Lbp3CbMX4C5JcGVibPwkxRgmuL5CnqfKc-5KbGxnoos=.216f8380-a2db-475b-84fd-9f3102f24df7@github.com>

A trivial doc-only change.

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

Commit messages:
 - the fix

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

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


From jnimeh at openjdk.org  Wed Feb  1 20:35:27 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 1 Feb 2023 20:35:27 GMT
Subject: RFR: 8301299: Wrong class spec on sun.security.util.Pem
In-Reply-To: <Lbp3CbMX4C5JcGVibPwkxRgmuL5CnqfKc-5KbGxnoos=.216f8380-a2db-475b-84fd-9f3102f24df7@github.com>
References: <Lbp3CbMX4C5JcGVibPwkxRgmuL5CnqfKc-5KbGxnoos=.216f8380-a2db-475b-84fd-9f3102f24df7@github.com>
Message-ID: <vNt1YC_JEwNJHj1_PXZKLXlEM2uaLfl4-S1wfaFeSNU=.25ee1540-645c-4a96-8c29-cc453d6f4ace@github.com>

On Wed, 1 Feb 2023 19:25:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A trivial doc-only change.

Marked as reviewed by jnimeh (Reviewer).

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

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


From weijun at openjdk.org  Wed Feb  1 21:02:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Feb 2023 21:02:40 GMT
Subject: Integrated: 8301299: Wrong class spec on sun.security.util.Pem
In-Reply-To: <Lbp3CbMX4C5JcGVibPwkxRgmuL5CnqfKc-5KbGxnoos=.216f8380-a2db-475b-84fd-9f3102f24df7@github.com>
References: <Lbp3CbMX4C5JcGVibPwkxRgmuL5CnqfKc-5KbGxnoos=.216f8380-a2db-475b-84fd-9f3102f24df7@github.com>
Message-ID: <RNtXkdHy4QPUVQdci-ZHdRerKxuz6zfkXF44FRI53gE=.98908422-deff-48e5-a28b-363028d3a6b9@github.com>

On Wed, 1 Feb 2023 19:25:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A trivial doc-only change.

This pull request has now been integrated.

Changeset: 6c927c92
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c927c92f7bd01e6b34c1348594b8dff6e760a24
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8301299: Wrong class spec on sun.security.util.Pem

Reviewed-by: jnimeh

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

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


From rhalade at openjdk.org  Wed Feb  1 21:35:14 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 1 Feb 2023 21:35:14 GMT
Subject: RFR: 8245654: Add Certigna Root CA
Message-ID: <QD8dU8-pLMiAvsdr-9k8FDXgqm0t-hhngz09Bb16mPU=.69c13db6-3ce6-4ea7-83ae-6eeaeb2253c9@github.com>

This fix adds Certigna root CA to cacerts trust store.

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

Commit messages:
 - Update copyright year in VerifyCACerts.java
 - update copyright
 - Merge branch 'master' into 8247698-certigna
 - Root certificate should not be considered weak
 - Merge branch 'master' into 8247698-certigna
 - int cert doesn't specify OCSP
 - Merge branch 'openjdk:master' into 8247698-certigna
 - Merge branch 'master' into 8247698-certigna
 - remove control-M characters
 - Added Certigna CA cert and updated VerifyCACerts.java test
 - ... and 2 more: https://git.openjdk.org/jdk/compare/facd4151...4a970043

Changes: https://git.openjdk.org/jdk/pull/12376/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12376&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8245654
  Stats: 262 lines in 3 files changed: 258 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12376.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12376/head:pull/12376

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


From duke at openjdk.org  Wed Feb  1 21:51:53 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 1 Feb 2023 21:51:53 GMT
Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS
 implementation [v5]
In-Reply-To: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
References: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
Message-ID: <hHo7E0wyG3Jl8WDDTzD8VP3KJU1PBAwgbvYsAE2dlZA=.744c3caa-b190-436e-9158-bf8b074b61b7@github.com>

> Updated the test for TLS 1.2 and removed from ProblemList.txt

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

  did some additional cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11857/files
  - new: https://git.openjdk.org/jdk/pull/11857/files/db55dc43..e0915bb4

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

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

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


From duke at openjdk.org  Thu Feb  2 13:01:13 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 2 Feb 2023 13:01:13 GMT
Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation [v3]
In-Reply-To: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
Message-ID: <I4M_bKs0nsAoEWAv7SM8mvsBGZ3xx6BTzpSPK0P80ek=.1a952a9e-4cc6-4a63-8261-b1e6f5449c8a@github.com>

> Refactored the code a little bit and updated the test for changes to the TLS state machine.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - removed import, updated ProblemList
 - Merge branch 'master' into engine-close
 - Merge branch 'master' into engine-close
 - removed unnecessary line
 - 8298868: Update EngineCloseOnAlert.java for changes to TLS implementation

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

Changes: https://git.openjdk.org/jdk/pull/11903/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11903&range=02
  Stats: 56 lines in 2 files changed: 14 ins; 11 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11903.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11903/head:pull/11903

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


From duke at openjdk.org  Thu Feb  2 13:05:14 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 2 Feb 2023 13:05:14 GMT
Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation [v4]
In-Reply-To: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
Message-ID: <9laFlb6WpsSCkS_pT_txRYi1g8jH7MCs7-GMLnKjAoU=.4929e35b-70c6-4c6f-a5ff-01546cc4d55f@github.com>

> Refactored the code a little bit and updated the test for changes to the TLS state machine.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - fixed conflict
 - removed import, updated ProblemList
 - Merge branch 'master' into engine-close
 - Merge branch 'master' into engine-close
 - removed unnecessary line
 - 8298868: Update EngineCloseOnAlert.java for changes to TLS implementation

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

Changes: https://git.openjdk.org/jdk/pull/11903/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11903&range=03
  Stats: 55 lines in 2 files changed: 14 ins; 10 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11903.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11903/head:pull/11903

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


From duke at openjdk.org  Thu Feb  2 14:26:07 2023
From: duke at openjdk.org (Michele Da Meda)
Date: Thu, 2 Feb 2023 14:26:07 GMT
Subject: RFR: 8217633: Configurable extensions with system properties [v2]
In-Reply-To: <YWil3wAgJkvHh7sN0bsJIy70rOuZCnYpzOJSG_31hn0=.d780b75c-81c0-43f8-8390-eae15bc2acfd@github.com>
References: <b8NKhRjwTDexsi8ChJ1TqEFuO6waUFDZAdzOXnl1gMU=.4642774d-c1fb-4609-8f4c-8864a3ceb654@github.com>
 <D_6zFLjfcmtzMH-4zN_iATDMlrmpFwblQ5GtL03mBiM=.b3771bd7-c025-4a6c-ac6e-9a6a8bfb6bbb@github.com>
 <WgrPaQgT4o2dDd2xUaXNW8evHEjkRFVaQ6BUpeZ_4Kc=.d50ac6dd-7157-453a-bbcb-32f4ff538295@github.com>
 <YWil3wAgJkvHh7sN0bsJIy70rOuZCnYpzOJSG_31hn0=.d780b75c-81c0-43f8-8390-eae15bc2acfd@github.com>
Message-ID: <HR5tyQLyRhgrbg4x0gUzc07-LMyoNVi9AyV50iArY3g=.f0451b46-00eb-4eeb-8cb6-f3829ee02106@github.com>

On Tue, 26 Jan 2021 18:33:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright years to 2021
>
> Hi Bernd,
> 
> I agree with you that System property is not as useful to configure individual connections.  It is mostly used for corner cases that have interoperability or compatibility issues.  A general program should use APIs and the default system properties. 
> 
>> _Mailing list message from [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) on [security-dev](mailto:security-dev at openjdk.java.net):_
>> 
>> Hello,
>> 
>> I wanted to mention again, that all those System property configurations are good, especially to resolve the update pains, but not really useful if you want to make configurations on a per-connection base. If you have to support multiple partners it can be a real pain to setup a common feature set or multiple instances. For this a generic feature setter for the context would be really useful. Most prominent recent example is the ca-extension, which only really makes sense if you also did programmatically configure a small list of trusted CAs.
>> 
> Yes,  ca-extension is an item I was thinking of to support in JDK.
> 
>> I also think it would overall clean up the code and give a good place for Javadoc all those options.
>> Not to mention the default could be tied to a few new context names.
>> 
> Currently, the system properties are documented in the JSSE Reference Guides.  But just as you know, it is as easy to follow.  I agree with you that it would be nice to have better place to have them all together.
> 
> Thank you for the review.
> 
> Regards,
> Xuelei
> 
> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net

Hi @XueleiFan , i don't find this patch into latest OpenJDK 1.8 releases . Is there a plan to integrate this patch also into OpenJDK 1.8  ? (i see that OracleJDK 1.8 was updated)

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

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


From mpowers at openjdk.org  Thu Feb  2 15:32:14 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Feb 2023 15:32:14 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v2]
In-Reply-To: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
Message-ID: <ADI6_WqNyJehvM-JVu79juBJJsFocqCPEuSEIGSZWgw=.b39831ee-4f3a-44f3-9d88-9f6f8fe11c42@github.com>

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

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

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12348/files
  - new: https://git.openjdk.org/jdk/pull/12348/files/dc5b408c..66e2f1bd

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

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

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


From coffeys at openjdk.org  Thu Feb  2 17:03:35 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 2 Feb 2023 17:03:35 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
Message-ID: <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>

On Wed, 1 Feb 2023 14:46:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

src/java.base/share/conf/security/java.security line 953:

> 951: # "false". Any other value for the system property is also treated as "false".
> 952: # If the system property is set, it supersedes the XMLCryptoContext property
> 953: # value.

is is necessary to state (hint) that the system property is read once at class load time ?

test/jdk/javax/xml/crypto/dsig/SecureValidationSystemProperty.java line 38:

> 36:  * @library /test/lib
> 37:  * @run main/othervm -Dorg.jcp.xml.dsig.secureValidation=false SecureValidationSystemProperty
> 38:  */

the jtreg syntax seems to be repeated here.

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

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


From mullan at openjdk.org  Thu Feb  2 17:34:25 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Feb 2023 17:34:25 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
 <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>
Message-ID: <9cwqfmY0W5RQ_9lscG9Wvd-i8pB1SwBTJtthLr3Svv0=.c85ae23d-0eca-4652-8be2-bde5fa35ead4@github.com>

On Thu, 2 Feb 2023 17:00:36 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".
>
> test/jdk/javax/xml/crypto/dsig/SecureValidationSystemProperty.java line 38:
> 
>> 36:  * @library /test/lib
>> 37:  * @run main/othervm -Dorg.jcp.xml.dsig.secureValidation=false SecureValidationSystemProperty
>> 38:  */
> 
> the jtreg syntax seems to be repeated here.

I believe this is now the preferred way to run multiple tests, so that all tests are run even if prior ones fail. It would be nice to establish a best practice on this and update the Developer's Guide. @rhalade is that something you could work with @JesperIRL on?

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

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


From mullan at openjdk.org  Thu Feb  2 17:38:26 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Feb 2023 17:38:26 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
 <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>
Message-ID: <4DF9akM-x_pBNHcpmOJO03r0l6BTINOp8qsc-NL04xM=.a8126e23-78d2-4034-b5b8-ba520f40ed01@github.com>

On Thu, 2 Feb 2023 16:56:26 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".
>
> src/java.base/share/conf/security/java.security line 953:
> 
>> 951: # "false". Any other value for the system property is also treated as "false".
>> 952: # If the system property is set, it supersedes the XMLCryptoContext property
>> 953: # value.
> 
> is is necessary to state (hint) that the system property is read once at class load time ?

I think you are touching on an issue that is poorly documented across many system properties, so I'm reluctant to add something here which might lead to questions about other properties. I've always felt that unless otherwise specified, you should assume a system property is only read once.

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

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


From rhalade at openjdk.org  Thu Feb  2 18:16:27 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 2 Feb 2023 18:16:27 GMT
Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS
 implementation [v5]
In-Reply-To: <hHo7E0wyG3Jl8WDDTzD8VP3KJU1PBAwgbvYsAE2dlZA=.744c3caa-b190-436e-9158-bf8b074b61b7@github.com>
References: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
 <hHo7E0wyG3Jl8WDDTzD8VP3KJU1PBAwgbvYsAE2dlZA=.744c3caa-b190-436e-9158-bf8b074b61b7@github.com>
Message-ID: <RCXiWIcoixkKHuapt_idhwhQXUDYxcfRrjYF2wJ8r9s=.668a0f82-bf8b-4907-8b2d-8fbe5e185d60@github.com>

On Wed, 1 Feb 2023 21:51:53 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated the test for TLS 1.2 and removed from ProblemList.txt
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   did some additional cleanup

Marked as reviewed by rhalade (Reviewer).

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

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


From jnimeh at openjdk.org  Thu Feb  2 18:33:23 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 2 Feb 2023 18:33:23 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v2]
In-Reply-To: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
Message-ID: <A3QXaxzsDMf9ZqmMj8Yi-oSmBpdsKsegibStfU7H158=.16c88141-2e9d-455d-8187-7b6d210168ab@github.com>

> Hello all,
> 
> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
> 
> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8300939

Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - merge with main
 - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
 - Merge with main
 - Restore policy Root.java lost during merge
 - Merge with main
 - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
 - Remove dead commented code
 - Throw exception directly from non 200 HTTP response codes
 - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
 - 8296343: CPVE thrown on missing content-length in OCSP response

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

Changes: https://git.openjdk.org/jdk/pull/12370/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12370&range=01
  Stats: 55 lines in 3 files changed: 39 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12370.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12370/head:pull/12370

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


From weijun at openjdk.org  Thu Feb  2 18:40:25 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Feb 2023 18:40:25 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
Message-ID: <aE9cVK_CzRAWey0-kpKujwF1EwuYpb3Ab0zupmxSskM=.5c144612-5319-405a-a577-9826227b81b4@github.com>

On Wed, 1 Feb 2023 14:46:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

Looks good to me.

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

Marked as reviewed by weijun (Reviewer).

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


From hchao at openjdk.org  Thu Feb  2 21:17:28 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 2 Feb 2023 21:17:28 GMT
Subject: RFR: 8286907: keytool should warn about weak PBE algorithms [v2]
In-Reply-To: <H3qs6QssmnwQraDUJC4p2tHZiksR-Ls_mDjmahvYou8=.6dff7ca6-d57d-41d0-8c1b-594bc3dc9510@github.com>
References: <rWP9qmG41dCr9TXex7yYUXQBZoWksArIHUqomJ88LRY=.98cc8849-5878-4c84-a126-b2ef0286aa41@github.com>
 <E8YD7T_tgsYHud7KZZSNFLbo71ZFtPHDtUmzbGMJPR8=.e5f0c397-2c70-4d62-990b-2ae2730347fb@github.com>
 <H3qs6QssmnwQraDUJC4p2tHZiksR-Ls_mDjmahvYou8=.6dff7ca6-d57d-41d0-8c1b-594bc3dc9510@github.com>
Message-ID: <Vy49dYBv_soiGr_AiIan184JX6Rg5eK_yDDoEcFh3pg=.b5a3931b-65fc-4352-ab48-de60136d6b0e@github.com>

On Thu, 26 Jan 2023 17:39:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with Max's comment
>
> Yeah, this is a little tricky. My feeling is that if you disable an algorithm like "RC2", it should cover all uses of it no matter what the keysize. If you only want to disable certain keysizes, then you should add a `keySize` constraint. We would need to make the parsing smarter so that "RC2 keySize <= 40" covers RC2_40 but not RC2_128, etc.
> 
> Hmac is another good corner case. It would be nice if we could have exceptions, like "SHA512", "!HmacSHA512". But that's a little more involved, and requires some more thought as to whether that is a good idea.

@seanjmullan @wangweij Thanks for the review.

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

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


From hchao at openjdk.org  Thu Feb  2 21:20:33 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 2 Feb 2023 21:20:33 GMT
Subject: Integrated: 8286907: keytool should warn about weak PBE algorithms
In-Reply-To: <rWP9qmG41dCr9TXex7yYUXQBZoWksArIHUqomJ88LRY=.98cc8849-5878-4c84-a126-b2ef0286aa41@github.com>
References: <rWP9qmG41dCr9TXex7yYUXQBZoWksArIHUqomJ88LRY=.98cc8849-5878-4c84-a126-b2ef0286aa41@github.com>
Message-ID: <0GGrEHBT8ox7ekr7NQb3gNHeOVLhMPZUg-QfH4MhU-8=.9dca4134-5a5c-4cfc-b202-b0b6ef8eecdb@github.com>

On Tue, 17 Jan 2023 23:25:42 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the fix to address the problem in keytool -genseckey and -importpass.

This pull request has now been integrated.

Changeset: b00b70c2
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b00b70c2400d28070d26630614a010bc52237827
Stats:     37 lines in 2 files changed: 34 ins; 0 del; 3 mod

8286907: keytool should warn about weak PBE algorithms

Reviewed-by: mullan, weijun

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

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


From mullan at openjdk.org  Thu Feb  2 22:12:40 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Feb 2023 22:12:40 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v2]
In-Reply-To: <ADI6_WqNyJehvM-JVu79juBJJsFocqCPEuSEIGSZWgw=.b39831ee-4f3a-44f3-9d88-9f6f8fe11c42@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <ADI6_WqNyJehvM-JVu79juBJJsFocqCPEuSEIGSZWgw=.b39831ee-4f3a-44f3-9d88-9f6f8fe11c42@github.com>
Message-ID: <xgkP6zwbYSA8pmf9qbEuONPwUeL7bGettTvNzOnUWuw=.ae0b21b6-7eaf-435f-aaa6-727c2dc8cff6@github.com>

On Thu, 2 Feb 2023 15:32:14 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8300416
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

src/java.base/share/classes/java/security/MessageDigestSpi.java line 208:

> 206:     public Object clone() throws CloneNotSupportedException {
> 207:         if (this instanceof Cloneable) {
> 208:             var o = super.clone();

You could instead cast the return value of `super.clone` to `MessageDigestSpi` and avoid the casts below.

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

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


From mullan at openjdk.org  Thu Feb  2 22:12:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Feb 2023 22:12:44 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v2]
In-Reply-To: <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
 <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
Message-ID: <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>

On Wed, 1 Feb 2023 17:56:05 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> test/jdk/java/security/MessageDigest/TestCloneable.java line 95:
>> 
>>> 93: 
>>> 94:         System.out.println(": Shared data check");
>>> 95:         if (!Arrays.equals(d1.digest(), d2.digest())) {
>> 
>> If d1 and d2 don't share memory and each thread processes random bytes, how can the digests be equal?
>
> In the case where ByteBuffer has allocated a direct buffer, a new internal byte array gets allocated. This is the shared memory that's causing the problem. See MessageDigestSpi.java line 220.
> 
> Oops got to update the copyright.

I think you mean line 126? :

`                tempArray = new byte[n];  `

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

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


From bhuang at openjdk.org  Thu Feb  2 22:14:08 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 2 Feb 2023 22:14:08 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v4]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <P7tVGmixEOz2ZMOshVQl8eMbnSbDZ2nVtVTJLe99lk0=.0d45c4eb-508d-4abf-ac7c-35ddce949c27@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

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

  Check non-windows platform before retrieving user id.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/3b736036..49848a01

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

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

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


From duke at openjdk.org  Thu Feb  2 22:14:13 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 2 Feb 2023 22:14:13 GMT
Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation [v5]
In-Reply-To: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
Message-ID: <KZY5u9ZBcRw7JyOh7dIY-GSQqT2QxGAhW6vor-0W1TI=.3479e26a-7f73-4bf0-9020-3309f012cbdf@github.com>

> Refactored the code a little bit and updated the test for changes to the TLS state machine.

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

  updated SSL context

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11903/files
  - new: https://git.openjdk.org/jdk/pull/11903/files/a8753fdc..2adfcda8

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

  Stats: 14 lines in 1 file changed: 4 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11903.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11903/head:pull/11903

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


From mpowers at openjdk.org  Thu Feb  2 22:27:52 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Feb 2023 22:27:52 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v2]
In-Reply-To: <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
 <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
 <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>
Message-ID: <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>

On Thu, 2 Feb 2023 22:06:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> In the case where ByteBuffer has allocated a direct buffer, a new internal byte array gets allocated. This is the shared memory that's causing the problem. See MessageDigestSpi.java line 220.
>> 
>> Oops got to update the copyright.
>
> I think you mean line 126? :
> 
> `                tempArray = new byte[n];  `

You are correct. How did I come up with 220?

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

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


From mpowers at openjdk.org  Thu Feb  2 22:39:27 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Feb 2023 22:39:27 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v2]
In-Reply-To: <xgkP6zwbYSA8pmf9qbEuONPwUeL7bGettTvNzOnUWuw=.ae0b21b6-7eaf-435f-aaa6-727c2dc8cff6@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <ADI6_WqNyJehvM-JVu79juBJJsFocqCPEuSEIGSZWgw=.b39831ee-4f3a-44f3-9d88-9f6f8fe11c42@github.com>
 <xgkP6zwbYSA8pmf9qbEuONPwUeL7bGettTvNzOnUWuw=.ae0b21b6-7eaf-435f-aaa6-727c2dc8cff6@github.com>
Message-ID: <ga1Az8196Fk0KL60C-dzyNEttWpqbUt0RHuX5Ge7Y9E=.b51a82f4-2af8-415f-ab5b-b82472015226@github.com>

On Thu, 2 Feb 2023 22:01:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> src/java.base/share/classes/java/security/MessageDigestSpi.java line 208:
> 
>> 206:     public Object clone() throws CloneNotSupportedException {
>> 207:         if (this instanceof Cloneable) {
>> 208:             var o = super.clone();
> 
> You could instead cast the return value of `super.clone` to `MessageDigestSpi` and avoid the casts below.

I like that suggestion.

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

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


From mpowers at openjdk.org  Thu Feb  2 23:02:03 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Feb 2023 23:02:03 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v3]
In-Reply-To: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
Message-ID: <PAkZY3Wz1KgegzijYCjcK-Q_f-AgFD9nmNRAzuyojh0=.c24f83f3-089d-436b-8610-ccc9dba5fefe@github.com>

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

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

  Sean's comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12348/files
  - new: https://git.openjdk.org/jdk/pull/12348/files/66e2f1bd..bcf95a20

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

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

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


From bhuang at openjdk.org  Fri Feb  3 00:41:29 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 3 Feb 2023 00:41:29 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v5]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <1bRlAqwPrUsxVheBscnkECVvkbSVN6rDL0C8Hl-CNHA=.8ffc3074-f047-4054-bac6-060e1c3f89ce@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

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

  Exclude Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/49848a01..b8883211

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

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

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


From mbalao at openjdk.org  Fri Feb  3 01:48:57 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 3 Feb 2023 01:48:57 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
Message-ID: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>

We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.

In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):

  * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
    * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
    * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).

  * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
    * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In p
 articular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.

  * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
    * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
    * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
    * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
    * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
    * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
    * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
    * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
    * A ```P11PBECipher``` service accepts PBE keys only.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
    * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these differe
 nt entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
    * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
      * If the key algorithm matches the service algorithm, the use is allowed
      * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
    * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
    * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
    * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_PK
 CS5_PBKD2_HMAC_SHA1``` constant.
    * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
    * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
    * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
    * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
    * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
    * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
    * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
    * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.

  * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
    * New constants added.

  * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
    * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.

  * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
    * Adjustments to work with the new PBE parameter structures.
    * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.

  * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
    * Native constants and structures added.

Test files

  * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
    * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
    * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.

  * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
    * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.

  * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
    * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).

  * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
    * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.

  * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
    * Same issue fixed than for ```MacSameTest```.

  * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
    * Functions to generate random keys or passwords for PBE and non-PBE algorithms.

  * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
    * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
    * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.

Testing

  * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).

  * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).

  * No regressions have been observed in the JDK Tier-1 category.

  * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.

This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

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

Commit messages:
 - 8301553: Support Password-Based Cryptography in SunPKCS11

Changes: https://git.openjdk.org/jdk/pull/12396/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301553
  Stats: 2935 lines in 28 files changed: 2541 ins; 254 del; 140 mod
  Patch: https://git.openjdk.org/jdk/pull/12396.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12396/head:pull/12396

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


From ssahoo at openjdk.org  Fri Feb  3 05:22:57 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 3 Feb 2023 05:22:57 GMT
Subject: Integrated: 8180266: Convert sun/security/provider/KeyStore/DKSTest.sh
 to Java Jtreg Test
In-Reply-To: <-fzHD4qcvDTKuvG4pjLFsKjS06mw_eCYxNU0txrQx5M=.de561d23-44bb-4378-b423-8ee81c7bb0bd@github.com>
References: <-fzHD4qcvDTKuvG4pjLFsKjS06mw_eCYxNU0txrQx5M=.de561d23-44bb-4378-b423-8ee81c7bb0bd@github.com>
Message-ID: <jT3lGftXVFKRujuvQ4R09-pEg1HNlXeVOQURDD33uWw=.570b2c2e-44e6-49e6-bc00-6c0c7cb5a9e0@github.com>

On Fri, 27 Jan 2023 15:20:09 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Convert sun/security/provider/KeyStore/DKSTest.sh to Java Jtreg Test.

This pull request has now been integrated.

Changeset: 7f313b0c
Author:    Sibabrata Sahoo <ssahoo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f313b0cef7d0e9732beed6c61298815306531e0
Stats:     103 lines in 3 files changed: 20 ins; 78 del; 5 mod

8180266: Convert sun/security/provider/KeyStore/DKSTest.sh to Java Jtreg Test

Reviewed-by: rhalade

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

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


From aturbanov at openjdk.org  Fri Feb  3 07:28:49 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 3 Feb 2023 07:28:49 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification
In-Reply-To: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
Message-ID: <GDkKVHVXyRNiTo5A5TKnP1wHfo8N_eZSGCuZJ2bL5-s=.6dadcb71-8d66-4202-8dad-9422e9b670cc@github.com>

On Wed, 25 Jan 2023 17:38:13 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR resurrects VerifySignedJar which currently tests nothing.
> 
> VerifySignedJar currently verifies a binary JAR which was signed with SHA-1 back in April 2000. Because SHA-1 signed JARs has been disabled for a while, the JAR is treated as unsigned so the test doesn't really test anything as of now. 
> 
> The test is updated in the following ways:
> 
> - The JAR used for verification is now created and signed with SHA-256 by the test itself
> - The test is updated to check that the JAR is actually signed and with the expected certificate 
> - JarEntry InputStreams are now read fully to ensure verification of all entries
> - Objects.requireNonNull is used to check that entries returned by  getEntry, getJarEntry are non-null 
> - The existing binary JAR is retired

test/jdk/java/util/jar/JarFile/VerifySignedJar.java line 69:

> 67:                 jf.getInputStream(e).transferTo(OutputStream.nullOutputStream());
> 68:                 // Check that all regular files are signed by duke
> 69:                 if(!e.getName().startsWith("META-INF/")) {

Suggestion:

                if (!e.getName().startsWith("META-INF/")) {

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

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


From duke at openjdk.org  Fri Feb  3 08:01:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 3 Feb 2023 08:01:21 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification [v2]
In-Reply-To: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
Message-ID: <YilxN3T7_VnEafPoBo2fCX8it17Ix_UhIR3EecP3Slw=.45388665-4deb-4c33-925a-7cd80d03b837@github.com>

> This PR resurrects VerifySignedJar which currently tests nothing.
> 
> VerifySignedJar currently verifies a binary JAR which was signed with SHA-1 back in April 2000. Because SHA-1 signed JARs has been disabled for a while, the JAR is treated as unsigned so the test doesn't really test anything as of now. 
> 
> The test is updated in the following ways:
> 
> - The JAR used for verification is now created and signed with SHA-256 by the test itself
> - The test is updated to check that the JAR is actually signed and with the expected certificate 
> - JarEntry InputStreams are now read fully to ensure verification of all entries
> - Objects.requireNonNull is used to check that entries returned by  getEntry, getJarEntry are non-null 
> - The existing binary JAR is retired

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

  Add whitespace after "if"
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12206/files
  - new: https://git.openjdk.org/jdk/pull/12206/files/66ad0c7d..8ff06744

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

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

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


From coffeys at openjdk.org  Fri Feb  3 10:30:51 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 3 Feb 2023 10:30:51 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
Message-ID: <yjVDSxr1n--lGWBCTPpZ7nAuUDbK4aVz4a5sSQfBl2Q=.a650cd38-41b4-40de-b6d8-dc8b56b813a8@github.com>

On Wed, 1 Feb 2023 14:46:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

Marked as reviewed by coffeys (Reviewer).

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

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


From coffeys at openjdk.org  Fri Feb  3 10:30:53 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 3 Feb 2023 10:30:53 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <4DF9akM-x_pBNHcpmOJO03r0l6BTINOp8qsc-NL04xM=.a8126e23-78d2-4034-b5b8-ba520f40ed01@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
 <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>
 <4DF9akM-x_pBNHcpmOJO03r0l6BTINOp8qsc-NL04xM=.a8126e23-78d2-4034-b5b8-ba520f40ed01@github.com>
Message-ID: <NikDz9-pkC7jRQn4v6QHU6Hd6_dG1nU6qiM60prspQ4=.787a5ecd-69aa-479b-b603-d5e55d10ddfa@github.com>

On Thu, 2 Feb 2023 17:35:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 953:
>> 
>>> 951: # "false". Any other value for the system property is also treated as "false".
>>> 952: # If the system property is set, it supersedes the XMLCryptoContext property
>>> 953: # value.
>> 
>> is is necessary to state (hint) that the system property is read once at class load time ?
>
> I think you are touching on an issue that is poorly documented across many system properties, so I'm reluctant to add something here which might lead to questions about other properties. I've always felt that unless otherwise specified, you should assume a system property is only read once.

Thanks. I guess I was trying to be a bit more cautious here given that the DOMCryptoContext.html#setProperty approach allows the same property to be set/changed at any time during runtime. I'm fine with current edits then.

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

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


From yan at openjdk.org  Fri Feb  3 14:20:32 2023
From: yan at openjdk.org (Yuri Nesterenko)
Date: Fri, 3 Feb 2023 14:20:32 GMT
Subject: RFR: 8301760: Fix possible leak in SpNegoContext dispose
Message-ID: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>

This small change should fix a possible under certain circumstances native memory leak. In fact, the actual leak was reported in production.

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

Commit messages:
 - 8301760: Fix possible leak in SpNegoContext dispose

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

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


From jwaters at openjdk.org  Fri Feb  3 15:18:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Feb 2023 15:18:27 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

 - Merge branch 'openjdk:master' into comments
 - Partial Revert
 - sspi.cpp
 - Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/9c74387b..6b17f624

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

  Stats: 10119 lines in 311 files changed: 3838 ins; 2509 del; 3772 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

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


From duke at openjdk.org  Fri Feb  3 15:26:13 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 3 Feb 2023 15:26:13 GMT
Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS
 implementation [v6]
In-Reply-To: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
References: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
Message-ID: <rbWAPg1bV0uKtVfWdEIqHoAC9eEprrC5o7GM4UtE6uY=.10e8f66e-aaf4-47e1-b11b-f90420fbdb7f@github.com>

> Updated the test for TLS 1.2 and removed from ProblemList.txt

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

  renamed CheckStatus to CheckTlsEngineResults

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11857/files
  - new: https://git.openjdk.org/jdk/pull/11857/files/e0915bb4..e70aeb3e

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

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

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


From mullan at openjdk.org  Fri Feb  3 15:33:54 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Feb 2023 15:33:54 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v3]
In-Reply-To: <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
Message-ID: <E11Yri6vBw7l-e8FYjZHbfnH3ZL7jzK5Fb98vW8tl3E=.067c65eb-9801-4c8a-831b-e4f8b32ee61a@github.com>

On Wed, 1 Feb 2023 15:13:41 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean's comment
>
> test/jdk/java/security/MessageDigest/TestCloneable.java line 95:
> 
>> 93: 
>> 94:         System.out.println(": Shared data check");
>> 95:         if (!Arrays.equals(d1.digest(), d2.digest())) {
> 
> If d1 and d2 don't share memory and each thread processes random bytes, how can the digests be equal?

@mpdonova I believe it is because Random is producing the same sequence of bytes for each thread, and thus each MessageDigest should be equal. When the memory is shared, they inevitably overwrite each other's tempArray and you get different results.

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

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


From mullan at openjdk.org  Fri Feb  3 15:33:55 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Feb 2023 15:33:55 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v3]
In-Reply-To: <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
 <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
 <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>
 <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>
Message-ID: <te0F9La5ki9kgzUP3ZgxEDCqJ7GGyJN3Q6rA0DMI0nk=.d4190592-9ada-4d18-a439-a415c837e0d0@github.com>

On Thu, 2 Feb 2023 22:24:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I think you mean line 126? :
>> 
>> `                tempArray = new byte[n];  `
>
> You are correct. How did I come up with 220?

@mcpowers Some comments in the code explaining this better would help.

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

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


From duke at openjdk.org  Fri Feb  3 15:39:55 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 3 Feb 2023 15:39:55 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v3]
In-Reply-To: <te0F9La5ki9kgzUP3ZgxEDCqJ7GGyJN3Q6rA0DMI0nk=.d4190592-9ada-4d18-a439-a415c837e0d0@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
 <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
 <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>
 <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>
 <te0F9La5ki9kgzUP3ZgxEDCqJ7GGyJN3Q6rA0DMI0nk=.d4190592-9ada-4d18-a439-a415c837e0d0@github.com>
Message-ID: <8ne1-kdILvYR_e6IMG3rpBPtUyKn2h6gtEDXNq5DeYo=.5cb6d4cd-5f29-41d1-9529-2d4c6fcf2b02@github.com>

On Fri, 3 Feb 2023 15:30:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> You are correct. How did I come up with 220?
>
> @mcpowers Some comments in the code explaining this better would help.

That makes sense, thanks @seanjmullan

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

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


From weijun at openjdk.org  Fri Feb  3 15:41:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Feb 2023 15:41:56 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from 3rd
 party providers
Message-ID: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>

Keep the "NAME -> 1.2.3.4" mapping unchanged but modify "1.2.3.4 -> NAME" to "1.2.3.4 -> Name".

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/12410/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12410&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301788
  Stats: 91 lines in 2 files changed: 80 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12410.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12410/head:pull/12410

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


From weijun at openjdk.org  Fri Feb  3 16:11:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Feb 2023 16:11:21 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers [v2]
In-Reply-To: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
Message-ID: <mx9TDYefF1veBBCkyQot9uvL0yTJuoeLVilbIEyemEU=.fbdeb5c2-c9b7-4e6f-ae60-952b74d27e3b@github.com>

> Keep the "NAME -> 1.2.3.4" mapping unchanged but modify "1.2.3.4 -> NAME" to "1.2.3.4 -> Name".

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

  impl not necessary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12410/files
  - new: https://git.openjdk.org/jdk/pull/12410/files/26581839..61f3448c

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

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

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


From weijun at openjdk.org  Fri Feb  3 16:24:50 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Feb 2023 16:24:50 GMT
Subject: RFR: 8301760: Fix possible leak in SpNegoContext dispose
In-Reply-To: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
References: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
Message-ID: <gmFR2h1jOZXF0yn8aZhfPLimEgvsOTugZRgBn3IsFBg=.1c387197-b7ee-4dbd-8cf7-67c82e1f782d@github.com>

On Fri, 3 Feb 2023 14:12:42 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> This small change should fix a possible under certain circumstances native memory leak. In fact, the actual leak was reported in production.

Looks good to me. I'll run some tests, does not look like there will be an unexpected exception thrown.

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

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


From mpowers at openjdk.org  Fri Feb  3 17:17:54 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 3 Feb 2023 17:17:54 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v2]
In-Reply-To: <A3QXaxzsDMf9ZqmMj8Yi-oSmBpdsKsegibStfU7H158=.16c88141-2e9d-455d-8187-7b6d210168ab@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
 <A3QXaxzsDMf9ZqmMj8Yi-oSmBpdsKsegibStfU7H158=.16c88141-2e9d-455d-8187-7b6d210168ab@github.com>
Message-ID: <aUWSwrw4j8cvBpcXtyyc8zDoM6uAA0zTMx3KnuI6PTQ=.050b88f8-1502-43ba-bd1f-f4f0b34a3daf@github.com>

On Thu, 2 Feb 2023 18:33:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hello all,
>> 
>> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
>> 
>> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
>> 
>> - JBS: https://bugs.openjdk.org/browse/JDK-8300939
>
> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - merge with main
>  - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
>  - Merge with main
>  - Restore policy Root.java lost during merge
>  - Merge with main
>  - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
>  - Remove dead commented code
>  - Throw exception directly from non 200 HTTP response codes
>  - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
>  - 8296343: CPVE thrown on missing content-length in OCSP response

It's not clear to me what is causing this test failure, but your fix is to drain the input stream and flush the output?

test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 59:

> 57: 
> 58:     // Enable debugging for additional output
> 59:     static final boolean debug = true;

Do you intend to leave this `true`?

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

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


From weijun at openjdk.org  Fri Feb  3 17:43:41 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Feb 2023 17:43:41 GMT
Subject: RFR: 8301793: AlgorithmId should not encode a missing parameters field
 as NULL unless hardcoded
Message-ID: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>

Change blocklist to allowlist for encoding null parameters in `AlgorithmId`.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/12412/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12412&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301793
  Stats: 193 lines in 2 files changed: 121 ins; 21 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/12412.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12412/head:pull/12412

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


From jnimeh at openjdk.org  Fri Feb  3 17:58:57 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 3 Feb 2023 17:58:57 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v2]
In-Reply-To: <aUWSwrw4j8cvBpcXtyyc8zDoM6uAA0zTMx3KnuI6PTQ=.050b88f8-1502-43ba-bd1f-f4f0b34a3daf@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
 <A3QXaxzsDMf9ZqmMj8Yi-oSmBpdsKsegibStfU7H158=.16c88141-2e9d-455d-8187-7b6d210168ab@github.com>
 <aUWSwrw4j8cvBpcXtyyc8zDoM6uAA0zTMx3KnuI6PTQ=.050b88f8-1502-43ba-bd1f-f4f0b34a3daf@github.com>
Message-ID: <lDgcMvElzGHvWjMtHvyev2rG9SR9o-WLdZpmiN_qwK0=.72093389-b343-4af1-a40a-ed3c280fa61f@github.com>

On Fri, 3 Feb 2023 17:14:41 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> It's not clear to me what is causing this test failure, but your fix is to drain the input stream and flush the output?

Yes, that's the gist of it.  I didn't realize originally that I was leaving unread data in the input stream, so draining that and making sure everything was flushed definitely improved things.  The other changes were just minor extras (additional logging, etc.) that made sense while I was in this class.

> test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 59:
> 
>> 57: 
>> 58:     // Enable debugging for additional output
>> 59:     static final boolean debug = true;
> 
> Do you intend to leave this `true`?

Yes, I would like to leave this in the off chance this does rear its ugly head again.  I've done hundreds upon hundreds of iterations of this test both by itself and as part of tier2 runs and no failures occur.  If it did fail though, I'd like to have the extra logging.  It doesn't add very much to the output, but the info is useful.

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

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


From rhalade at openjdk.org  Fri Feb  3 19:04:50 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 3 Feb 2023 19:04:50 GMT
Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS
 implementation [v6]
In-Reply-To: <rbWAPg1bV0uKtVfWdEIqHoAC9eEprrC5o7GM4UtE6uY=.10e8f66e-aaf4-47e1-b11b-f90420fbdb7f@github.com>
References: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
 <rbWAPg1bV0uKtVfWdEIqHoAC9eEprrC5o7GM4UtE6uY=.10e8f66e-aaf4-47e1-b11b-f90420fbdb7f@github.com>
Message-ID: <TLudXEJarU4Cn_wAWOStvajJq_23A7Q36RYiMtYdWf0=.c7321608-0204-49cb-9f4e-b6eba3a03c15@github.com>

On Fri, 3 Feb 2023 15:26:13 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated the test for TLS 1.2 and removed from ProblemList.txt
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed CheckStatus to CheckTlsEngineResults

Marked as reviewed by rhalade (Reviewer).

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

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


From rhalade at openjdk.org  Fri Feb  3 19:11:51 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 3 Feb 2023 19:11:51 GMT
Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation [v5]
In-Reply-To: <KZY5u9ZBcRw7JyOh7dIY-GSQqT2QxGAhW6vor-0W1TI=.3479e26a-7f73-4bf0-9020-3309f012cbdf@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
 <KZY5u9ZBcRw7JyOh7dIY-GSQqT2QxGAhW6vor-0W1TI=.3479e26a-7f73-4bf0-9020-3309f012cbdf@github.com>
Message-ID: <lOsScncTPeFYjILIJh2-UR3V8Uw9ELBIuUkJIqRJxkc=.3347ab04-6a0d-4faa-bdb1-60608c66ee92@github.com>

On Thu, 2 Feb 2023 22:14:13 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Refactored the code a little bit and updated the test for changes to the TLS state machine.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated SSL context

Marked as reviewed by rhalade (Reviewer).

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

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


From rhalade at openjdk.org  Fri Feb  3 19:15:51 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 3 Feb 2023 19:15:51 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v5]
In-Reply-To: <1bRlAqwPrUsxVheBscnkECVvkbSVN6rDL0C8Hl-CNHA=.8ffc3074-f047-4054-bac6-060e1c3f89ce@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
 <1bRlAqwPrUsxVheBscnkECVvkbSVN6rDL0C8Hl-CNHA=.8ffc3074-f047-4054-bac6-060e1c3f89ce@github.com>
Message-ID: <qquZHn9vCf8C8UwfVgzMZYNyK1SccVfN1sf6HTibTFI=.d710f437-2edb-46f4-8bc9-9196118d1d34@github.com>

On Fri, 3 Feb 2023 00:41:29 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude Windows.

Marked as reviewed by rhalade (Reviewer).

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

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


From rhalade at openjdk.org  Fri Feb  3 19:18:53 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 3 Feb 2023 19:18:53 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode
In-Reply-To: <9cwqfmY0W5RQ_9lscG9Wvd-i8pB1SwBTJtthLr3Svv0=.c85ae23d-0eca-4652-8be2-bde5fa35ead4@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
 <RBGAOUp51rFI6ixLuHAPDcIurkNA33HPmCe-jjDM02U=.ff8ae1bb-5267-4fab-b96e-63fa88e76b47@github.com>
 <9cwqfmY0W5RQ_9lscG9Wvd-i8pB1SwBTJtthLr3Svv0=.c85ae23d-0eca-4652-8be2-bde5fa35ead4@github.com>
Message-ID: <NLCuemiAzaRsiokBYHuIA_JZAHe69xpc9Argx_N4lhk=.cc5fb279-eecd-4d9f-a165-bfb15b5bd4b8@github.com>

On Thu, 2 Feb 2023 17:32:06 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/xml/crypto/dsig/SecureValidationSystemProperty.java line 38:
>> 
>>> 36:  * @library /test/lib
>>> 37:  * @run main/othervm -Dorg.jcp.xml.dsig.secureValidation=false SecureValidationSystemProperty
>>> 38:  */
>> 
>> the jtreg syntax seems to be repeated here.
>
> I believe this is now the preferred way to run multiple tests, so that all tests are run even if prior ones fail. It would be nice to establish a best practice on this and update the Developer's Guide. @rhalade is that something you could work with @JesperIRL on?

Yes, we will work to get it updated in Developer's guide.

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

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


From bhuang at openjdk.org  Fri Feb  3 19:22:00 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 3 Feb 2023 19:22:00 GMT
Subject: Integrated: JDK-8299994: java/security/Policy/Root/Root.java fails
 when home directory is read-only
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <Dy0-QBlGXcQRPzw_pvVgQhYO_hpqAokIi4EZusXhA2s=.36f30dd5-f5f7-4450-96b9-3948c7d08169@github.com>

On Tue, 31 Jan 2023 22:35:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

This pull request has now been integrated.

Changeset: 20579e48
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20579e48cf598e890aa35c5518ec8d0594f45385
Stats:     41 lines in 3 files changed: 37 ins; 1 del; 3 mod

8299994: java/security/Policy/Root/Root.java fails when home directory is read-only

Reviewed-by: rhalade

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

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


From aivanov at openjdk.org  Fri Feb  3 19:37:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 19:37:53 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
Message-ID: <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>

On Fri, 3 Feb 2023 15:18:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into comments
>  - Partial Revert
>  - sspi.cpp
>  - Comments

Except for the change in `sspi.cpp`, it looks good to me.

src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31:

> 29: // This library can be built directly with the following command:
> 30: //   cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp
> 31: //      -link -dll -out:sspi_bridge.dll

I think the backslash `` should remain there: it's a command line and `` is used to wrap the long line.

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

Changes requested by aivanov (Reviewer).

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


From duke at openjdk.org  Fri Feb  3 19:59:05 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 3 Feb 2023 19:59:05 GMT
Subject: Integrated: 8298872: Update CheckStatus.java for changes to TLS
 implementation
In-Reply-To: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
References: <BxcoZLbQBeD88JiHK44NQBQahNsH-j3RhnbMYBvE_sU=.2f671e20-2cb5-4f79-8196-92520bcee655@github.com>
Message-ID: <qZpF7M_Lw3Wiz4y-2KWs1Pq3ZYUwiKdV5wFR_g95lqo=.b338ebf3-2806-4b6d-869e-f7df10ddfc88@github.com>

On Thu, 5 Jan 2023 01:18:55 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Updated the test for TLS 1.2 and removed from ProblemList.txt

This pull request has now been integrated.

Changeset: e7247b10
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7247b10ccd2bf1ad6809395a1b63aa5046d5b1d
Stats:     1424 lines in 3 files changed: 709 ins; 715 del; 0 mod

8298872: Update CheckStatus.java for changes to TLS implementation

Reviewed-by: rhalade

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

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


From weijun.wang at oracle.com  Fri Feb  3 22:53:41 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 3 Feb 2023 22:53:41 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
Message-ID: <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>

Hi All,

Thanks for all the feedbacks. One of them [1] from Bernd Eckenfels is about Hybrid TLS Key Exchange. I read the IETF draft on it [2] and noticed something that the current KEM API cannot handle. It says the 2 ciphertext for each sub-KEM will be concatenated into a longer byte array as the ciphertext of the hybrid KEM. This brings up a problem on the decapsulator side: how can we split the long array into two if we don't know the size of each sub-ciphertext?

David Hook mentioned that RSA-KEM has a similar problem.

Therefore we decide to add a getCiphertextSize() method, and it can only be called after the private key is known. The decapsulation will be broken into multiple steps: the key is provided first, you have a chance to get the ciphertext size, and then perform the actual decapsulation. But instead of choosing Signature's initSign-then-sign approach which is on the same object and thus not thread-safe and mutable, the 1st step will return a Decapsulator object and this Decapsulator is used to perform the other steps, including the new size retrieval methods and the actual decapsulation function. The same is done on the encapsulation side.

We also take this chance to rename "ciphertext" into "key encapsulation message". This is the name used in the PQC APIs [4] and this avoids confusing with encryption output of a Cipher. This is also a suggestion from David Hook.

Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.

Thanks,
Max

[1] https://mastodon.social/@eckes at zusammenkunft.net/109752008992193461
[2] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html#name-transmitting-public-keys-an <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>
[3] https://www.rfc-editor.org/rfc/rfc5990#appendix-A.2
[4] https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf


> On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi All,
> 
> We are working on providing a new API for KEM (Key Encapsulation Mechanism). There will be a KEM class for users along with a KEMSpi class for security providers, and several other parameter and exception classes.
> 
> You can read the draft JEP at https://openjdk.org/jeps/8301034.
> 
> Feel free to add any comment here.
> 
> Thanks,
> Max
> 



From jwaters at openjdk.org  Sat Feb  4 07:45:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Feb 2023 07:45:52 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
Message-ID: <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>

On Fri, 3 Feb 2023 19:32:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into comments
>>  - Partial Revert
>>  - sspi.cpp
>>  - Comments
>
> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31:
> 
>> 29: // This library can be built directly with the following command:
>> 30: //   cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp
>> 31: //      -link -dll -out:sspi_bridge.dll
> 
> I think the backslash `` should remain there: it's a command line and `` is used to wrap the long line.

I did think about that too when I first saw it, but the command this is often run from is the Windows CMD, which does not accept `` to escape to the next line. MSYS bash does not have the required environment set up outside of configure time to run `cl` either, but I have not tested with WSL yet. I suppose one could do the complicated setup required to be able to run this from the winenv provided bash, but that seems like a lot of hassle, enough that to me someone trying to compile sspi_bridge.dll by itself wouldn't really bother with the process. On top of that cl.exe will actually interpret the backslash as the literal object file `.o` for some weird reason. I've already pinged the original author of the file @wangweij above to ask for guidance on this as such

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

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


From weijun at openjdk.org  Sat Feb  4 12:38:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 4 Feb 2023 12:38:48 GMT
Subject: RFR: 8301760: Fix possible leak in SpNegoContext dispose
In-Reply-To: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
References: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
Message-ID: <qLYEKDXMyddGkxlKwb7lRqBX2wvSl6bYMy0ktskpGIg=.9e77044b-f298-4093-a448-f1a8f594b073@github.com>

On Fri, 3 Feb 2023 14:12:42 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> This small change should fix a possible under certain circumstances native memory leak. In fact, the actual leak was reported in production.

Marked as reviewed by weijun (Reviewer).

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

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


From weijun at openjdk.org  Sat Feb  4 13:39:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 4 Feb 2023 13:39:54 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
Message-ID: <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>

On Sat, 4 Feb 2023 07:42:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31:
>> 
>>> 29: // This library can be built directly with the following command:
>>> 30: //   cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp
>>> 31: //      -link -dll -out:sspi_bridge.dll
>> 
>> I think the backslash `` should remain there: it's a command line and `` is used to wrap the long line.
>
> I did think about that too when I first saw it, but the command this is often run from is the Windows CMD, which does not accept `` to escape to the next line. MSYS bash does not have the required environment set up outside of configure time to run `cl` either, but I have not tested with WSL yet. I suppose one could do the complicated setup required to be able to run this from the winenv provided bash, but that seems like a lot of hassle, enough that to me someone trying to compile sspi_bridge.dll by itself wouldn't really bother with the process. On top of that cl.exe will actually interpret the backslash as the literal object file `.o` for some weird reason. I've already pinged the original author of the file @wangweij above to ask for guidance on this as such

I have no objection to the code change. Or maybe you can change it to the windows line extension character `^`.

I was using this command for quick recompiling while writing this code, and it's in a cmd.exe window launched with a start menu item named something like "Visual Studio Developing Environment". I wrote it inside here to remind myself if I need to rework on it.

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

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


From xuelei.f at gmail.com  Sat Feb  4 15:44:52 2023
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Sat, 4 Feb 2023 07:44:52 -0800
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
Message-ID: <FF0F7C44-C704-42C0-9FC6-ECDF50C715FB@gmail.com>

Hi,

Thank you for the update.  

What?s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I?m not very sure of it.  

For example, at 2013, the following cord should work without any issues:
1. var kemS = KEM.getInstance("DHKEM?);
2. var pkR = retrieveKey();
3. var e = kemS.newEncapsulater(pkR);
4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
5. var secS = enc.key();
6. sendBytes(enc.encapsulation());


At 2023, a new DerivedKeyParameterSpec algorithm or spec could be defined.  For example, the new algorithm is ?ZES?.  An application may use ?ZES" as:

1. var kemS = KEM.getInstance("DHKEM?);
2. var pkR = retrieveKey();
3. var e = kemS.newEncapsulater(pkR);
- 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
+ 4. var enc = e.encapsulate(new DerivedKeyParameterSpec(?ZES", 32));
5. var secS = enc.key();
6. sendBytes(enc.encapsulation());


The provider A implemented before 2023 cannot support AES, and another provider B updated after 2023 could.  Suppose there are two providers, and provider A is preferred, will the application that use ?ZES? work as expected (choose provider B)?  Per the current JEP, It looks like provider A will be selected at line 3, and exception could be thrown at line 4.

Thanks,
Xuelei

> On Feb 3, 2023, at 2:53 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi All,
> 
> Thanks for all the feedbacks. One of them [1] from Bernd Eckenfels is about Hybrid TLS Key Exchange. I read the IETF draft on it [2] and noticed something that the current KEM API cannot handle. It says the 2 ciphertext for each sub-KEM will be concatenated into a longer byte array as the ciphertext of the hybrid KEM. This brings up a problem on the decapsulator side: how can we split the long array into two if we don't know the size of each sub-ciphertext?
> 
> David Hook mentioned that RSA-KEM has a similar problem.
> 
> Therefore we decide to add a getCiphertextSize() method, and it can only be called after the private key is known. The decapsulation will be broken into multiple steps: the key is provided first, you have a chance to get the ciphertext size, and then perform the actual decapsulation. But instead of choosing Signature's initSign-then-sign approach which is on the same object and thus not thread-safe and mutable, the 1st step will return a Decapsulator object and this Decapsulator is used to perform the other steps, including the new size retrieval methods and the actual decapsulation function. The same is done on the encapsulation side.
> 
> We also take this chance to rename "ciphertext" into "key encapsulation message". This is the name used in the PQC APIs [4] and this avoids confusing with encryption output of a Cipher. This is also a suggestion from David Hook.
> 
> Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.
> 
> Thanks,
> Max
> 
> [1] https://mastodon.social/@eckes at zusammenkunft.net/109752008992193461
> [2] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html#name-transmitting-public-keys-an <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>
> [3] https://www.rfc-editor.org/rfc/rfc5990#appendix-A.2
> [4] https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf
> 
> 
>> On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Hi All,
>> 
>> We are working on providing a new API for KEM (Key Encapsulation Mechanism). There will be a KEM class for users along with a KEMSpi class for security providers, and several other parameter and exception classes.
>> 
>> You can read the draft JEP at https://openjdk.org/jeps/8301034.
>> 
>> Feel free to add any comment here.
>> 
>> Thanks,
>> Max
>> 
> 



From aivanov at openjdk.org  Sat Feb  4 17:25:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 4 Feb 2023 17:25:48 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
Message-ID: <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>

On Sat, 4 Feb 2023 13:36:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I did think about that too when I first saw it, but the command this is often run from is the Windows CMD, which does not accept `` to escape to the next line. MSYS bash does not have the required environment set up outside of configure time to run `cl` either, but I have not tested with WSL yet. I suppose one could do the complicated setup required to be able to run this from the winenv provided bash, but that seems like a lot of hassle, enough that to me someone trying to compile sspi_bridge.dll by itself wouldn't really bother with the process. On top of that cl.exe will actually interpret the backslash as the literal object file `.o` for some weird reason. I've already pinged the original author of the file @wangweij above to ask for guidance on this as such
>
> I have no objection to the code change. Or maybe you can change it to the windows line extension character `^`.
> 
> I was using this command for quick recompiling while writing this code, and it's in a cmd.exe window launched with a start menu item named something like "Visual Studio Developing Environment". I wrote it inside here to remind myself if I need to rework on it.

I used to have Visual Studio compilers available in my Cygwin environment. Now I don't, I just point the `configure` script to the batch file which configures the environment.

If this command is supposed to be run in `cmd.exe`, then `^` makes more sense: one could just copy & paste the command.

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

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


From weijun.wang at oracle.com  Sat Feb  4 22:33:10 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Sat, 4 Feb 2023 22:33:10 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <FF0F7C44-C704-42C0-9FC6-ECDF50C715FB@gmail.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <FF0F7C44-C704-42C0-9FC6-ECDF50C715FB@gmail.com>
Message-ID: <3AFC1A4A-4D80-40F3-8A01-E3E6A2B0D08D@oracle.com>

Hi Xuelei,

This is a very interesting case since both crypto primitives (KEM and Cipher) require delayed provider selection.

I would say line 4 should not throw an exception. A KEM should not reject any algorithm name, because it might be any string. It's very likely that the shared secret is then be passed into a KDF. I don't think there is a convention on what the algorithm name should be used for the input of a KDF. Should any KEM reject the "TlsPreSharedSecret" algorithm name? Maybe not.

In your example, it's very unfortunate that the real ZES implementation is not able to use the unextractable key generated by a KEM in another provider. I assume some considerations on a proper provider order might be necessary, or the user might need to think about picking up a provider explicitly. You can imagine this becoming more of a problem in the KEM -> KDF -> Key Wrapping Cipher -> Data Encryption Cipher case, which is a very typical combination in today's secure data exchange.

Thanks,
Max


> On Feb 4, 2023, at 10:44 AM, Xuelei Fan <xuelei.f at gmail.com> wrote:
> 
> Hi,
> 
> Thank you for the update.  
> 
> What?s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I?m not very sure of it.  
> 
> For example, at 2013, the following cord should work without any issues:
> 1. var kemS = KEM.getInstance("DHKEM?);
> 2. var pkR = retrieveKey();
> 3. var e = kemS.newEncapsulater(pkR);
> 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
> 5. var secS = enc.key();
> 6. sendBytes(enc.encapsulation());
> 
> 
> At 2023, a new DerivedKeyParameterSpec algorithm or spec could be defined.  For example, the new algorithm is ?ZES?.  An application may use ?ZES" as:
> 
> 1. var kemS = KEM.getInstance("DHKEM?);
> 2. var pkR = retrieveKey();
> 3. var e = kemS.newEncapsulater(pkR);
> - 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
> + 4. var enc = e.encapsulate(new DerivedKeyParameterSpec(?ZES", 32));
> 5. var secS = enc.key();
> 6. sendBytes(enc.encapsulation());
> 
> 
> The provider A implemented before 2023 cannot support AES, and another provider B updated after 2023 could.  Suppose there are two providers, and provider A is preferred, will the application that use ?ZES? work as expected (choose provider B)?  Per the current JEP, It looks like provider A will be selected at line 3, and exception could be thrown at line 4.
> 
> Thanks,
> Xuelei
> 
>> On Feb 3, 2023, at 2:53 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Hi All,
>> 
>> Thanks for all the feedbacks. One of them [1] from Bernd Eckenfels is about Hybrid TLS Key Exchange. I read the IETF draft on it [2] and noticed something that the current KEM API cannot handle. It says the 2 ciphertext for each sub-KEM will be concatenated into a longer byte array as the ciphertext of the hybrid KEM. This brings up a problem on the decapsulator side: how can we split the long array into two if we don't know the size of each sub-ciphertext?
>> 
>> David Hook mentioned that RSA-KEM has a similar problem.
>> 
>> Therefore we decide to add a getCiphertextSize() method, and it can only be called after the private key is known. The decapsulation will be broken into multiple steps: the key is provided first, you have a chance to get the ciphertext size, and then perform the actual decapsulation. But instead of choosing Signature's initSign-then-sign approach which is on the same object and thus not thread-safe and mutable, the 1st step will return a Decapsulator object and this Decapsulator is used to perform the other steps, including the new size retrieval methods and the actual decapsulation function. The same is done on the encapsulation side.
>> 
>> We also take this chance to rename "ciphertext" into "key encapsulation message". This is the name used in the PQC APIs [4] and this avoids confusing with encryption output of a Cipher. This is also a suggestion from David Hook.
>> 
>> Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.
>> 
>> Thanks,
>> Max
>> 
>> [1] https://urldefense.com/v3/__https://mastodon.social/@eckes at zusammenkunft.net/109752008992193461__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXz4sePXo4$ 
>> [2] https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html*name-transmitting-public-keys-an__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzNgH0GW8$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzwgQIN5I$ >
>> [3] https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5990*appendix-A.2__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzF2ogx9M$ 
>> [4] https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzP6fP4sc$ 
>> 
>> 
>>> On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Hi All,
>>> 
>>> We are working on providing a new API for KEM (Key Encapsulation Mechanism). There will be a KEM class for users along with a KEMSpi class for security providers, and several other parameter and exception classes.
>>> 
>>> You can read the draft JEP at https://openjdk.org/jeps/8301034.
>>> 
>>> Feel free to add any comment here.
>>> 
>>> Thanks,
>>> Max



From xuelei.f at gmail.com  Sun Feb  5 06:24:33 2023
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Sat, 4 Feb 2023 22:24:33 -0800
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <3AFC1A4A-4D80-40F3-8A01-E3E6A2B0D08D@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <FF0F7C44-C704-42C0-9FC6-ECDF50C715FB@gmail.com>
 <3AFC1A4A-4D80-40F3-8A01-E3E6A2B0D08D@oracle.com>
Message-ID: <CAPJ=zziA9G1uWuGso640T8N=XoP=gTDzk65Nn6qC2aPkRBDLkA@mail.gmail.com>

On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang <weijun.wang at oracle.com> wrote:

> Hi Xuelei,
>
> This is a very interesting case since both crypto primitives (KEM and
> Cipher) require delayed provider selection.
>
> I would say line 4 should not throw an exception. A KEM should not reject
> any algorithm name, because it might be any string. It's very likely that
> the shared secret is then be passed into a KDF. I don't think there is a
> convention on what the algorithm name should be used for the input of a
> KDF. Should any KEM reject the "TlsPreSharedSecret" algorithm name? Maybe
> not.
>
>
I'm not sure unless there is a specification that says so.  If you are sure
of it, please make it clear in the specification so that the implementation
could be guided accordingly.



> In your example, it's very unfortunate that the real ZES implementation is
> not able to use the unextractable key generated by a KEM in another
> provider. I assume some considerations on a proper provider order might be
> necessary, or the user might need to think about picking up a provider
> explicitly.


Unfortunately, an application may not want to pick up a provider explicitly
or specify the order, especially if code update is required or the
application needs to work generally.


> You can imagine this becoming more of a problem in the KEM -> KDF -> Key
> Wrapping Cipher -> Data Encryption Cipher case, which is a very typical
> combination in today's secure data exchange.
>
>
Anyway, the issue is not new.  There were similar cases when RSASSA
algorithms were introduced.  There is not much one can do for the existing
RSA classes.  But for new classes, the story could be new.  That's why I
asked the question,  "what?s the different impact of parameters like
algorithm name, KEMParameterSpec, PublicKey/PrivateKey and
DerivedKeyParameterSpec?" If the parameters can be treated similar to
algorithm name and KEMParameterSpec that specified at getInstance method,
as if the classes has been designed as more immutable, the APIs may look
different.

-  var kemS = KEM.getInstance("DHKEM?);
+ var kemS = KEM.getInstance("DHKEM?, pkR, new
DerivedKeyParameterSpec("AES", 32));

Best,
Xuelei



> Thanks,
> Max
>
>
> > On Feb 4, 2023, at 10:44 AM, Xuelei Fan <xuelei.f at gmail.com> wrote:
> >
> > Hi,
> >
> > Thank you for the update.
> >
> > What?s the different impact of parameters like algorithm name,
> KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I?m not
> very sure of it.
> >
> > For example, at 2013, the following cord should work without any issues:
> > 1. var kemS = KEM.getInstance("DHKEM?);
> > 2. var pkR = retrieveKey();
> > 3. var e = kemS.newEncapsulater(pkR);
> > 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
> > 5. var secS = enc.key();
> > 6. sendBytes(enc.encapsulation());
> >
> >
> > At 2023, a new DerivedKeyParameterSpec algorithm or spec could be
> defined.  For example, the new algorithm is ?ZES?.  An application may use
> ?ZES" as:
> >
> > 1. var kemS = KEM.getInstance("DHKEM?);
> > 2. var pkR = retrieveKey();
> > 3. var e = kemS.newEncapsulater(pkR);
> > - 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
> > + 4. var enc = e.encapsulate(new DerivedKeyParameterSpec(?ZES", 32));
> > 5. var secS = enc.key();
> > 6. sendBytes(enc.encapsulation());
> >
> >
> > The provider A implemented before 2023 cannot support AES, and another
> provider B updated after 2023 could.  Suppose there are two providers, and
> provider A is preferred, will the application that use ?ZES? work as
> expected (choose provider B)?  Per the current JEP, It looks like provider
> A will be selected at line 3, and exception could be thrown at line 4.
> >
> > Thanks,
> > Xuelei
> >
> >> On Feb 3, 2023, at 2:53 PM, Wei-Jun Wang <weijun.wang at oracle.com>
> wrote:
> >>
> >> Hi All,
> >>
> >> Thanks for all the feedbacks. One of them [1] from Bernd Eckenfels is
> about Hybrid TLS Key Exchange. I read the IETF draft on it [2] and noticed
> something that the current KEM API cannot handle. It says the 2 ciphertext
> for each sub-KEM will be concatenated into a longer byte array as the
> ciphertext of the hybrid KEM. This brings up a problem on the decapsulator
> side: how can we split the long array into two if we don't know the size of
> each sub-ciphertext?
> >>
> >> David Hook mentioned that RSA-KEM has a similar problem.
> >>
> >> Therefore we decide to add a getCiphertextSize() method, and it can
> only be called after the private key is known. The decapsulation will be
> broken into multiple steps: the key is provided first, you have a chance to
> get the ciphertext size, and then perform the actual decapsulation. But
> instead of choosing Signature's initSign-then-sign approach which is on the
> same object and thus not thread-safe and mutable, the 1st step will return
> a Decapsulator object and this Decapsulator is used to perform the other
> steps, including the new size retrieval methods and the actual
> decapsulation function. The same is done on the encapsulation side.
> >>
> >> We also take this chance to rename "ciphertext" into "key encapsulation
> message". This is the name used in the PQC APIs [4] and this avoids
> confusing with encryption output of a Cipher. This is also a suggestion
> from David Hook.
> >>
> >> Please take a look. The updated JEP is still at
> https://openjdk.org/jeps/8301034.
> >>
> >> Thanks,
> >> Max
> >>
> >> [1]
> https://urldefense.com/v3/__https://mastodon.social/@eckes at zusammenkunft.net/109752008992193461__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXz4sePXo4$
> >> [2]
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html*name-transmitting-public-keys-an__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzNgH0GW8$
> <
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzwgQIN5I$
> >
> >> [3]
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5990*appendix-A.2__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzF2ogx9M$
> >> [4]
> https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzP6fP4sc$
> >>
> >>
> >>> On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang <weijun.wang at oracle.com>
> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> We are working on providing a new API for KEM (Key Encapsulation
> Mechanism). There will be a KEM class for users along with a KEMSpi class
> for security providers, and several other parameter and exception classes.
> >>>
> >>> You can read the draft JEP at https://openjdk.org/jeps/8301034.
> >>>
> >>> Feel free to add any comment here.
> >>>
> >>> Thanks,
> >>> Max
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230204/521e5629/attachment.htm>

From weijun.wang at oracle.com  Sun Feb  5 14:31:04 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Sun, 5 Feb 2023 14:31:04 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <CAPJ=zziA9G1uWuGso640T8N=XoP=gTDzk65Nn6qC2aPkRBDLkA@mail.gmail.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <FF0F7C44-C704-42C0-9FC6-ECDF50C715FB@gmail.com>
 <3AFC1A4A-4D80-40F3-8A01-E3E6A2B0D08D@oracle.com>
 <CAPJ=zziA9G1uWuGso640T8N=XoP=gTDzk65Nn6qC2aPkRBDLkA@mail.gmail.com>
Message-ID: <0F247645-5381-40BC-8BEF-B583A66E06E1@oracle.com>

var cek = KeyGenerator.getInstance("ZES").generateKey();

var ikm = KEM.getInstance("DHKEM?, pkR, new DerivedKeyParameterSpec("HKDF")).encapsulate().key();
var kek = KDF.getInstance("HKDF", ikm, new DerivedKeyParameterSpec("YESWrap", 32)).extract();
var ek = Cipher.getInstance("YESWrap").init(WRAP, k2).wrap(cek);

Hopefully we can find a YESWrap cipher than accepts kek and is able to wrap cek.

I'll try to see if this is describable when I'm fully back to work state on Monday.

Thanks and Happy Rice Ball Day!

--Max


> On Feb 5, 2023, at 1:24 AM, Xuelei Fan <xuelei.f at gmail.com> wrote:
> 
> 
> On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> Hi Xuelei,
> 
> This is a very interesting case since both crypto primitives (KEM and Cipher) require delayed provider selection.
> 
> I would say line 4 should not throw an exception. A KEM should not reject any algorithm name, because it might be any string. It's very likely that the shared secret is then be passed into a KDF. I don't think there is a convention on what the algorithm name should be used for the input of a KDF. Should any KEM reject the "TlsPreSharedSecret" algorithm name? Maybe not.
> 
> 
> I'm not sure unless there is a specification that says so.  If you are sure of it, please make it clear in the specification so that the implementation could be guided accordingly.
> 
>   In your example, it's very unfortunate that the real ZES implementation is not able to use the unextractable key generated by a KEM in another provider. I assume some considerations on a proper provider order might be necessary, or the user might need to think about picking up a provider explicitly.
>  Unfortunately, an application may not want to pick up a provider explicitly or specify the order, especially if code update is required or the application needs to work generally.
>  You can imagine this becoming more of a problem in the KEM -> KDF -> Key Wrapping Cipher -> Data Encryption Cipher case, which is a very typical combination in today's secure data exchange.
> 
> 
> Anyway, the issue is not new.  There were similar cases when RSASSA algorithms were introduced.  There is not much one can do for the existing RSA classes.  But for new classes, the story could be new.  That's why I asked the question,  "what?s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec?" If the parameters can be treated similar to algorithm name and KEMParameterSpec that specified at getInstance method, as if the classes has been designed as more immutable, the APIs may look different.
> 
> -  var kemS = KEM.getInstance("DHKEM?);
> + var kemS = KEM.getInstance("DHKEM?, pkR, new DerivedKeyParameterSpec("AES", 32));
> 
> Best,
> Xuelei
> 
>   Thanks,
> Max
> 
> 
> > On Feb 4, 2023, at 10:44 AM, Xuelei Fan <xuelei.f at gmail.com> wrote:
> > 
> > Hi,
> > 
> > Thank you for the update.  
> > 
> > What?s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I?m not very sure of it.  
> > 
> > For example, at 2013, the following cord should work without any issues:
> > 1. var kemS = KEM.getInstance("DHKEM?);
> > 2. var pkR = retrieveKey();
> > 3. var e = kemS.newEncapsulater(pkR);
> > 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
> > 5. var secS = enc.key();
> > 6. sendBytes(enc.encapsulation());
> > 
> > 
> > At 2023, a new DerivedKeyParameterSpec algorithm or spec could be defined.  For example, the new algorithm is ?ZES?.  An application may use ?ZES" as:
> > 
> > 1. var kemS = KEM.getInstance("DHKEM?);
> > 2. var pkR = retrieveKey();
> > 3. var e = kemS.newEncapsulater(pkR);
> > - 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
> > + 4. var enc = e.encapsulate(new DerivedKeyParameterSpec(?ZES", 32));
> > 5. var secS = enc.key();
> > 6. sendBytes(enc.encapsulation());
> > 
> > 
> > The provider A implemented before 2023 cannot support AES, and another provider B updated after 2023 could.  Suppose there are two providers, and provider A is preferred, will the application that use ?ZES? work as expected (choose provider B)?  Per the current JEP, It looks like provider A will be selected at line 3, and exception could be thrown at line 4.
> > 
> > Thanks,
> > Xuelei
> > 
> >> On Feb 3, 2023, at 2:53 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> >> 
> >> Hi All,
> >> 
> >> Thanks for all the feedbacks. One of them [1] from Bernd Eckenfels is about Hybrid TLS Key Exchange. I read the IETF draft on it [2] and noticed something that the current KEM API cannot handle. It says the 2 ciphertext for each sub-KEM will be concatenated into a longer byte array as the ciphertext of the hybrid KEM. This brings up a problem on the decapsulator side: how can we split the long array into two if we don't know the size of each sub-ciphertext?
> >> 
> >> David Hook mentioned that RSA-KEM has a similar problem.
> >> 
> >> Therefore we decide to add a getCiphertextSize() method, and it can only be called after the private key is known. The decapsulation will be broken into multiple steps: the key is provided first, you have a chance to get the ciphertext size, and then perform the actual decapsulation. But instead of choosing Signature's initSign-then-sign approach which is on the same object and thus not thread-safe and mutable, the 1st step will return a Decapsulator object and this Decapsulator is used to perform the other steps, including the new size retrieval methods and the actual decapsulation function. The same is done on the encapsulation side.
> >> 
> >> We also take this chance to rename "ciphertext" into "key encapsulation message". This is the name used in the PQC APIs [4] and this avoids confusing with encryption output of a Cipher. This is also a suggestion from David Hook.
> >> 
> >> Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.
> >> 
> >> Thanks,
> >> Max
> >> 
> >> [1] https://urldefense.com/v3/__https://mastodon.social/@eckes at zusammenkunft.net/109752008992193461__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXz4sePXo4$ 
> >> [2] https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html*name-transmitting-public-keys-an__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzNgH0GW8$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzwgQIN5I$ >
> >> [3] https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5990*appendix-A.2__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzF2ogx9M$ 
> >> [4] https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzP6fP4sc$ 
> >> 
> >> 
> >>> On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> >>> 
> >>> Hi All,
> >>> 
> >>> We are working on providing a new API for KEM (Key Encapsulation Mechanism). There will be a KEM class for users along with a KEMSpi class for security providers, and several other parameter and exception classes.
> >>> 
> >>> You can read the draft JEP at https://openjdk.org/jeps/8301034.
> >>> 
> >>> Feel free to add any comment here.
> >>> 
> >>> Thanks,
> >>> Max
> 
> 


From jwaters at openjdk.org  Sun Feb  5 15:57:50 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Feb 2023 15:57:50 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
Message-ID: <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>

On Sat, 4 Feb 2023 17:23:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I have no objection to the code change. Or maybe you can change it to the windows line extension character `^`.
>> 
>> I was using this command for quick recompiling while writing this code, and it's in a `cmd.exe` window launched with a start menu item named something like "Visual Studio Developing Environment". I wrote it inside here to remind myself if I need to rework on it.
>
> I used to have Visual Studio compilers available in my Cygwin environment. Now I don't, I just point the `configure` script to the batch file which configures the environment.
> 
> If this command is supposed to be run in `cmd.exe`, then `^` makes more sense: one could just copy & paste the command.

I've just tried copying and pasting the command with ^ instead of \ and cmd doesn't seem to be correctly reading the compile command either even with ^, is there something I'm missing here?

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

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


From jwaters at openjdk.org  Sun Feb  5 16:28:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Feb 2023 16:28:14 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v3]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <PLFBOlGFegk6k9TN6leiJlUSM58YGt5HScXAjj5pVZY=.fcf3d3b1-f57f-480f-8c5f-5f330f06bdeb@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

  awt_Toolkit.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/6b17f624..99aed8a0

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

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

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


From weijun at openjdk.org  Sun Feb  5 17:30:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 5 Feb 2023 17:30:48 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
 <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
Message-ID: <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>

On Sun, 5 Feb 2023 15:55:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I used to have Visual Studio compilers available in my Cygwin environment. Now I don't, I just point the `configure` script to the batch file which configures the environment.
>> 
>> If this command is supposed to be run in `cmd.exe`, then `^` makes more sense: one could just copy & paste the command.
>
> I've just tried copying and pasting the command with ^ instead of \ and cmd doesn't seem to be correctly reading the compile command either even with ^, is there something I'm missing here?

I don't know. I'm quite sure I was using the full command in `cmd.exe` after calling some `vcvars64.bat`. I added the `` character because it's a little long to be recorded here. I don't really care which separator is used. You can remove the `` character. We don't need to spend too much time on this.

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

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


From jwaters at openjdk.org  Mon Feb  6 03:37:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 6 Feb 2023 03:37:03 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v4]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <mzI7SEq3zv3egItZTlRd66dZ0tyhRKB0_1ngBxgiVWg=.4c93a2ea-7ba3-469a-8df9-f46603e58d23@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

  sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/99aed8a0..24becec8

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

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

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


From jwaters at openjdk.org  Mon Feb  6 03:37:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 6 Feb 2023 03:37:04 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
 <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
 <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>
Message-ID: <SI9ksB_ugdnmIP9OF3CPWqM_HDjZcHyLlwmsg8L6oiY=.b3114edb-bbfe-48f0-a086-39f79f713f6b@github.com>

On Sun, 5 Feb 2023 17:26:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I've just tried copying and pasting the command with ^ instead of \ and cmd doesn't seem to be correctly reading the compile command either even with ^, is there something I'm missing here?
>
> I don't know. I'm quite sure I was using the full command in `cmd.exe` after calling some `vcvars64.bat`. I added the `` character because it's a little long to be recorded here. I don't really care which separator is used. You can remove the `` character. We don't need to spend too much time on this.

Honestly, with all of this confusion around the command line, I think I'd rather just avoid the issue entirely by turning this into a multiline comment so the backslash doesn't cause compiler warnings

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

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


From weijun at openjdk.org  Mon Feb  6 04:13:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 04:13:51 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification [v2]
In-Reply-To: <YilxN3T7_VnEafPoBo2fCX8it17Ix_UhIR3EecP3Slw=.45388665-4deb-4c33-925a-7cd80d03b837@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
 <YilxN3T7_VnEafPoBo2fCX8it17Ix_UhIR3EecP3Slw=.45388665-4deb-4c33-925a-7cd80d03b837@github.com>
Message-ID: <rY_OMVgmAGHp9-Wa8elz4p1J-7Wz1r0c-pC4xhYaT7I=.5583dd99-0757-4d15-8942-90feec083013@github.com>

On Fri, 3 Feb 2023 08:01:21 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR resurrects VerifySignedJar which currently tests nothing.
>> 
>> VerifySignedJar currently verifies a binary JAR which was signed with SHA-1 back in April 2000. Because SHA-1 signed JARs has been disabled for a while, the JAR is treated as unsigned so the test doesn't really test anything as of now. 
>> 
>> The test is updated in the following ways:
>> 
>> - The JAR used for verification is now created and signed with SHA-256 by the test itself
>> - The test is updated to check that the JAR is actually signed and with the expected certificate 
>> - JarEntry InputStreams are now read fully to ensure verification of all entries
>> - Objects.requireNonNull is used to check that entries returned by  getEntry, getJarEntry are non-null 
>> - The existing binary JAR is retired
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add whitespace after "if"
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/util/jar/JarFile/VerifySignedJar.java line 76:

> 74:             // Read entry by name
> 75:             ZipEntry ze = Objects.requireNonNull(jf.getEntry("getprop.class"));
> 76:             JarEntry je = Objects.requireNonNull(jf.getJarEntry("getprop.class"));

There is no need to store the outputs to variables.

Also, for the `Unreached` lines below, we have `jdk.test.lib.Utils::runAndCheckException` which is good at catching exceptions.

            Utils.runAndCheckException(() -> jf.getEntry(null), NullPointerException.class);
            Utils.runAndCheckException(() -> jf.getJarEntry(null), NullPointerException.class);
            Utils.runAndCheckException(() -> jf.getInputStream(null), NullPointerException.class);

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

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


From yan at openjdk.org  Mon Feb  6 07:06:50 2023
From: yan at openjdk.org (Yuri Nesterenko)
Date: Mon, 6 Feb 2023 07:06:50 GMT
Subject: RFR: 8301760: Fix possible leak in SpNegoContext dispose
In-Reply-To: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
References: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
Message-ID: <3WK3SH2PfAyh1Yk3S4HTuRJTYtQAdNRtWtbTk-tWgeg=.ca652281-e60c-4447-b820-8e7033bca8f3@github.com>

On Fri, 3 Feb 2023 14:12:42 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> This small change should fix a possible under certain circumstances native memory leak. In fact, the actual leak was reported in production.

Pre-submit windows64 "hs/tier1 compiler" test timeout  failure is apparently unrelated (detected in other PRs submitted around the same time)

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

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


From yan at openjdk.org  Mon Feb  6 07:11:58 2023
From: yan at openjdk.org (Yuri Nesterenko)
Date: Mon, 6 Feb 2023 07:11:58 GMT
Subject: RFR: 8301760: Fix possible leak in SpNegoContext dispose
In-Reply-To: <gmFR2h1jOZXF0yn8aZhfPLimEgvsOTugZRgBn3IsFBg=.1c387197-b7ee-4dbd-8cf7-67c82e1f782d@github.com>
References: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
 <gmFR2h1jOZXF0yn8aZhfPLimEgvsOTugZRgBn3IsFBg=.1c387197-b7ee-4dbd-8cf7-67c82e1f782d@github.com>
Message-ID: <H4hRerjn9COhRwByfH8Q2sNGtV2LRR5t6XUzjBsQMGU=.ba35f931-4efe-447c-92ee-fb8511f70016@github.com>

On Fri, 3 Feb 2023 16:21:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This small change should fix a possible under certain circumstances native memory leak. In fact, the actual leak was reported in production.
>
> Looks good to me. I'll run some tests, does not look like there will be an unexpected exception thrown.

Thank you @wangweij ! I'm integrating.

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

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


From yan at openjdk.org  Mon Feb  6 07:12:00 2023
From: yan at openjdk.org (Yuri Nesterenko)
Date: Mon, 6 Feb 2023 07:12:00 GMT
Subject: Integrated: 8301760: Fix possible leak in SpNegoContext dispose
In-Reply-To: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
References: <Letm9862sqyy-GeGCaK8RLzqibLWoeqPb-OCUcCcD-I=.c3eef37d-3450-45be-9c30-9d378953c0d1@github.com>
Message-ID: <c8vjoNwXb_TMfKRWI_eiLKtEI45D5TuTdK0-GI9NbJY=.f9dae3a4-a593-4a3a-8607-e90f213aeeea@github.com>

On Fri, 3 Feb 2023 14:12:42 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> This small change should fix a possible under certain circumstances native memory leak. In fact, the actual leak was reported in production.

This pull request has now been integrated.

Changeset: 3f3356bc
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f3356bcbd2b2fbc545263dc70a48ee931a4e56b
Stats:     5 lines in 1 file changed: 4 ins; 1 del; 0 mod

8301760: Fix possible leak in SpNegoContext dispose

Reviewed-by: weijun

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

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


From duke at openjdk.org  Mon Feb  6 09:21:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 09:21:29 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification [v3]
In-Reply-To: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
Message-ID: <eWh5eBxyLopdZ3ABig5zACxoQIfWcPo7STQjwdodV58=.f41920af-150d-47d1-81c0-e7af2744c957@github.com>

> This PR resurrects VerifySignedJar which currently tests nothing.
> 
> VerifySignedJar currently verifies a binary JAR which was signed with SHA-1 back in April 2000. Because SHA-1 signed JARs has been disabled for a while, the JAR is treated as unsigned so the test doesn't really test anything as of now. 
> 
> The test is updated in the following ways:
> 
> - The JAR used for verification is now created and signed with SHA-256 by the test itself
> - The test is updated to check that the JAR is actually signed and with the expected certificate 
> - JarEntry InputStreams are now read fully to ensure verification of all entries
> - Objects.requireNonNull is used to check that entries returned by  getEntry, getJarEntry are non-null 
> - The existing binary JAR is retired

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

 - Merge remote-tracking branch 'eirbjo/verify-signed-jar' into verify-signed-jar
 - Add whitespace after "if"
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Remove unused local variables, replace Unreached/catch with runAndCheckException
 - Merge branch 'master' into verify-signed-jar
 - Simplify checkSignedBy by using JarEntry.getCertificates() instead of JarEntry.getCodeSigners()
 - o Update VerifySignedJar test to create and sign a JAR file instead of reading a binary JAR from version control.
   o Make sure that verification is actually triggered by reading the entire file contents of each entry
   o Check that entries are signed with the expected certificate.
   o Use Objects.requireNonNull to check that entries returned by  getEntry, getJarEntry are non-null
   o Retire the now unused binary test JAR "thawjar.jar"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12206/files
  - new: https://git.openjdk.org/jdk/pull/12206/files/8ff06744..c26b27da

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

  Stats: 5306 lines in 266 files changed: 1548 ins; 1145 del; 2613 mod
  Patch: https://git.openjdk.org/jdk/pull/12206.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12206/head:pull/12206

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


From duke at openjdk.org  Mon Feb  6 09:21:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 09:21:30 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification [v2]
In-Reply-To: <rY_OMVgmAGHp9-Wa8elz4p1J-7Wz1r0c-pC4xhYaT7I=.5583dd99-0757-4d15-8942-90feec083013@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
 <YilxN3T7_VnEafPoBo2fCX8it17Ix_UhIR3EecP3Slw=.45388665-4deb-4c33-925a-7cd80d03b837@github.com>
 <rY_OMVgmAGHp9-Wa8elz4p1J-7Wz1r0c-pC4xhYaT7I=.5583dd99-0757-4d15-8942-90feec083013@github.com>
Message-ID: <dIYQ_cjNhwES6y3zXNS7tB6R_Zb5F93Sv6XQ2hzBcZI=.294278ae-835c-4b90-b263-123016785041@github.com>

On Mon, 6 Feb 2023 04:09:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add whitespace after "if"
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/java/util/jar/JarFile/VerifySignedJar.java line 76:
> 
>> 74:             // Read entry by name
>> 75:             ZipEntry ze = Objects.requireNonNull(jf.getEntry("getprop.class"));
>> 76:             JarEntry je = Objects.requireNonNull(jf.getJarEntry("getprop.class"));
> 
> There is no need to store the outputs to variables.
> 
> Also, for the `Unreached` lines below, we have `jdk.test.lib.Utils::runAndCheckException` which is good at catching exceptions.
> 
>             Utils.runAndCheckException(() -> jf.getEntry(null), NullPointerException.class);
>             Utils.runAndCheckException(() -> jf.getJarEntry(null), NullPointerException.class);
>             Utils.runAndCheckException(() -> jf.getInputStream(null), NullPointerException.class);

I've removed the local variables. Just in case there was some intent in showing that the methods excercise both ZipFile and JarFile, I updated the comment above slightly.

I also replaced the exception checking code as suggested. I opted for a static import, is that ok?

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

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


From duke at openjdk.org  Mon Feb  6 13:32:23 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 6 Feb 2023 13:32:23 GMT
Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation [v6]
In-Reply-To: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
Message-ID: <wjqxT2SqEyoGl4G-Ppzjwr44NG6LWOEzMy7I9zr0YBw=.d0ff426c-82e5-4d20-8692-7470af55a0ac@github.com>

> Refactored the code a little bit and updated the test for changes to the TLS state machine.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - fixed conflict
 - updated SSL context
 - fixed conflict
 - removed import, updated ProblemList
 - Merge branch 'master' into engine-close
 - Merge branch 'master' into engine-close
 - removed unnecessary line
 - 8298868: Update EngineCloseOnAlert.java for changes to TLS implementation

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

Changes: https://git.openjdk.org/jdk/pull/11903/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11903&range=05
  Stats: 61 lines in 2 files changed: 14 ins; 14 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/11903.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11903/head:pull/11903

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


From duke at openjdk.org  Mon Feb  6 15:03:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:33 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
Message-ID: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>

After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.

This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 

ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 

Additionally, this PR suggest to make the following updates to getEntryPos:

- The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
- A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
- The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)

(My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)

I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):

Baseline:

Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op



PR:


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op


To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):


Percentile Baseline Patch
50?%          23155 21149
75?%          23598 21454
90?%          23989 21691
95?%          24238 21973
99?%          25270 22446
STDEV           792   549
Count           500   500

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

Commit messages:
 - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
 - Rename test to InvalidBytesInEntryNameOrComment
 - Adjust whitespace
 - Some minor improvements to code comments
 - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
 - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
 - ByteBuffers for reading ZIP files must be little-endian
 - Produce template ZIP as a byte[] instead of writing it to disk
 - Improve summary for the test
 - Simplify comment for "name/" match
 - ... and 7 more: https://git.openjdk.org/jdk/compare/dff41316...3ca98e21

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

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


From duke at openjdk.org  Mon Feb  6 15:03:35 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:35 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <8y5f1YxDu1ALUEanR55V1S4za2fgUdWcarnFVqU3AR8=.67a750cd-d1db-4f0f-8a55-f3c2938d2090@github.com>

On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

As suggested by @cl4es, I've replaced the use of ArraySupport.mismatch with Arrays.mismatch. The added range checks seems to give a regression of ~3% on the getEntryHit micro.

I realized that encoding to bytes and then comparing to CEN bytes might not be safe for encodings were multiple representations is possible for the same code points. So I moved string/byte array comparison into ZipCoder, which can now decode from CEN and compare as in the current code. Micros indicate this has no performance impact.

src/java.base/share/classes/java/lang/System.java line 2678:

> 2676:                 }
> 2677:                 return Arrays.mismatch(encoded, 0, encoded.length, b, fromIndex, toIndex);
> 2678:             }

Leaving the ArraySupport.mismatch code here for now if anyone wants to investigate the ~3% regression introduced by the range checks in Arrays.mismatch

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

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


From redestad at openjdk.org  Mon Feb  6 15:03:39 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:39 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>

On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Filed JDK-8301873 for this, update PR title when you're ready.

src/java.base/share/classes/java/lang/System.java line 2668:

> 2666:             @Override
> 2667:             public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
> 2668:                 byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);

I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably `str.isAscii() ? ...`. The ASCII check will have to look at the bytes, so will incur a minor penalty.

Good news is that you should already be able to do this with what's already exposed via `JLA.getBytesNoRepl(str, StandardCharsets.UTF_8)`, so no need for more shared secrets.

src/java.base/share/classes/java/lang/System.java line 2671:

> 2669:                 if (false) {
> 2670:                     // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
> 2671:                     int aLength = encoded.length;

Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (`encoded, 0, encoded.length`).

As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:

Benchmark                                     (size)  Mode  Cnt   Score   Error  Units
ArraysMismatch.Char.differentSubrangeMatches      90  avgt   10  12.165 ? 0.074  ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
ArraysMismatch.Char.subrangeMatches               90  avgt   10  10.748 ? 0.006  ns/op # mismatch(a, b, bFrom, bTo)

This might be something we can solve in the JITs without having to add new methods to `java.util.Arrays` to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.

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

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


From duke at openjdk.org  Mon Feb  6 15:03:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:41 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
Message-ID: <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>

On Sun, 5 Feb 2023 22:13:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> src/java.base/share/classes/java/lang/System.java line 2668:
> 
>> 2666:             @Override
>> 2667:             public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
>> 2668:                 byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);
> 
> I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably `str.isAscii() ? ...`. The ASCII check will have to look at the bytes, so will incur a minor penalty.
> 
> Good news is that you should already be able to do this with what's already exposed via `JLA.getBytesNoRepl(str, StandardCharsets.UTF_8)`, so no need for more shared secrets.

Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.

I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.

> src/java.base/share/classes/java/lang/System.java line 2671:
> 
>> 2669:                 if (false) {
>> 2670:                     // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
>> 2671:                     int aLength = encoded.length;
> 
> Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (`encoded, 0, encoded.length`).
> 
> As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:
> 
> Benchmark                                     (size)  Mode  Cnt   Score   Error  Units
> ArraysMismatch.Char.differentSubrangeMatches      90  avgt   10  12.165 ? 0.074  ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
> ArraysMismatch.Char.subrangeMatches               90  avgt   10  10.748 ? 0.006  ns/op # mismatch(a, b, bFrom, bTo)
> 
> This might be something we can solve in the JITs without having to add new methods to `java.util.Arrays` to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.

Interesting. Would be nice to solve this in the JIT!

This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.

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

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


From duke at openjdk.org  Mon Feb  6 15:03:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
Message-ID: <8VuNna-hLp1SzcAKlCIepnlXabh_U4tYZIDRGEpKu5g=.df5d974f-e7c9-4c3d-be66-63117a43c597@github.com>

On Mon, 6 Feb 2023 11:47:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2668:
>> 
>>> 2666:             @Override
>>> 2667:             public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
>>> 2668:                 byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);
>> 
>> I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably `str.isAscii() ? ...`. The ASCII check will have to look at the bytes, so will incur a minor penalty.
>> 
>> Good news is that you should already be able to do this with what's already exposed via `JLA.getBytesNoRepl(str, StandardCharsets.UTF_8)`, so no need for more shared secrets.
>
> Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.
> 
> I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.

getBytesNoRepl throws CharacterCodingException "for malformed input or unmappable characters".

This should never happen since initCEN should already reject it. If it should happen anyway, I return NO_MATCH which will ignore the match just like the catch in getEntryPos currently does.

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

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


From redestad at openjdk.org  Mon Feb  6 15:03:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <8VuNna-hLp1SzcAKlCIepnlXabh_U4tYZIDRGEpKu5g=.df5d974f-e7c9-4c3d-be66-63117a43c597@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
 <8VuNna-hLp1SzcAKlCIepnlXabh_U4tYZIDRGEpKu5g=.df5d974f-e7c9-4c3d-be66-63117a43c597@github.com>
Message-ID: <Cdn107SRWSWB4K34Mmk2CZK_gK4Aw09q-EWyVRPBVVA=.56db4621-15fd-4acf-9ca3-cf3dc1ad4485@github.com>

On Mon, 6 Feb 2023 12:01:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.
>> 
>> I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.
>
> getBytesNoRepl throws CharacterCodingException "for malformed input or unmappable characters".
> 
> This should never happen since initCEN should already reject it. If it should happen anyway, I return NO_MATCH which will ignore the match just like the catch in getEntryPos currently does.

Yes, this should be fine.

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

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


From redestad at openjdk.org  Mon Feb  6 15:03:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
Message-ID: <eCFHU69SKQpSlZyHJfmABBrCNtUcKIYh9zPZTmPpSdk=.5f1a6051-5e06-4290-8225-14e6e602492e@github.com>

On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2671:
>> 
>>> 2669:                 if (false) {
>>> 2670:                     // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
>>> 2671:                     int aLength = encoded.length;
>> 
>> Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (`encoded, 0, encoded.length`).
>> 
>> As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:
>> 
>> Benchmark                                     (size)  Mode  Cnt   Score   Error  Units
>> ArraysMismatch.Char.differentSubrangeMatches      90  avgt   10  12.165 ? 0.074  ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
>> ArraysMismatch.Char.subrangeMatches               90  avgt   10  10.748 ? 0.006  ns/op # mismatch(a, b, bFrom, bTo)
>> 
>> This might be something we can solve in the JITs without having to add new methods to `java.util.Arrays` to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.
>
> Interesting. Would be nice to solve this in the JIT!
> 
> This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.

Right. I might have fumbled this experiment a bit, and perhaps your setup would inline and then eliminate some of the known-in-range checks already. 

Though we have intrinsified some of the `Preconditions.check*` methods in the past to help improve range checks, but the `checkFromToIndex` method that would be applicable here has not been intrinsified. It might be a reasonable path forward to replace `Arrays.rangeCheck` with `Preconditions.checkFromToIndex` and then look at intrinsifying that method to help eliminating or optimizing some of the checks.

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

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


From redestad at openjdk.org  Mon Feb  6 15:03:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:47 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <eCFHU69SKQpSlZyHJfmABBrCNtUcKIYh9zPZTmPpSdk=.5f1a6051-5e06-4290-8225-14e6e602492e@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
 <eCFHU69SKQpSlZyHJfmABBrCNtUcKIYh9zPZTmPpSdk=.5f1a6051-5e06-4290-8225-14e6e602492e@github.com>
Message-ID: <FpTjuqARcCTWFJv5H1LBcyL5fYSp5XXRvhGaFWqP2N8=.dae5bb05-fead-4fe7-8a20-9882b13962da@github.com>

On Mon, 6 Feb 2023 14:27:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Interesting. Would be nice to solve this in the JIT!
>> 
>> This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.
>
> Right. I might have fumbled this experiment a bit, and perhaps your setup would inline and then eliminate some of the known-in-range checks already. 
> 
> Though we have intrinsified some of the `Preconditions.check*` methods in the past to help improve range checks, but the `checkFromToIndex` method that would be applicable here has not been intrinsified. It might be a reasonable path forward to replace `Arrays.rangeCheck` with `Preconditions.checkFromToIndex` and then look at intrinsifying that method to help eliminating or optimizing some of the checks.

Nevermind, I had a flaw in my experiment and seems the first range check in a call like `Arrays.mismatch(encoded, 0, encoded.length, b, off, off+len);` should be eliminated. So perhaps you're seeing the cost of the second range check, which might be unavoidable to be safe (zip meta data could otherwise be doctored to try and perform out of bounds reads via intrinsified code)

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

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


From duke at openjdk.org  Mon Feb  6 15:03:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:49 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <8y5f1YxDu1ALUEanR55V1S4za2fgUdWcarnFVqU3AR8=.67a750cd-d1db-4f0f-8a55-f3c2938d2090@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <8y5f1YxDu1ALUEanR55V1S4za2fgUdWcarnFVqU3AR8=.67a750cd-d1db-4f0f-8a55-f3c2938d2090@github.com>
Message-ID: <UO7zdMbi3wAPMizFEKQ3dVuxLC4by60G8zVZMhsbzwg=.8f145eb7-d571-4244-80b4-85ab2dbab760@github.com>

On Mon, 30 Jan 2023 14:20:58 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> src/java.base/share/classes/java/lang/System.java line 2678:
> 
>> 2676:                 }
>> 2677:                 return Arrays.mismatch(encoded, 0, encoded.length, b, fromIndex, toIndex);
>> 2678:             }
> 
> Leaving the ArraySupport.mismatch code here for now if anyone wants to investigate the ~3% regression introduced by the range checks in Arrays.mismatch

The performance hit of using Arrays.mismatch instead of  ArraysSupport might be more like 5% actually:


Benchmark                             (size)  Mode  Cnt    Score    Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   59.149 ?  0.820  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   73.250 ?  1.114  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  103.377 ?  1.118  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  115.418 ?  2.767  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   22.200 ?  0.145  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   22.528 ?  0.271  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   57.359 ?  0.428  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   68.013 ?  2.070  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   72.407 ?  0.603  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   82.875 ? 11.094  ns/op

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

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


From duke at openjdk.org  Mon Feb  6 15:21:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:21:10 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Spelling fix in test data for non-ascii latin1 string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/3ca98e21..d0c12325

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

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

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


From duke at openjdk.org  Mon Feb  6 15:21:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:21:11 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
Message-ID: <aetLV3k8G1u-yGPlhDGy_AskhX2NqM5nmVLj8kHJfY4=.41d597fb-cc92-4398-9f54-f152b8e1d40c@github.com>

On Mon, 6 Feb 2023 15:17:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spelling fix in test data for non-ascii latin1 string

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 126:

> 124:         // latin1, but not ASCII
> 125:         String entryName = "sm?rg?rdsbord";
> 126: 

@cl4es Are we ok with non-ASCII in source files? I'd hate to escape this ;-)

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

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


From weijun at openjdk.org  Mon Feb  6 15:40:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 15:40:54 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification [v3]
In-Reply-To: <eWh5eBxyLopdZ3ABig5zACxoQIfWcPo7STQjwdodV58=.f41920af-150d-47d1-81c0-e7af2744c957@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
 <eWh5eBxyLopdZ3ABig5zACxoQIfWcPo7STQjwdodV58=.f41920af-150d-47d1-81c0-e7af2744c957@github.com>
Message-ID: <fNnxFR1WFW71rOAx9_9KCImr0JPLLwH3YMF6pCJNNOI=.96222f6a-fd1f-4ad3-b7bb-acae7672dbe1@github.com>

On Mon, 6 Feb 2023 09:21:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR resurrects VerifySignedJar which currently tests nothing.
>> 
>> VerifySignedJar currently verifies a binary JAR which was signed with SHA-1 back in April 2000. Because SHA-1 signed JARs has been disabled for a while, the JAR is treated as unsigned so the test doesn't really test anything as of now. 
>> 
>> The test is updated in the following ways:
>> 
>> - The JAR used for verification is now created and signed with SHA-256 by the test itself
>> - The test is updated to check that the JAR is actually signed and with the expected certificate 
>> - JarEntry InputStreams are now read fully to ensure verification of all entries
>> - Objects.requireNonNull is used to check that entries returned by  getEntry, getJarEntry are non-null 
>> - The existing binary JAR is retired
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'eirbjo/verify-signed-jar' into verify-signed-jar
>  - Add whitespace after "if"
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Remove unused local variables, replace Unreached/catch with runAndCheckException
>  - Merge branch 'master' into verify-signed-jar
>  - Simplify checkSignedBy by using JarEntry.getCertificates() instead of JarEntry.getCodeSigners()
>  - o Update VerifySignedJar test to create and sign a JAR file instead of reading a binary JAR from version control.
>    o Make sure that verification is actually triggered by reading the entire file contents of each entry
>    o Check that entries are signed with the expected certificate.
>    o Use Objects.requireNonNull to check that entries returned by  getEntry, getJarEntry are non-null
>    o Retire the now unused binary test JAR "thawjar.jar"

Looks good. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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


From weijun at openjdk.org  Mon Feb  6 15:40:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 15:40:57 GMT
Subject: RFR: 8301167: Update VerifySignedJar to actually exercise and test
 verification [v2]
In-Reply-To: <dIYQ_cjNhwES6y3zXNS7tB6R_Zb5F93Sv6XQ2hzBcZI=.294278ae-835c-4b90-b263-123016785041@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
 <YilxN3T7_VnEafPoBo2fCX8it17Ix_UhIR3EecP3Slw=.45388665-4deb-4c33-925a-7cd80d03b837@github.com>
 <rY_OMVgmAGHp9-Wa8elz4p1J-7Wz1r0c-pC4xhYaT7I=.5583dd99-0757-4d15-8942-90feec083013@github.com>
 <dIYQ_cjNhwES6y3zXNS7tB6R_Zb5F93Sv6XQ2hzBcZI=.294278ae-835c-4b90-b263-123016785041@github.com>
Message-ID: <QYIcIxBVq7JOfho5t4u9ntKnFknASZzNg4YyqNDV_IA=.da2b7f0f-a77b-4542-811d-a8bb83a2852d@github.com>

On Mon, 6 Feb 2023 09:16:45 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> test/jdk/java/util/jar/JarFile/VerifySignedJar.java line 76:
>> 
>>> 74:             // Read entry by name
>>> 75:             ZipEntry ze = Objects.requireNonNull(jf.getEntry("getprop.class"));
>>> 76:             JarEntry je = Objects.requireNonNull(jf.getJarEntry("getprop.class"));
>> 
>> There is no need to store the outputs to variables.
>> 
>> Also, for the `Unreached` lines below, we have `jdk.test.lib.Utils::runAndCheckException` which is good at catching exceptions.
>> 
>>             Utils.runAndCheckException(() -> jf.getEntry(null), NullPointerException.class);
>>             Utils.runAndCheckException(() -> jf.getJarEntry(null), NullPointerException.class);
>>             Utils.runAndCheckException(() -> jf.getInputStream(null), NullPointerException.class);
>
> I've removed the local variables. Just in case there was some intent in showing that the methods excercise both ZipFile and JarFile, I updated the comment above slightly.
> 
> I also replaced the exception checking code as suggested. I opted for a static import, is that ok?

That's OK.

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

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


From duke at openjdk.org  Mon Feb  6 15:47:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:47:00 GMT
Subject: Integrated: 8301167: Update VerifySignedJar to actually exercise and
 test verification
In-Reply-To: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
References: <5UbuRQPAEB6bCoMVbyQGz49Ulfi9gpNtNn9DbN0l-_c=.c3797cbe-3814-45a4-a2a6-12e2e6c8c535@github.com>
Message-ID: <fvvGMEwIEqlT2xZa4ao8ARuUUSToB9gdAqDjC-5YGiQ=.ebfff9f3-f785-4844-90b9-ea9799a6bade@github.com>

On Wed, 25 Jan 2023 17:38:13 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR resurrects VerifySignedJar which currently tests nothing.
> 
> VerifySignedJar currently verifies a binary JAR which was signed with SHA-1 back in April 2000. Because SHA-1 signed JARs has been disabled for a while, the JAR is treated as unsigned so the test doesn't really test anything as of now. 
> 
> The test is updated in the following ways:
> 
> - The JAR used for verification is now created and signed with SHA-256 by the test itself
> - The test is updated to check that the JAR is actually signed and with the expected certificate 
> - JarEntry InputStreams are now read fully to ensure verification of all entries
> - Objects.requireNonNull is used to check that entries returned by  getEntry, getJarEntry are non-null 
> - The existing binary JAR is retired

This pull request has now been integrated.

Changeset: 05ea083b
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05ea083b0563ddacf3e38dc329ba00dc4bac9b29
Stats:     110 lines in 2 files changed: 84 ins; 12 del; 14 mod

8301167: Update VerifySignedJar to actually exercise and test verification

Reviewed-by: weijun

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

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


From weijun at openjdk.org  Mon Feb  6 15:47:52 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 15:47:52 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs [v2]
In-Reply-To: <C6eR-gsDGOO9u4-ELduSXdACSe_sdwkGW_p5hVuC3ug=.5fdb1397-16d0-4922-b8cb-33c5dcb859e0@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
 <C6eR-gsDGOO9u4-ELduSXdACSe_sdwkGW_p5hVuC3ug=.5fdb1397-16d0-4922-b8cb-33c5dcb859e0@github.com>
Message-ID: <47NuYXRJbBJslno6CYAQ9VwCzpyc-QY7y55Np-3Iwng=.02d5cd14-745c-42aa-a2a2-2589280266fa@github.com>

On Tue, 17 Jan 2023 18:54:13 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR adds test coverage for pending block files in signed JAR files
>> 
>> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
>> 
>> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
>> 
>> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make it more clear in the @summary tag that it is the block file that is pending, not the signature file
>  - Renamed test from PendingBlocksJar to more descriptive SignedJarPendingBlock

Marked as reviewed by weijun (Reviewer).

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

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


From redestad at openjdk.org  Mon Feb  6 15:55:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:55:52 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <aetLV3k8G1u-yGPlhDGy_AskhX2NqM5nmVLj8kHJfY4=.41d597fb-cc92-4398-9f54-f152b8e1d40c@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
 <aetLV3k8G1u-yGPlhDGy_AskhX2NqM5nmVLj8kHJfY4=.41d597fb-cc92-4398-9f54-f152b8e1d40c@github.com>
Message-ID: <C2b10FjDXIwxDfQoB3DuFjrfA1qzbQR3LbJ8HNN11G0=.c644ab25-5876-4917-bfdf-b8fba9734ffc@github.com>

On Mon, 6 Feb 2023 15:14:37 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 126:
> 
>> 124:         // latin1, but not ASCII
>> 125:         String entryName = "sm?rg?rdsbord";
>> 126: 
> 
> @cl4es Are we ok with non-ASCII in source files? I'd hate to escape this ;-)

As long as the file is UTF-8 encoded then I think it should be fine. Thanks for fixing the spelling before I could remark on it! :D

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

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


From redestad at openjdk.org  Mon Feb  6 15:58:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:58:52 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
Message-ID: <4y6TArTKErM-B-nDJCqh2482tTMiyCak05SI9wAqCfM=.3651c522-f00a-4e72-b757-18df5a0a6ae1@github.com>

On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spelling fix in test data for non-ascii latin1 string

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 153:

> 151:         // Need to skip past the length of the name and extra fields
> 152:         int nlen = buffer.getShort(off + NLEN);
> 153:         int elen = buffer.getShort(off + NLEN);

Is this supposed to say `ELEN`?

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

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


From redestad at openjdk.org  Mon Feb  6 16:02:53 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 16:02:53 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
Message-ID: <nDhwZYL6cilJsFpKp5Ub3puvmqNc5Cz8UP9wgx7ADXY=.7263f482-7375-45d2-9e25-242eab276860@github.com>

On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spelling fix in test data for non-ascii latin1 string

I think this looks good. Glad we can get this done without adding even more ways to peek into `String` internals.

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 158:

> 156:         int coff = off + CEN_HDR + nlen + elen;
> 157: 
> 158:         // Write invald bytes

`invalid`

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

Marked as reviewed by redestad (Reviewer).

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


From mullan at openjdk.org  Mon Feb  6 16:05:58 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Feb 2023 16:05:58 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers [v2]
In-Reply-To: <mx9TDYefF1veBBCkyQot9uvL0yTJuoeLVilbIEyemEU=.fbdeb5c2-c9b7-4e6f-ae60-952b74d27e3b@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
 <mx9TDYefF1veBBCkyQot9uvL0yTJuoeLVilbIEyemEU=.fbdeb5c2-c9b7-4e6f-ae60-952b74d27e3b@github.com>
Message-ID: <cG-Q65fvVK_47WUa2VSbqRjm-KgnMir5pzxlorL4nZM=.67c50d2e-cd25-425c-a8a4-29754fee3ede@github.com>

On Fri, 3 Feb 2023 16:11:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Keep the "NAME -> 1.2.3.4" mapping unchanged but modify "1.2.3.4 -> NAME" to "1.2.3.4 -> Name".
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   impl not necessary

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 603:

> 601:                         // add the name->oid and oid->name mappings if none exists
> 602:                         if (KnownOIDs.findMatch(upperStdAlgName) == null) {
> 603:                             // not override earlier entries if it exists

s/not/do not/

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 607:

> 605:                         }
> 606:                         if (KnownOIDs.findMatch(ostr) == null) {
> 607:                             // not override earlier entries if it exists

s/not/do not/

test/jdk/sun/security/x509/AlgorithmId/Uppercase.java line 30:

> 28:  * @summary AlgorithmId should keep lowercase characters from 3rd party providers
> 29:  * @modules java.base/sun.security.x509
> 30:  *          java.base/sun.security.util

Do you need this module?

test/jdk/sun/security/x509/AlgorithmId/Uppercase.java line 55:

> 53:         public ProviderImpl() {
> 54:             super("ProviderImpl", "1.0", "ProviderImpl");
> 55:             // It does not matter if we really provider an implementation

s/provider/provide/

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

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


From duke at openjdk.org  Mon Feb  6 16:14:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 16:14:14 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v3]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <kocafii57-tSO8NfHg_5ywyqC_5DMPWa07dbqdG7884=.1e6e34d0-1e26-4ea7-aa52-466908d45d16@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/d0c12325..2c5e7c2c

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

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

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


From duke at openjdk.org  Mon Feb  6 16:14:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 16:14:17 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <4y6TArTKErM-B-nDJCqh2482tTMiyCak05SI9wAqCfM=.3651c522-f00a-4e72-b757-18df5a0a6ae1@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
 <4y6TArTKErM-B-nDJCqh2482tTMiyCak05SI9wAqCfM=.3651c522-f00a-4e72-b757-18df5a0a6ae1@github.com>
Message-ID: <uqtMRxTKCzZXANG-dvJ8aY_7gw2bcf3UbMdBpbUgFio=.f2d1e7fe-3145-4ea6-b5e0-db8aa45ecb92@github.com>

On Mon, 6 Feb 2023 15:56:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 153:
> 
>> 151:         // Need to skip past the length of the name and extra fields
>> 152:         int nlen = buffer.getShort(off + NLEN);
>> 153:         int elen = buffer.getShort(off + NLEN);
> 
> Is this supposed to say `ELEN`?

Indeed, good catch! Must have lucked out on the comment be longer than the name :-)

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

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


From weijun at openjdk.org  Mon Feb  6 16:34:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 16:34:51 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers [v2]
In-Reply-To: <cG-Q65fvVK_47WUa2VSbqRjm-KgnMir5pzxlorL4nZM=.67c50d2e-cd25-425c-a8a4-29754fee3ede@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
 <mx9TDYefF1veBBCkyQot9uvL0yTJuoeLVilbIEyemEU=.fbdeb5c2-c9b7-4e6f-ae60-952b74d27e3b@github.com>
 <cG-Q65fvVK_47WUa2VSbqRjm-KgnMir5pzxlorL4nZM=.67c50d2e-cd25-425c-a8a4-29754fee3ede@github.com>
Message-ID: <r5N-GYQslDEkogUlyO1SLKN-CbNv84co4Wy1AYWEBXM=.f912ff2e-ff5e-4a80-9688-f40e86535a24@github.com>

On Mon, 6 Feb 2023 16:01:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   impl not necessary
>
> test/jdk/sun/security/x509/AlgorithmId/Uppercase.java line 30:
> 
>> 28:  * @summary AlgorithmId should keep lowercase characters from 3rd party providers
>> 29:  * @modules java.base/sun.security.x509
>> 30:  *          java.base/sun.security.util
> 
> Do you need this module?

`AlgorithmId.get(ALG).getOID().toString()` calls `sun.security.util.ObjectIdentifier::toString`.

Uppercase.java:46: error: ObjectIdentifier.toString() in package sun.security.util is not accessible
        Asserts.assertEQ(AlgorithmId.get(ALG).getOID().toString(), OID);
                                                      ^
  (package sun.security.util is declared in module java.base, which does not export it to the unnamed module)

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

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


From mullan at openjdk.org  Mon Feb  6 16:43:30 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Feb 2023 16:43:30 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers [v3]
In-Reply-To: <4rcoVh26HiNSjgehlgZkQyuqjFXSdjD8VNQRVV-Crgc=.55342639-d1b9-4ccc-9ab3-47dc3091fd5f@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
 <4rcoVh26HiNSjgehlgZkQyuqjFXSdjD8VNQRVV-Crgc=.55342639-d1b9-4ccc-9ab3-47dc3091fd5f@github.com>
Message-ID: <DlW4VWkRvc4ZvMwU-4JTVRJuXC8YgSzAXSwN7UBDzTI=.ce40293b-22be-4bb7-ae9e-dbaa492237c1@github.com>

On Mon, 6 Feb 2023 16:39:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Keep the "NAME -> 1.2.3.4" mapping unchanged but modify "1.2.3.4 -> NAME" to "1.2.3.4 -> Name".
>
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - useless import
>  - fix comments

Marked as reviewed by mullan (Reviewer).

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

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


From mullan at openjdk.org  Mon Feb  6 16:43:30 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Feb 2023 16:43:30 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers [v2]
In-Reply-To: <r5N-GYQslDEkogUlyO1SLKN-CbNv84co4Wy1AYWEBXM=.f912ff2e-ff5e-4a80-9688-f40e86535a24@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
 <mx9TDYefF1veBBCkyQot9uvL0yTJuoeLVilbIEyemEU=.fbdeb5c2-c9b7-4e6f-ae60-952b74d27e3b@github.com>
 <cG-Q65fvVK_47WUa2VSbqRjm-KgnMir5pzxlorL4nZM=.67c50d2e-cd25-425c-a8a4-29754fee3ede@github.com>
 <r5N-GYQslDEkogUlyO1SLKN-CbNv84co4Wy1AYWEBXM=.f912ff2e-ff5e-4a80-9688-f40e86535a24@github.com>
Message-ID: <J38nbcnpuyEyebhQ_0-cdIqnuwWWncB3ea7fbWJAHSc=.9a9e8eca-ab76-4cbe-9c5d-91f4563fc47b@github.com>

On Mon, 6 Feb 2023 16:32:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/x509/AlgorithmId/Uppercase.java line 30:
>> 
>>> 28:  * @summary AlgorithmId should keep lowercase characters from 3rd party providers
>>> 29:  * @modules java.base/sun.security.x509
>>> 30:  *          java.base/sun.security.util
>> 
>> Do you need this module?
>
> `AlgorithmId.get(ALG).getOID().toString()` calls `sun.security.util.ObjectIdentifier::toString`.
> 
> Uppercase.java:46: error: ObjectIdentifier.toString() in package sun.security.util is not accessible
>         Asserts.assertEQ(AlgorithmId.get(ALG).getOID().toString(), OID);
>                                                       ^
>   (package sun.security.util is declared in module java.base, which does not export it to the unnamed module)

ok

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

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


From weijun at openjdk.org  Mon Feb  6 16:43:29 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 16:43:29 GMT
Subject: RFR: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers [v3]
In-Reply-To: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
Message-ID: <4rcoVh26HiNSjgehlgZkQyuqjFXSdjD8VNQRVV-Crgc=.55342639-d1b9-4ccc-9ab3-47dc3091fd5f@github.com>

> Keep the "NAME -> 1.2.3.4" mapping unchanged but modify "1.2.3.4 -> NAME" to "1.2.3.4 -> Name".

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

 - useless import
 - fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12410/files
  - new: https://git.openjdk.org/jdk/pull/12410/files/61f3448c..42fb5d4a

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

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

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


From weijun at openjdk.org  Mon Feb  6 17:14:05 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 17:14:05 GMT
Subject: Integrated: 8301788: AlgorithmId should keep lowercase characters from
 3rd party providers
In-Reply-To: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
References: <nDy05el1KfnbtPBXIEPylJ8tIF1Q7ocnouQXP8ofUCA=.163f23da-7e3e-45ea-82c1-742292a19fe0@github.com>
Message-ID: <qNL-2pIxZHj3oBGS-OT_W3bB_vbTX1dlm88ab9PBFsY=.f6a5fd9b-9ac1-4ccb-bf22-27e116f5d4fa@github.com>

On Fri, 3 Feb 2023 15:32:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Keep the "NAME -> 1.2.3.4" mapping unchanged but modify "1.2.3.4 -> NAME" to "1.2.3.4 -> Name".

This pull request has now been integrated.

Changeset: b5697420
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b56974209b1a9c2c702e1c39708cdfbda37d56fc
Stats:     70 lines in 2 files changed: 59 ins; 0 del; 11 mod

8301788: AlgorithmId should keep lowercase characters from 3rd party providers

Reviewed-by: mullan

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

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


From duke at openjdk.org  Mon Feb  6 17:19:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 17:19:05 GMT
Subject: Integrated: 8300259: Add test coverage for processing of pending block
 files in signed JARs
In-Reply-To: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
Message-ID: <BGmZCs657zYJ2ZPpoD6SHVvX27pd51FEapN6osIMl4c=.e0ab71b0-4ab3-4b5e-bc3b-fdd298ffdee6@github.com>

On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR adds test coverage for pending block files in signed JAR files
> 
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
> 
> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
> 
> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.

This pull request has now been integrated.

Changeset: c129ce46
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c129ce4660e6c9b5365c8bf89fb916e2a7c28e98
Stats:     173 lines in 1 file changed: 173 ins; 0 del; 0 mod

8300259: Add test coverage for processing of pending block files in signed JARs

Reviewed-by: weijun

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

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


From mpowers at openjdk.org  Mon Feb  6 17:54:15 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 6 Feb 2023 17:54:15 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v4]
In-Reply-To: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
Message-ID: <auYuG6rmkImGxl7xvfWULKpId4ncljpe9AfbZWgwJ8A=.c5515f34-f07c-4dde-a48c-0aa4ddde397f@github.com>

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

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

  added comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12348/files
  - new: https://git.openjdk.org/jdk/pull/12348/files/bcf95a20..d35bc54f

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

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

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


From mullan at openjdk.org  Mon Feb  6 19:11:51 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Feb 2023 19:11:51 GMT
Subject: RFR: 8245654: Add Certigna Root CA
In-Reply-To: <QD8dU8-pLMiAvsdr-9k8FDXgqm0t-hhngz09Bb16mPU=.69c13db6-3ce6-4ea7-83ae-6eeaeb2253c9@github.com>
References: <QD8dU8-pLMiAvsdr-9k8FDXgqm0t-hhngz09Bb16mPU=.69c13db6-3ce6-4ea7-83ae-6eeaeb2253c9@github.com>
Message-ID: <toucBq9d5i1ZBLopFgA3SY_Ve3T2pCUHJZOqWzAl69M=.ed700cbc-0943-4a86-9c56-8113d96dc759@github.com>

On Wed, 1 Feb 2023 21:28:25 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix adds Certigna root CA to cacerts trust store.

Marked as reviewed by mullan (Reviewer).

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

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


From aivanov at openjdk.org  Mon Feb  6 19:59:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Feb 2023 19:59:53 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v4]
In-Reply-To: <mzI7SEq3zv3egItZTlRd66dZ0tyhRKB0_1ngBxgiVWg=.4c93a2ea-7ba3-469a-8df9-f46603e58d23@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <mzI7SEq3zv3egItZTlRd66dZ0tyhRKB0_1ngBxgiVWg=.4c93a2ea-7ba3-469a-8df9-f46603e58d23@github.com>
Message-ID: <wSXV07-b_hqLtZVIfmIVUHFr9qFEneYwfL9ik7L-26Q=.0d3fc71a-b8c8-411a-8b98-e0bd6de199fb@github.com>

On Mon, 6 Feb 2023 03:37:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sspi.cpp

Marked as reviewed by aivanov (Reviewer).

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

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


From jwaters at openjdk.org  Tue Feb  7 01:17:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 01:17:18 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

 - D3DVertexCacher.cpp
 - awt_List.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/24becec8..e6d54f21

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

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

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


From peter.firmstone at zeus.net.au  Tue Feb  7 02:53:22 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 7 Feb 2023 12:53:22 +1000
Subject: Implementing an Authorization framework on Java.
Message-ID: <bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au>

Hello OpenJDK folk,

SecurityManager, AccessController and AccessControlContext will be 
removed in a future version of Java.

Just briefly: Our software is heavily dependant on Java's Authorization 
framework, we use ProtectionDomain's to represent remote services for 
authorization decisions.? We are working out how to implement a new 
authorization framework after SecurityManager's removal.

Many libraries call AccessController#doPrivileged methods, when these 
methods are removed, we're going to have a big problem with viral 
permissions. ? Restricted authorization will become meaningless if it 
has to be granted to all domains on a call stack.

https://github.com/opensearch-project/OpenSearch/issues/1687

Retaining methods in the platform that developers can instrument will 
provide a common frame of reference for authorization decisions, that's 
runtime backward non-breaking, without burdening OpenJDK with maintenance.

I'm requesting retaining the DomainController interface, 
AccessController, AccessControlContext and Subject methods as no-op's 
for instrumentation???? Please leave them deprecated as no-op's, but not 
"deprecated for removal".

https://github.com/pfirmstone/HighPerformanceSecurity

Some thoughts:

 1. Ability to disable finalizers in Java 18 onwards is important to
    prevent finalizer attacks when instrumenting constructors to throw a
    RuntimeException.
 2. Guard#check methods can be no-op's for instrumentation.?? If I can
    replace all instances of SecurityManager#checkPermission in OpenJDK
    with Guard#check, I can contribute the patches, this will assist
    greatly in the transition process of retaining existing hooks, while
    developing replacements.
 3. Reduce the size of the Java Platform's trusted computing base by
    giving all system ProtectionDomain's a CodeSource with a non-null
    meaningful URL.?? Unfortunately Java Serialization is in the base
    module, so we cannot authorize it's use with a permission check, as
    the base module needs AllPermission, it has to be managed with
    serial filters
    (https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
    - perhaps someone will write a serialfilter generation tool that
    works similarly to our POLP policy generation tool?). Privileges
    cannot be elevated by an authenticated Subject, when all domains on
    the call stack are already privileged.? If Serialization was in a
    different ProtectionDomain, then we could prevent de-serialization
    for unauthenticated Subject's. Perhaps OpenJDK might consider moving
    Serialization into a different module in future before it's eventual
    removal?
 4. Instrument all data parsing methods with guard checks, eg XML.??
    This allows authorization decisions to parse remote data based on
    the Principal's of the remotely authenticated Subject, to prevent
    injection attacks.
 5. We already have principle of least privilege policy generation tools
    and efficient policy checking tools for authorization in place.??
    These allow for simple policy file generation, auditing, editing and
    deployment.

-- 
Regards,
  
Peter Firmstone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230207/5982e87a/attachment.htm>

From redestad at openjdk.org  Tue Feb  7 13:14:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 13:14:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v3]
In-Reply-To: <kocafii57-tSO8NfHg_5ywyqC_5DMPWa07dbqdG7884=.1e6e34d0-1e26-4ea7-aa52-466908d45d16@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <kocafii57-tSO8NfHg_5ywyqC_5DMPWa07dbqdG7884=.1e6e34d0-1e26-4ea7-aa52-466908d45d16@github.com>
Message-ID: <tN-FR3uI-_c3ZiWNk2iOyYoXbj958BblH1WWVs4xLNA=.755a09be-65c2-4e74-892c-e8e4ab256bc4@github.com>

On Mon, 6 Feb 2023 16:14:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".

Some GHA testing seem to have failed due to infrastructure issues - try merging in master to trigger testing again.

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

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


From duke at openjdk.org  Tue Feb  7 13:23:26 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 7 Feb 2023 13:23:26 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos 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 20 additional commits since the last revision:

 - Merge branch 'master' into getentrypos-prefixmatch
 - Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
 - Spelling fix in test data for non-ascii latin1 string
 - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
 - Rename test to InvalidBytesInEntryNameOrComment
 - Adjust whitespace
 - Some minor improvements to code comments
 - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
 - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
 - ByteBuffers for reading ZIP files must be little-endian
 - ... and 10 more: https://git.openjdk.org/jdk/compare/23f44474...06047377

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/2c5e7c2c..06047377

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

  Stats: 22651 lines in 906 files changed: 9116 ins; 4377 del; 9158 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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


From mullan at openjdk.org  Tue Feb  7 13:44:45 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Feb 2023 13:44:45 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v4]
In-Reply-To: <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
 <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
 <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>
 <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>
Message-ID: <ARMkPNX6RIsVtDCqMBc7cKjpPuKl1Ylx3u-dycZx3rg=.6813d7a9-40b7-4d90-a9e0-a4059cc9d875@github.com>

On Thu, 2 Feb 2023 22:24:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I think you mean line 126? :
>> 
>> `                tempArray = new byte[n];  `
>
> You are correct. How did I come up with 220?

@mcpowers can you also add a comment to the test, maybe right before line 95, with something like I said above: 

"Random is producing the same sequence of bytes for each thread, and thus each MessageDigest should be equal. When the memory is shared, they inevitably overwrite each other's tempArray and you get different results."

@mcpowers can you also add a comment to the test, maybe right before line 95, with something like I said above: 

"Random is producing the same sequence of bytes for each thread, and thus each MessageDigest should be equal. When the memory is shared, they inevitably overwrite each other's tempArray and you get different results."

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

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


From aivanov at openjdk.org  Tue Feb  7 15:34:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 15:34:17 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
Message-ID: <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>

On Tue, 7 Feb 2023 01:17:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - D3DVertexCacher.cpp
>  - awt_List.cpp

src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 183:

> 181: //      SetWindowPos(hList, 0, 0, 0, w, h, flags);
> 182: //  }
> 183: //

Maybe it's time to remove this commented out code? It's been commented out since 2007 when the code moved to Mercurial.

If you decide to remove it, please submit a new issue to communicate the intention clearly.

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

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


From aivanov at openjdk.org  Tue Feb  7 15:34:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 15:34:20 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <SI9ksB_ugdnmIP9OF3CPWqM_HDjZcHyLlwmsg8L6oiY=.b3114edb-bbfe-48f0-a086-39f79f713f6b@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
 <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
 <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>
 <SI9ksB_ugdnmIP9OF3CPWqM_HDjZcHyLlwmsg8L6oiY=.b3114edb-bbfe-48f0-a086-39f79f713f6b@github.com>
Message-ID: <DEFA3KIoARIe_UKINva75oSfK82gywHUx7-ZaFfySuk=.0e32de96-44c3-4e4b-b377-6d412a6b2855@github.com>

On Mon, 6 Feb 2023 03:31:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I don't know. I'm quite sure I was using the full command in `cmd.exe` after calling some `vcvars64.bat`. I added the `` character because it's a little long to be recorded here. I don't really care which separator is used. You can remove the `` character. We don't need to spend too much time on this.
>
> Honestly, with all of this confusion around the command line, I think I'd rather just avoid the issue entirely by turning this into a multiline comment so the backslash doesn't cause compiler warnings

I don't know what the error message you get, but `^` definitely works for me as continuation line marker in `cmd.exe`.


C:\dev\jdk-dev>cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp ^
More?    -link -dll -out:sspi_bridge.dll
'cl' is not recognized as an internal or external command,
operable program or batch file.


This `More?` prompt identifies the continuation line.

Anyway, we decided to leave it as is but convert to multi-line comment, which is fine with me.

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

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


From mpowers at openjdk.org  Tue Feb  7 15:58:31 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Feb 2023 15:58:31 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v5]
In-Reply-To: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
Message-ID: <5LttGdL1RXjV2FZAlsAX19m9G5QWlv3TAG2NRs6Mlks=.a33754e6-1a9b-4e6e-94b6-525f357eae91@github.com>

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

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

  Sean's test comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12348/files
  - new: https://git.openjdk.org/jdk/pull/12348/files/d35bc54f..c94838b7

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

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

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


From mpowers at openjdk.org  Tue Feb  7 15:58:33 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Feb 2023 15:58:33 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v5]
In-Reply-To: <ARMkPNX6RIsVtDCqMBc7cKjpPuKl1Ylx3u-dycZx3rg=.6813d7a9-40b7-4d90-a9e0-a4059cc9d875@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <fqP1RTWamxgrnLV0VS2D39xrj7P26nYmuL2MDgY7lfw=.2d96371a-1180-4eca-99b9-dd061a714dc1@github.com>
 <LbTRH9V9WSUcpgjj9mGYHbCwavzv2M34PyOtNRbyWQA=.be1448e3-5bc1-40f6-b4af-6b8ebc2a3143@github.com>
 <wC52Znh5lYClvM1TP2gWq-_-ba-NGo3SxPIUN8dxqic=.e3e76bf1-9de9-4aa2-9a48-2e149053c596@github.com>
 <Ely1bNaXdy2-3jZcZeIFEoNwgRwtmLNDo_tPyczElRs=.a0f88a1e-68e0-4b81-893b-16854b01d1d2@github.com>
 <ARMkPNX6RIsVtDCqMBc7cKjpPuKl1Ylx3u-dycZx3rg=.6813d7a9-40b7-4d90-a9e0-a4059cc9d875@github.com>
Message-ID: <r3P4wkbOueUDL8JiU7I5qYUhfRv6PlL_a3vLuH6PBBw=.b37532d9-dd47-4f58-a200-63232d606fba@github.com>

On Tue, 7 Feb 2023 13:41:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> You are correct. How did I come up with 220?
>
> @mcpowers can you also add a comment to the test, maybe right before line 95, with something like I said above: 
> 
> "Random is producing the same sequence of bytes for each thread, and thus each MessageDigest should be equal. When the memory is shared, they inevitably overwrite each other's tempArray and you get different results."

Good idea. It's not obvious what's going on.

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

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


From jwaters at openjdk.org  Tue Feb  7 16:00:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 16:00:09 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
Message-ID: <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>

On Tue, 7 Feb 2023 15:14:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - D3DVertexCacher.cpp
>>  - awt_List.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 183:
> 
>> 181: //      SetWindowPos(hList, 0, 0, 0, w, h, flags);
>> 182: //  }
>> 183: //
> 
> Maybe it's time to remove this commented out code? It's been commented out since 2007 when the code moved to Mercurial.
> 
> If you decide to remove it, please submit a new issue to communicate the intention clearly.

Perhaps, but I'll leave that to the discretion of the client libs group. Are the new changes fine with you though?

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

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


From aivanov at openjdk.org  Tue Feb  7 16:14:56 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 16:14:56 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
Message-ID: <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>

On Tue, 7 Feb 2023 15:57:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 183:
>> 
>>> 181: //      SetWindowPos(hList, 0, 0, 0, w, h, flags);
>>> 182: //  }
>>> 183: //
>> 
>> Maybe it's time to remove this commented out code? It's been commented out since 2007 when the code moved to Mercurial.
>> 
>> If you decide to remove it, please submit a new issue to communicate the intention clearly.
>
> Perhaps, but I'll leave that to the discretion of the client libs group. Are the new changes fine with you though?

I'd rather remove the offending commented out code than change its formatting.

Could you submit a bug, please, and assign it to me?

There's a closed test associated with [JDK-4046446](https://bugs.openjdk.org/browse/JDK-4046446), it can be open-sourced. Then it'll be safe to remove the commented out code.

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

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


From mullan at openjdk.org  Tue Feb  7 16:14:55 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Feb 2023 16:14:55 GMT
Subject: RFR: JDK-8300416 java.security.MessageDigestSpi clone can result
 in thread-unsafe clones [v5]
In-Reply-To: <5LttGdL1RXjV2FZAlsAX19m9G5QWlv3TAG2NRs6Mlks=.a33754e6-1a9b-4e6e-94b6-525f357eae91@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
 <5LttGdL1RXjV2FZAlsAX19m9G5QWlv3TAG2NRs6Mlks=.a33754e6-1a9b-4e6e-94b6-525f357eae91@github.com>
Message-ID: <7b1s3ys_JtJ0YMHvT9DaPfVH8GCEw_DA7m0jGqM3uig=.0e162432-44ff-4569-b6a9-5298f2afc80f@github.com>

On Tue, 7 Feb 2023 15:58:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8300416
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean's test comment

Marked as reviewed by mullan (Reviewer).

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

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


From jwaters at openjdk.org  Tue Feb  7 17:11:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 17:11:08 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
Message-ID: <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>

On Tue, 7 Feb 2023 16:11:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Perhaps, but I'll leave that to the discretion of the client libs group. Are the new changes fine with you though?
>
> I'd rather remove the offending commented out code than change its formatting.
> 
> Could you submit a bug, please, and assign it to me?
> 
> There's a closed test associated with [JDK-4046446](https://bugs.openjdk.org/browse/JDK-4046446), it can be open-sourced. Then it'll be safe to remove the commented out code.

Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994

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

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


From mpowers at openjdk.org  Tue Feb  7 17:43:36 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Feb 2023 17:43:36 GMT
Subject: Integrated: JDK-8300416 java.security.MessageDigestSpi clone can
 result in thread-unsafe clones
In-Reply-To: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
References: <txPSKFV5QWYWr4swYZvCrPAzmo9MNtlFyqJ5U_Xufg0=.0a9be842-12fa-4992-962e-cb6e99227190@github.com>
Message-ID: <XjgCRSgGoQcr5ocK0346EDKPT1lNkWjxoo0sew2arfk=.a8b6d048-086f-454a-a8ed-061fb5788879@github.com>

On Tue, 31 Jan 2023 16:54:03 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 2e2e71e1
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e2e71e1fa326b8d30f018a3e0726bbcd6d24019
Stats:     64 lines in 2 files changed: 58 ins; 0 del; 6 mod

8300416: java.security.MessageDigestSpi clone can result in thread-unsafe clones

Reviewed-by: mullan

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

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


From aivanov at openjdk.org  Tue Feb  7 19:22:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 19:22:32 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
 <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
Message-ID: <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>

On Tue, 7 Feb 2023 17:08:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994

Thank you, @TheShermanTanker.

Do you still want to keep the changes?
If it's not too critical, I would rather prefer you revert the changes to `awt_List.cpp`.

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

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


From mullan at openjdk.org  Tue Feb  7 20:47:08 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Feb 2023 20:47:08 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode [v2]
In-Reply-To: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
Message-ID: <jIo2KNXaHPt9wUDg20pAn--WTR0EpCCmMRCqAwhfaeM=.eb20bc81-6932-471f-bce7-55cce0c738ad@github.com>

> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

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

  Document system property in DOMValidateContext API.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12365/files
  - new: https://git.openjdk.org/jdk/pull/12365/files/254572cd..bc77ee05

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

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

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


From mullan at openjdk.org  Tue Feb  7 21:01:19 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Feb 2023 21:01:19 GMT
Subject: RFR: 8301260: Add system property to toggle XML Signature secure
 validation mode [v3]
In-Reply-To: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
Message-ID: <pKj7P76IIW7I799EJXgDer0MQUM7hNqv0ELPJONlpDs=.d605f154-cae6-4639-b59f-da6f62742b3d@github.com>

> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

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

  Remove trailing whitespace.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12365/files
  - new: https://git.openjdk.org/jdk/pull/12365/files/bc77ee05..949f671a

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

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

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


From lance.andersen at oracle.com  Tue Feb  7 21:38:49 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Feb 2023 21:38:49 +0000
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
Message-ID: <BFCB87DC-E42F-49D5-BC05-CDC9C99B0F5B@oracle.com>

This is still on my list to review will get to it in the next day or so

On Feb 7, 2023, at 8:23 AM, Eirik Bjorsnos <duke at openjdk.org<mailto:duke at openjdk.org>> wrote:

After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.

This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly.

ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes.

Additionally, this PR suggest to make the following updates to getEntryPos:

- The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
- A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
- The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)

(My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)

I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):

Baseline:

Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op



PR:


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op


To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):


Percentile Baseline Patch
50 %          23155 21149
75 %          23598 21454
90 %          23989 21691
95 %          24238 21973
99 %          25270 22446
STDEV           792   549
Count           500   500

Eirik Bjorsnos 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 20 additional commits since the last revision:

- Merge branch 'master' into getentrypos-prefixmatch
- Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
- Spelling fix in test data for non-ascii latin1 string
- Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
- Rename test to InvalidBytesInEntryNameOrComment
- Adjust whitespace
- Some minor improvements to code comments
- Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
- Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
- ByteBuffers for reading ZIP files must be little-endian
- ... and 10 more: https://git.openjdk.org/jdk/compare/23f44474...06047377

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

Changes:
 - all: https://git.openjdk.org/jdk/pull/12290/files
 - new: https://git.openjdk.org/jdk/pull/12290/files/2c5e7c2c..06047377

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

 Stats: 22651 lines in 906 files changed: 9116 ins; 4377 del; 9158 mod
 Patch: https://git.openjdk.org/jdk/pull/12290.diff
 Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230207/e873a076/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230207/e873a076/oracle_sig_logo.gif>

From mchung at openjdk.org  Tue Feb  7 22:32:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 7 Feb 2023 22:32:32 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596
Message-ID: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>

A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

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

Commit messages:
 - JDK-8301462: Convert Permission files to use lambda after JDK-8076596

Changes: https://git.openjdk.org/jdk/pull/12463/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12463&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301462
  Stats: 75 lines in 4 files changed: 3 ins; 30 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/12463.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12463/head:pull/12463

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


From redestad at openjdk.org  Tue Feb  7 22:54:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 22:54:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
Message-ID: <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>

On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into getentrypos-prefixmatch
>  - Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
>  - Spelling fix in test data for non-ascii latin1 string
>  - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
>  - Rename test to InvalidBytesInEntryNameOrComment
>  - Adjust whitespace
>  - Some minor improvements to code comments
>  - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
>  - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
>  - ByteBuffers for reading ZIP files must be little-endian
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/184e3101...06047377

Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:

java.lang.AssertionError: expected [837891402] but found [837891401]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestZipFileEncodings.checkEqual(TestZipFileEncodings.java:153)
	at TestZipFileEncodings.doTest0(TestZipFileEncodings.java:190)
	at TestZipFileEncodings.doTest(TestZipFileEncodings.java:162)
	at TestZipFileEncodings.test(TestZipFileEncodings.java:146)
	at TestZipFileEncodings.testUnicodeManyEntries(TestZipFileEncodings.java:116)```

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

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


From fferrari at redhat.com  Wed Feb  8 00:23:39 2023
From: fferrari at redhat.com (Francisco Ferrari Bihurriet)
Date: Tue, 7 Feb 2023 21:23:39 -0300
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <986e77e8-e77b-d548-c76b-81022093865e@redhat.com>

Hi, here is a more plaintext-friendly version of the pull request
Markdown body.

NOTE: I did manual wrapping to get a reasonably good representation in
the archived version of this email [*], sorry if you are reading this in
a <72 characters screen. On the other hand, not wrapping at all would
lead to very long lines in wider screens.

[*]: https://mail.openjdk.org/pipermail/security-dev/2023-February/034438.html

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

We would like to propose an implementation for the JDK-8301553: Support
Password-Based Cryptography in SunPKCS11 [1] enhancement requirement.

In addition to pursuing the requirement goals and guidelines of
JDK-8301553 [1], we want to share the following implementation notes
(grouped per altered file):

 ? src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java (modified)

   ? This file contains the SunJCE implementation for the PKCS #12
     General Method for Password Integrity [2] algorithms. It has been
     modified with the intent of consolidating all parameter checks in a
     common file
     (src/java.base/share/classes/sun/security/util/PBEUtil.java), that
     can be used both by SunJCE and SunPKCS11. This change does not only
     serve the purpose of avoiding duplicated code but also ensuring
     alignment and compatibility between different implementations of
     the same algorithms. No changes have been made to parameter checks
     themselves.

   ? The new PBEUtil::getPBAKeySpec method introduced for parameters
     checking takes both a Key and a AlgorithmParameterSpec instance
     (same as the HmacPKCS12PBECore::engineInit method), and returns a
     PBEKeySpec instance which consolidates all the data later required
     to proceed with the computation (password, salt and iteration
     count).

 ? src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java (modified)

   ? This file contains the SunJCE implementation for the PKCS #5
     Password-Based Encryption Scheme [3] algorithms, which use PBKD2
     algorithms underneath for key derivation. In the same spirit than
     for the HmacPKCS12PBECore case, we decided to consolidate common
     code for parameters validation and default values in a single file
     (src/java.base/share/classes/sun/security/util/PBEUtil.java), that
     can serve both SunJCE and SunPKCS11 and ensure compatibility.
     However, instead of a single static method at the implementation
     level (see PBEUtil::getPBAKeySpec), we create an instance of an
     auxiliary class and invoke an instance method
     (PBEUtil.PBES2Params::getPBEKeySpec). The reason is to persist
     parameters data that has to be consistent between calls to
     PBES2Core::engineInit (in its multiple overloads) and
     PBES2Core::engineGetParameters, given a single PBES2Core instance.
     In particular, a call to any of these methods can potentially
     modify the state in an observable way by means of generating a
     random IV and a salt. Previous to the proposed patch, this data was
     persisted in the PBES2Core::ivSpec and PBES2Core::salt instance
     fields. For compatibility purposes, we decided to preserve SunJCE's
     current behavior.

 ? src/java.base/share/classes/sun/security/util/PBEUtil.java (new file)

   ? This utility file contains the PBE parameters checking routines and
     default values that are used by both SunJCE and SunPKCS11. These
     routines are invoked from HmacPKCS12PBECore (SunJCE), PBES2Core
     (SunJCE), P11PBECipher (SunPKCS11) and P11Mac (SunPKCS11). As
     previously noted, the goals are to avoid duplicate code and to
     improve compatibility between different security providers that
     implement PBE algorithms.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java (modified)

   ? An utility function to determine if the token is NSS is now called.
     This function is in a common utility class (P11Util) and invoked
     from P11Key and P11SecretKeyFactory too.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java (modified)

   ? A new type of P11 key is introduced: P11PBEKey. This new type
     represents a secret key that exists inside the token. Thus, this
     type inherits from P11SecretKey. At the same time, this type holds
     data used for key derivation. Thus, this type implements the
     javax.crypto.interfaces.PBEKey interface. In addition to the
     conceptual modeling, there are practical advantages of identifying
     a key by this new P11PBEKey type and holding the data used for
     derivation: 1) if the key is used in another token (different than
     the one where it was originally derived), a new derivation must
     take place; 2) if the key is passed to a non-SunPKCS11 security
     provider, its key translation method might use derivation data to
     derive again; and, 3) it's possible to return the PBEKeySpec for
     the key (see for example P11SecretKeyFactory::engineGetKeySpec).

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java (modified)

   ? We decided to integrate PBE algorithms to the existing P11Mac
     service because the changes required have a low impact on the
     existing code. When the P11Mac instance is created, we use the
     algorithm to get PBE key information (if available). Only PBE
     algorithms have this type of information. In the P11Mac::engineInit
     method, we now need to handle the PBE service case. In such case,
     if the key is a P11Key, we check parameters and that the key
     implements javax.crypto.interfaces.PBEKey by calling
     PBEUtil::checkKeyParams. In other words, the key has to be a
     P11PBEKey and the parameters used for its derivation must match the
     ones passed in the invocation to P11Mac::engineInit. If the key is
     not a P11Key, a PBE derivation is needed. As for the SunJCE case,
     we go through parameters processing in PBEUtil::getPBAKeySpec.

   ? There are two cases in which we need to call
     P11SecretKeyFactory::convertKey. One is when the service is not
     PBE, as we did before the proposed change. In the PBE case, we must
     call this function because it might be possible that, if the key
     token is not the same than the service's token, a new key
     derivation is required.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java (new file)

   ? Contrary to the P11Mac case, we decided to separate PBE Cipher from
     non-PBE Cipher in a different class. There is some additional
     complexity or gap between the two that we prefer to keep simple. A
     PBE Cipher uses a non-PBE Cipher service underneath and forwards
     most of its operations, but adds wrapping code to potentially
     derive keys during initialization (see P11PBECipher::engineInit).
     The code associated to key derivation and parameters consistency
     checking is analogous to the one described for P11Mac.

   ? P11PBECipher has a P11PBECipher::engineGetParameters method which
     calls PBEUtil.PBES2Params::getAlgorithmParameters and can
     potentially initialize an IV and a salt with a random value, as
     explained in the comments for PBES2Core.

   ? A P11PBECipher service accepts PBE keys only.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java (modified)

   ? The first significant change to this class that we want to discuss
     is the introduction of the KeyInfo class and the refactoring of the
     previous keyTypes map. Previous to the proposed change, the key
     information that we needed to retain for key creation at the PKCS
     #?11 level was simple: key algorithm -> PKCS #?11 native key type.
     With PBE, we must consider not only the algorithm name and key type
     but also (depending on the case) the mechanism that has to be used
     for derivation, the underlying derivation function and the key
     length. As an example, to derive a key for the
     PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this
     algorithm maps to a PKCS #?11 derivation mechanism value of
     CKM_PKCS5_PBKD2, a derivation function value of
     CKP_PKCS5_PBKD2_HMAC_SHA512, a derived key type of CKK_AES ?so it
     can be used in an AES Cipher service? and a key length of 256 bits.
     A new hierarchy of classes to represent these different entries on
     the mapping structure has been introduced (see KeyInfo, PBEKeyInfo,
     AESPBEKeyInfo, PBKDF2KeyInfo and P12MacPBEKeyInfo). The methods to
     add or find entries in the new map have been adjusted. The previous
     pseudo key types strategy (HMAC, SSLMAC), that allows any key type
     to be used in a HMAC service, has not been modified.

   ? The second significant change to this class was in the
     P11SecretKeyFactory::convertKey method. When checking if a key can
     be used in a service ?notice here that the service can be any of
     SecretKeyFactory, Cipher or Mac?, the following rules apply:

     ? If the key algorithm matches the service algorithm, the use is
       allowed

     ? If the key algorithm does not match the service algorithm and the
       service is not one of the pseudo types, further checks are
       needed. The KeyInfo structure for the key and service algorithms
       are obtained from the map and the KeyInfo::checkUse method is
       invoked. The following principles apply to make a decision: 1)
       PBE services require a javax.crypto.interfaces.PBEKey of the same
       algorithm ?we cannot use an AES key, for example, in a
       PBEWithHmacSHA512AndAES_256 Cipher service?, 2) PBKD2 keys can be
       used on any service ?there is no information about the key
       purpose to make a decision? and 3) keys can be used in a service
       if their underlying type match ?as an example, a
       PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of
       CKK_AES and can be used in an AES Cipher service?.

   ? The third significant change to this class was the addition of the
     P11SecretKeyFactory::derivePBEKey function. This function does
     different checks and creates the PKCS #?11 structures to make a
     native call to C_GenerateKey to derive the key. They key returned,
     in case of success, is of P11PBEKey type. It is worth mentioning
     that this function is the only path to invoke a native key
     derivation. It's used not only by the PBE P11SecretKeyFactory
     service but also by PBE Cipher and PBE Mac services when they need
     to derive a key.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java (modified)

   ? Added some utility functions. One of them is
     P11Util::encodePassword which serves the purpose of encoding a
     password in a way that can go through native library truncation
     (OpenJDK) and reach the PKCS #?11 API in the expected encoding.
     Password encoding must be UTF-8 for PKCS #?5 v2.1 derivation and
     BMPString (UTF-16 big endian) for PKCS #?12 v1.1 General Method for
     Password Integrity derivation. By avoiding a modification to the
     existing native jCharArrayToCKUTF8CharArray function (p11_util.c),
     we reduce the risk of breaking existing code.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java (modified)

   ? The new PBE algorithms are registered for SunPKCS11 services. It's
     worth noting that there is an additional (and optional)
     requiredMechs array to specify a list of native mechanisms that
     must be available in the token for the service to be enabled. To
     explain the need for this structure, we will focus on the
     HmacPBESHA1 Mac service example. On the one hand, we require the
     CKM_SHA_1_HMAC mechanism to be available in the token because this
     is, ultimately, a SHA-1 HMAC operation. However, the
     CKM_PBA_SHA1_WITH_SHA1_HMAC mechanism must be available as well for
     the preceding PBE key derivation. In the PBKDF2 case, we leverage
     on this structure to require a mechanism associated to the
     derivation function. The assumption is that, for example, if the
     CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC mechanisms are available, a
     PBKDF2 derivation using HMAC SHA-1 underneath will be available. In
     this case, the derivation function is represented by the
     CKP_PKCS5_PBKD2_HMAC_SHA1 constant.

   ? As mentioned in JDK-8301553 [1], for some algorithms there isn't a
     PKCS #?11 constant and we use the NSS vendor-specific one. This
     code can be easily be updated in the future if a constant is
     introduced to the standard. We don't know if that will ever happen
     as the newer PKCS #?5 derivation for Mac (PBMAC1) might be
     considered in the future as a PKCS #?12 integrity scheme
     replacement.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java (modified)

   ? Minor comment fix. This mistake was probably the result of using
     the CK_PKCS5_PBKD2_PARAMS file as a template and forgetting to
     update the comment.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java (modified)

   ? New constructors for the CK_PBE_PARAMS, CK_PKCS5_PBKD2_PARAMS and
     CK_PKCS5_PBKD2_PARAMS2 structures that can be used along with a
     CK_MECHANISM.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java (modified)

   ? Some minor adjustments to comments and a constructor to make this
     class usable with the PKCS #?12 General Method for Password
     Integrity derivation.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java (modified)

   ? Same than for CK_PBE_PARAMS. It is worth noting that this structure
     is the one used in PKCS #?11 revisions previous to v2.40 Errata 01.
     Given that NSS has decided to keep using it ?even when it's not
     compliant with the latest revisions of the v2.40 and v3.0
     standards?, we make an exception for it.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java (new file)

   ? The new structure for passing PBE parameters to the PKCS #?11 token
     in the PKCS #?5 v2.1 derivation scheme.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java (modified)

   ? Same comment than for CK_ECDH1_DERIVE_PARAMS.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java (modified)

   ? More visibility of major and minor versions of the PKCS #?11
     standard implemented by a token is needed to decide between the
     CK_PKCS5_PBKD2_PARAMS and CK_PKCS5_PBKD2_PARAMS2 structures.

 ? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java (modified)

   ? New constants added.

 ? src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c (modified)

   ? Adjustments made to work with the structures to pass parameters to
     the token for PBE derivation. It's worth noting that native PBKD2
     parameter structures have a tag before the data so we can execute
     the correct logic to free up resources, once the operation is
     completed. This is how we differentiate a CK_PKCS5_PBKD2_PARAMS
     from a CK_PKCS5_PBKD2_PARAMS2 one.

 ? src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c (modified)

   ? Adjustments to work with the new PBE parameter structures.

   ? A bug affecting non-null Java arrays whose length is 0 and need to
     be converted to native PKCS #?11 arrays has been fixed. For these
     arrays, it was possible that some platforms return NULL as a result
     of calling memory allocation functions when the size was 0 and an
     OutOfMemory exception was incorrectly thrown.

 ? src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h (modified)

   ? Native constants and structures added.

Test files

 ? test/jdk/sun/security/pkcs11/Cipher/PBECipher.java (new file)

   ? Tests the PBE Cipher service in SunPKCS11, cross-comparing results
     against SunJCE (if available) and static data.

   ? The PBE Cipher service is tested with different types of keys:
     derived from data in a PBEParameterSpec, derived with a SunPKCS11
     SecretKeyFactory service, derived from data in AlgorithmParameters
     and derived from data contained in a javax.crypto.interfaces.PBEKey
     instance.

 ? test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java (new file)

   ? Tests that, for several PBE algorithms, PKCS #?12 key stores (with
     Privacy and Integrity) written using SunPKCS11 underneath can be
     read using SunJCE underneath.

 ? test/jdk/sun/security/pkcs11/Mac/MacSameTest.java (modified)

   ? This test was not expecting PBE services to be available in the
     SunPKCS11 security provider, and needs to invoke a new function
     (PKCS11Test::generateKey) to generate a random key (password).

 ? test/jdk/sun/security/pkcs11/Mac/PBAMac.java (new file)

   ? Similar to PBECipher but these are the possible types of keys:
     derived from data in a PBEParameterSpec, derived with a SunPKCS11
     SecretKeyFactory service and derived from data contained in a
     javax.crypto.interfaces.PBEKey instance.

 ? test/jdk/sun/security/pkcs11/Mac/ReinitMac.java (modified)

   ? Same issue fixed than for MacSameTest.

 ? test/jdk/sun/security/pkcs11/PKCS11Test.java (modified)

   ? Functions to generate random keys or passwords for PBE and non-PBE
     algorithms.

 ? test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java (new
   file)

   ? In addition to testing derived keys for different algorithms
     against SunJCE and static assertion data, this test asserts: 1)
     different types of valid and invalid key conversions, and 2)
     invalid or inconsistent parameters passed for key derivation. Keys
     are derived with data contained in a PBEKeySpec or in a
     javax.crypto.interfaces.PBEKey instance.

   ? Both an empty and a unicode password, containing a non-ASCII
     character, are used during this test.

Testing

 ? No regressions have been observed in the jdk/sun/security/pkcs11
   category (SunPKCS11).

 ? No regressions have been observed in the jdk/com/sun/crypto/provider
   category (SunJCE).

 ? No regressions have been observed in the JDK Tier-1 category.

 ? Anecdotally, a partial version of the proposed patch containing
   Cipher and Mac changes is shipped in Red Hat Enterprise Linux builds
   of OpenJDK 17 since November 2022, without any known issues at this
   moment.

This contribution is co-authored between fferrari at redhat.com and
mbalao at redhat.com. We are both under the cover of the OCA agreement per
our employer (Red Hat). We look forward to sharing this new feature for
the benefit of the broad OpenJDK community and users.


[1] https://bugs.openjdk.org/browse/JDK-8301553
[2] https://datatracker.ietf.org/doc/html/rfc7292#appendix-B
[3] https://datatracker.ietf.org/doc/html/rfc8018#section-6.2

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

Regards,
-- 
Francisco Ferrari Bihurriet <fferrari at redhat.com>
Senior Software Engineer
Red Hat Argentina (https://www.redhat.com)

A00A 468A 5506 5D16 9851  E3A9 CD8B C3EF 772B BD6F



From jpai at openjdk.org  Wed Feb  8 01:55:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 01:55:48 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <vdtstlMwXANkrCKAMuAn8UpnQVptdiD_JSnhg_y4_88=.ceda6eef-dc3b-4081-8e23-5f6bb704e5a3@github.com>

On Tue, 7 Feb 2023 22:25:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

Hello Mandy, the changes look fine to me.

Each of these files will need a copyright year update before integrating.

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

Marked as reviewed by jpai (Reviewer).

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


From valeriep at openjdk.org  Wed Feb  8 01:59:43 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 8 Feb 2023 01:59:43 GMT
Subject: RFR: 8295425: DH keys missing the optional private value length field
 even when it's specified
Message-ID: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>

This changes the SunPKCS11 provider to use the same default private exponent length as the value used by SunJCE provider when initializing the DH Key Pair Generator impl using key size. In addition, the generated key pair will contain the specified parameters. If the supplied parameter does not contain the optional private exponent length, then we will leave it to the underlying PKCS11 library.

Thanks in advance for the review~
Valerie

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

Commit messages:
 - 8295425: DH keys missing the optional private value length field even when it's specified

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

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


From mchung at openjdk.org  Wed Feb  8 03:42:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 03:42:16 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

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

  update copyright end year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12463/files
  - new: https://git.openjdk.org/jdk/pull/12463/files/abeecaf1..627da759

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

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

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


From mchung at openjdk.org  Wed Feb  8 03:42:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 03:42:16 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <vdtstlMwXANkrCKAMuAn8UpnQVptdiD_JSnhg_y4_88=.ceda6eef-dc3b-4081-8e23-5f6bb704e5a3@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <vdtstlMwXANkrCKAMuAn8UpnQVptdiD_JSnhg_y4_88=.ceda6eef-dc3b-4081-8e23-5f6bb704e5a3@github.com>
Message-ID: <H4m2RQUlmogrkbwTgirveFq8DP8vnjmzpGGpmg33CNU=.bf747d3d-be49-45ef-aa94-ec92e79e2764@github.com>

On Wed, 8 Feb 2023 01:53:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright end year
>
> Hello Mandy, the changes look fine to me.
> 
> Each of these files will need a copyright year update before integrating.

Thanks for the review @jaikiran

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

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


From jpai at openjdk.org  Wed Feb  8 05:27:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 05:27:42 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <VGPMX9KZjPSWR31jdYdTScjtg4KFOjTa_OMgMsFKKTQ=.1d9a5d8f-4215-49ea-897f-1f1ce242d41a@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

Marked as reviewed by jpai (Reviewer).

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

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


From jwaters at openjdk.org  Wed Feb  8 08:31:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:31:09 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v6]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <HkL5vx2E1jDr55u_pnt2FZtVMb5knZ4SnroOytx9h28=.998951f9-ed1a-4408-b591-44e7c507ceb7@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

  Revert awt_List.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/e6d54f21..cb0f33bf

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

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

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


From jwaters at openjdk.org  Wed Feb  8 08:31:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:31:11 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
 <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
 <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>
Message-ID: <oismWdH6blxn1BU_dld0qAgmiB_5O_EeXvNGlWMD7_8=.f2492f68-bf96-4704-a39b-dd2da351eb10@github.com>

On Tue, 7 Feb 2023 19:19:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994
>
>> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994
> 
> Thank you, @TheShermanTanker.
> 
> Do you still want to keep the changes?
> If it's not too critical, I would rather prefer you revert the changes to `awt_List.cpp`.

No worries, I'm fine with reverting `awt_List.cpp`, I can set my local branch up to avoid a rebase conflict when the commented code does get deleted rather easily

On the other hand, could I trouble you for a quick review of https://github.com/openjdk/jdk/pull/12405? It's just a constructor from libawt that I happened to overlook in my previous Pull Request on initialization orders. Sorry for the trouble!

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

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


From jwaters at openjdk.org  Wed Feb  8 08:36:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:36:03 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v7]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <6R_itk-rGsyjqyl0jNSC9LfGx9LC9cgFVBEy5oQAgYU=.90078df9-9a42-4ece-b334-e801a2129aef@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

 - Merge branch 'openjdk:master' into comments
 - Revert awt_List.cpp
 - D3DVertexCacher.cpp
 - awt_List.cpp
 - sspi.cpp
 - awt_Toolkit.cpp
 - Merge branch 'openjdk:master' into comments
 - Partial Revert
 - sspi.cpp
 - Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/cb0f33bf..85a999e9

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

  Stats: 7867 lines in 252 files changed: 6097 ins; 1034 del; 736 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

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


From duke at openjdk.org  Wed Feb  8 11:34:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 11:34:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
 <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
Message-ID: <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>

On Tue, 7 Feb 2023 22:52:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:

Did you get this from GHA somehow? Do you happen to know the platform, timezone and encoding used?

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

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


From redestad at openjdk.org  Wed Feb  8 11:59:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 11:59:42 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
 <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
 <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>
Message-ID: <UBRlcezmIHLqIp6apGRLppHVfWvJf-kUarTYAsMOJcQ=.498910d2-9dc8-4eae-bdef-c8cf348bacda@github.com>

On Wed, 8 Feb 2023 11:32:02 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:
> 
> Did you get this from GHA somehow? Do you happen to know the platform, timezone and encoding used?

Yes, clicked through the failing macosx-x64 test suite. Here's a link to the summary which has the failing test logs at the bottom: https://github.com/eirbjo/jdk/actions/runs/4114300244

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

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


From redestad at openjdk.org  Wed Feb  8 12:05:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 12:05:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <UBRlcezmIHLqIp6apGRLppHVfWvJf-kUarTYAsMOJcQ=.498910d2-9dc8-4eae-bdef-c8cf348bacda@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
 <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
 <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>
 <UBRlcezmIHLqIp6apGRLppHVfWvJf-kUarTYAsMOJcQ=.498910d2-9dc8-4eae-bdef-c8cf348bacda@github.com>
Message-ID: <OaXd_OHymxHMJa-S72I90bx7zoDmrtkAFse9pp8I9z4=.cad478f4-41b6-41de-adcb-88b04235170e@github.com>

On Wed, 8 Feb 2023 11:57:16 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > > Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:
> > 
> > 
> > Did you get this from GHA somehow? Do you happen to know the platform, timezone and encoding used?
> 
> Yes, clicked through the failing macosx-x64 test suite. Here's a link to the summary which has the failing test logs at the bottom: https://github.com/eirbjo/jdk/actions/runs/4114300244

Seems the failing assert is checking timestamps:

assertEquals((x.getTime() / 2000), y.getTime() / 2000);

... so maybe this is a rare intermittent issue. It's just very suspect though that it happens in the test you're changing.

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

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


From dfuchs at openjdk.org  Wed Feb  8 12:25:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 8 Feb 2023 12:25:42 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <zhgiz3QEdWcIY2Al969OS46ybPVs0wS8J5b_AXvD9Eg=.93acd381-bfac-4682-8dea-fcde4adad204@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

LGTM. I can't help noticing that the code for SocketPermission, PropertyPermission, and ServicePermission is almost identical. But there's not much we could do factorize that easily since the lambda requires access to private static method accessors: trying to factorize would probably add to the complexity instead of reducing it and impair readability.

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

Marked as reviewed by dfuchs (Reviewer).

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


From duke at openjdk.org  Wed Feb  8 13:19:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 13:19:54 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
Message-ID: <ZiZSExF0n_TO-Pitb5SHUT2Rl6PlF_E29Od8zVVOQNw=.d425aa3e-4b89-4848-a356-57d0faae8d7d@github.com>

On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into getentrypos-prefixmatch
>  - Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
>  - Spelling fix in test data for non-ascii latin1 string
>  - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
>  - Rename test to InvalidBytesInEntryNameOrComment
>  - Adjust whitespace
>  - Some minor improvements to code comments
>  - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
>  - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
>  - ByteBuffers for reading ZIP files must be little-endian
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/4399bd8c...06047377

I have reproduced this by running testUnicodeManyEntries in a while loop. Smells of hash collisions or System.currentTimeMillis issues.

I'm marking this PR as draft while we investigate this issue.

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

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


From jwaters at openjdk.org  Wed Feb  8 14:27:44 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 14:27:44 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <oismWdH6blxn1BU_dld0qAgmiB_5O_EeXvNGlWMD7_8=.f2492f68-bf96-4704-a39b-dd2da351eb10@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
 <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
 <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>
 <oismWdH6blxn1BU_dld0qAgmiB_5O_EeXvNGlWMD7_8=.f2492f68-bf96-4704-a39b-dd2da351eb10@github.com>
Message-ID: <K3Vr5qyrS2-oC33pobb4o4VpY0veF-bpqkZ7zVXh90M=.c2d09121-af20-40f3-b6e0-b7c402af1a2a@github.com>

On Wed, 8 Feb 2023 08:23:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994
>> 
>> Thank you, @TheShermanTanker.
>> 
>> Do you still want to keep the changes?
>> If it's not too critical, I would rather prefer you revert the changes to `awt_List.cpp`.
>
> No worries, I'm fine with reverting `awt_List.cpp`, I can set my local branch up to avoid a rebase conflict when the commented code does get deleted rather easily
> 
> On the other hand, could I trouble you for a quick review of https://github.com/openjdk/jdk/pull/12405? It's just a constructor from libawt that I happened to overlook in my previous Pull Request on initialization orders. Sorry for the trouble!

Thanks for the review! Are the other changes here ok with you in the meantime?

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

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


From duke at openjdk.org  Wed Feb  8 15:21:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 15:21:23 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v5]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <_24L8SrA8ejikdCKtYDEoX7kVmF5yJxyvC3dvEo9yeg=.300e1bf3-c213-4cd1-b52d-c98ae654c692@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  In the ZipCoder.compare base implementation, add check that the decoded name startsWith the search name. Add a test to TestZipFileEncodings which catches this regression by performing lookups on entries with matching hash codes and lengths.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/06047377..f9285261

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

  Stats: 37 lines in 2 files changed: 34 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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


From duke at openjdk.org  Wed Feb  8 15:31:15 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 15:31:15 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Align entry name whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/f9285261..ac7c4c7a

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

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

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


From duke at openjdk.org  Wed Feb  8 15:31:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 15:31:19 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v5]
In-Reply-To: <_24L8SrA8ejikdCKtYDEoX7kVmF5yJxyvC3dvEo9yeg=.300e1bf3-c213-4cd1-b52d-c98ae654c692@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_24L8SrA8ejikdCKtYDEoX7kVmF5yJxyvC3dvEo9yeg=.300e1bf3-c213-4cd1-b52d-c98ae654c692@github.com>
Message-ID: <PWw8k5a6EsJ2b1F-JYUvdfEqsS5vXEupzWSUjeoayzQ=.16839e7f-1431-4503-b7f9-8bad0a732584@github.com>

On Wed, 8 Feb 2023 15:21:23 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   In the ZipCoder.compare base implementation, add check that the decoded name startsWith the search name. Add a test to TestZipFileEncodings which catches this regression by performing lookups on entries with matching hash codes and lengths.

I found the bug!

Turns out the entry.startsWith(name) check got lost when moving the slashMatch logic into ZipCoder.compare. This resulted in a possible false positive SLASH_MATCH for non-UTF ZIPs if two names have colliding hash codes AND equal lengths. This case is rare, so we are lucky that the TestZipFileEncodings found it in one of the runs!

The fix is to add back the startsWith check. I have also added a test to TestZipFileEncodings which reliably reproduces the issue using the names found from the analysis.

Thanks to @cl4es for identifying the failing test which I had noticed, but misinterpreted as an infra glitch.

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

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


From redestad at openjdk.org  Wed Feb  8 16:08:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 16:08:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
Message-ID: <KNsiozMAEf3AY8ntZdW_MYeHyZOyguL9mzOuLi5VINg=.fe4a3a28-4d57-479d-beaf-7b27265c3cd2@github.com>

On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align entry name whitespace

Good! Would it be too much to ask for you to try and construct such a test for UTF-8 zip files, too?

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

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


From duke at openjdk.org  Wed Feb  8 16:13:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 16:13:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
Message-ID: <AEoobdQsuST985cOZ8RUT3pvoXmpYSnqFd0lz4X51LU=.32bd787a-7ae7-4db4-8cfc-2f8f45de8b2f@github.com>

On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align entry name whitespace

It takes unicode-charsets as a DataProvider input parameter, so that should already be covered? Or did you mean something else?

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

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


From duke at openjdk.org  Wed Feb  8 16:36:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 16:36:16 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/ac7c4c7a..3cb77dba

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

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

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


From duke at openjdk.org  Wed Feb  8 16:37:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 16:37:45 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
Message-ID: <ur4Jy5k_buUe0RYJ-5JMmJ42JWlpEYpZnIXzrqIjYxo=.641f67bf-fe3f-4e7b-87fc-4610f76d183e@github.com>

On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align entry name whitespace

I found the following ASCII, same length, hash code colliding dir names which we can use instead:


_____1637461950/
_____-408231241/


This allows the test to run with all charsets. Fails for all charsets expect UTF-8.

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

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


From redestad at openjdk.org  Wed Feb  8 17:14:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 17:14:49 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <UtYLuRh41GSxGd_bTdsRYI1xW9iRaC4sze06kZbOoVE=.51701b73-2223-45d9-96d6-62f718501b7d@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

Marked as reviewed by redestad (Reviewer).

Great! Extending coverage to provoke the issue on most charsets is good, and it should guard UTF-8 from regressing too - no?

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

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


From mullan at openjdk.org  Wed Feb  8 17:19:47 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Feb 2023 17:19:47 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <NIFg7DQ_mPMwxcSTPevek9jhYkKB6Svo98Wa4HeP5U4=.234ed2cf-cae4-4f4d-817d-d94e4366656c@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

There's also one in `FilePermission.add()` that can be changed to use a lambda.

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

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


From duke at openjdk.org  Wed Feb  8 17:30:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 17:30:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <UtYLuRh41GSxGd_bTdsRYI1xW9iRaC4sze06kZbOoVE=.51701b73-2223-45d9-96d6-62f718501b7d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <UtYLuRh41GSxGd_bTdsRYI1xW9iRaC4sze06kZbOoVE=.51701b73-2223-45d9-96d6-62f718501b7d@github.com>
Message-ID: <aDHFmaqv42qeRmcp9e5-9ajabhwUNcl_e-sJXUvoVhA=.5a238942-0eab-4f6b-a53d-4d80101a3b7e@github.com>

On Wed, 8 Feb 2023 17:11:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Great! Extending coverage to provoke the issue on most charsets is good, and it should guard UTF-8 from regressing too - no?

It also guards UTFZipCoder from this particular regression, yes.

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

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


From mchung at openjdk.org  Wed Feb  8 17:58:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 17:58:12 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v3]
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <3zcZe9XAcX58dk8lhaHt6rbVH5xeUdNvm9IY7E2NsCs=.e4878f30-ea16-4e56-a55e-1d66e064d230@github.com>

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

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

 - Update FilePermission::add to use lambda
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8301462
 - update copyright end year
 - JDK-8301462: Convert Permission files to use lambda after JDK-8076596

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12463/files
  - new: https://git.openjdk.org/jdk/pull/12463/files/627da759..a4d03d02

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

  Stats: 15980 lines in 457 files changed: 9564 ins; 3402 del; 3014 mod
  Patch: https://git.openjdk.org/jdk/pull/12463.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12463/head:pull/12463

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


From mchung at openjdk.org  Wed Feb  8 17:58:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 17:58:13 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <K3RW1It4GTRPCb9qfy8PVqB78BORzLeOYEqB3XWKPjU=.e8abf94e-c9b5-49db-a4d7-19e0f264a34f@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

Updated `FilePermissionCollection::add` to use lambda.

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

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


From mullan at openjdk.org  Wed Feb  8 18:07:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Feb 2023 18:07:44 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v3]
In-Reply-To: <3zcZe9XAcX58dk8lhaHt6rbVH5xeUdNvm9IY7E2NsCs=.e4878f30-ea16-4e56-a55e-1d66e064d230@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <3zcZe9XAcX58dk8lhaHt6rbVH5xeUdNvm9IY7E2NsCs=.e4878f30-ea16-4e56-a55e-1d66e064d230@github.com>
Message-ID: <TdW3moticMbV7_idodOFxMjXdceZBCT4_VDgUSVKc4M=.45e7eb1a-9afb-46fc-b1aa-ed5646fc2fa0@github.com>

On Wed, 8 Feb 2023 17:58:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update FilePermission::add to use lambda
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8301462
>  - update copyright end year
>  - JDK-8301462: Convert Permission files to use lambda after JDK-8076596

Marked as reviewed by mullan (Reviewer).

Bug needs a `noreg` label.

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

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


From mchung at openjdk.org  Wed Feb  8 19:09:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 19:09:56 GMT
Subject: Integrated: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <l3qiqASNhBGpwiyHc-1q5J5uL_zHU9UDu5DJX9luH0o=.213ec531-3d2b-45f1-8a83-1ffa8afbc7f9@github.com>

On Tue, 7 Feb 2023 22:25:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

This pull request has now been integrated.

Changeset: 10dd98d0
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10dd98d0dd6aeb6f214999590ed19707a203f591
Stats:     98 lines in 5 files changed: 4 ins; 37 del; 57 mod

8301462: Convert Permission files to use lambda after JDK-8076596

Reviewed-by: jpai, dfuchs, mullan

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

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


From aivanov at openjdk.org  Wed Feb  8 23:03:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 23:03:46 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v7]
In-Reply-To: <6R_itk-rGsyjqyl0jNSC9LfGx9LC9cgFVBEy5oQAgYU=.90078df9-9a42-4ece-b334-e801a2129aef@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <6R_itk-rGsyjqyl0jNSC9LfGx9LC9cgFVBEy5oQAgYU=.90078df9-9a42-4ece-b334-e801a2129aef@github.com>
Message-ID: <_FDvJI7hd0i0SUCQffTxCntCkYsjCOjNppPn7YpwO5k=.fa19eac5-79c8-417d-96c1-6e1b60e0a493@github.com>

On Wed, 8 Feb 2023 08:36:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into comments
>  - Revert awt_List.cpp
>  - D3DVertexCacher.cpp
>  - awt_List.cpp
>  - sspi.cpp
>  - awt_Toolkit.cpp
>  - Merge branch 'openjdk:master' into comments
>  - Partial Revert
>  - sspi.cpp
>  - Comments

Marked as reviewed by aivanov (Reviewer).

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

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


From peter.firmstone at zeus.net.au  Thu Feb  9 00:20:20 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 9 Feb 2023 10:20:20 +1000
Subject: Implementing an Authorization framework on Java.
In-Reply-To: <bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au>
References: <bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au>
Message-ID: <6ff1e3d1-d55f-5d19-954e-4849981064ae@zeus.net.au>

I don't think I'm really asking for much here.?? JEP411's plan will 
destroy our ability to manage user and service authorization in our 
existing software, at least cut us a little slack.? I wish we built our 
software on some other authorization API, unfortunately we didn't.

We're just trying to migrate as best we can to future versions of Java.

-- 
Regards,
  
Peter Firmstone

On 7/02/2023 12:53 pm, Peter Firmstone wrote:
>
> Hello OpenJDK folk,
>
> SecurityManager, AccessController and AccessControlContext will be 
> removed in a future version of Java.
>
> Just briefly: Our software is heavily dependant on Java's 
> Authorization framework, we use ProtectionDomain's to represent remote 
> services for authorization decisions.? We are working out how to 
> implement a new authorization framework after SecurityManager's removal.
>
> Many libraries call AccessController#doPrivileged methods, when these 
> methods are removed, we're going to have a big problem with viral 
> permissions. ? Restricted authorization will become meaningless if it 
> has to be granted to all domains on a call stack.
>
> https://github.com/opensearch-project/OpenSearch/issues/1687
>
> Retaining methods in the platform that developers can instrument will 
> provide a common frame of reference for authorization decisions, 
> that's runtime backward non-breaking, without burdening OpenJDK with 
> maintenance.
>
> I'm requesting retaining the DomainController interface, 
> AccessController, AccessControlContext and Subject methods as no-op's 
> for instrumentation???? Please leave them deprecated as no-op's, but 
> not "deprecated for removal".
>
> https://github.com/pfirmstone/HighPerformanceSecurity
>
> Some thoughts:
>
>  1. Ability to disable finalizers in Java 18 onwards is important to
>     prevent finalizer attacks when instrumenting constructors to throw
>     a RuntimeException.
>  2. Guard#check methods can be no-op's for instrumentation.?? If I can
>     replace all instances of SecurityManager#checkPermission in
>     OpenJDK with Guard#check, I can contribute the patches, this will
>     assist greatly in the transition process of retaining existing
>     hooks, while developing replacements.
>  3. Reduce the size of the Java Platform's trusted computing base by
>     giving all system ProtectionDomain's a CodeSource with a non-null
>     meaningful URL.?? Unfortunately Java Serialization is in the base
>     module, so we cannot authorize it's use with a permission check,
>     as the base module needs AllPermission, it has to be managed with
>     serial filters
>     (https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
>     - perhaps someone will write a serialfilter generation tool that
>     works similarly to our POLP policy generation tool?). Privileges
>     cannot be elevated by an authenticated Subject, when all domains
>     on the call stack are already privileged.? If Serialization was in
>     a different ProtectionDomain, then we could prevent
>     de-serialization for unauthenticated Subject's.?? Perhaps OpenJDK
>     might consider moving Serialization into a different module in
>     future before it's eventual removal?
>  4. Instrument all data parsing methods with guard checks, eg XML.??
>     This allows authorization decisions to parse remote data based on
>     the Principal's of the remotely authenticated Subject, to prevent
>     injection attacks.
>  5. We already have principle of least privilege policy generation
>     tools and efficient policy checking tools for authorization in
>     place.?? These allow for simple policy file generation, auditing,
>     editing and deployment.
>
> -- 
> Regards,
>   
> Peter Firmstone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230209/5a398c1d/attachment.htm>

From jwaters at openjdk.org  Thu Feb  9 03:23:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Feb 2023 03:23:52 GMT
Subject: Integrated: 8301443: Clean broken comments from Windows code
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <AZ91hg5AdgTOQjiD7GElkAaYRj0vRB6qtoR3lnyRJvM=.c4012eae-ec8c-4aa3-b97b-215ab5bee227@github.com>

On Tue, 31 Jan 2023 06:28:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

This pull request has now been integrated.

Changeset: 70f31501
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70f3150166a758fe9fa14860588218ef41c2bff4
Stats:     27 lines in 12 files changed: 2 ins; 1 del; 24 mod

8301443: Clean broken comments from Windows code

Reviewed-by: aivanov

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

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


From duke at openjdk.org  Thu Feb  9 09:48:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 09:48:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <8700MJpl3hpnrZX4oIKqAXbBNEd5LWXN8SNK3JSqDXs=.4cace602-d522-473a-b5e5-637405dba100@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

A somewhat unrelated observation:

If String had a mismatch method, this last regression would probably not have been introduced, since the logic would align better with UTF8ZipCoder which used Arrays.mismatch.

Also, it could help performance since ZipCoder.compare now needs to do back-to-back equals and startsWith over mostly the same bytes.

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

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


From redestad at openjdk.org  Thu Feb  9 10:07:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 10:07:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <VYqYVkfokdGFn2g4AASmcf05PXYviK6mumcx1XYWbO4=.faa97241-953e-4ff9-8a4b-2d6f52585b28@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

You could skip the `equals`:

        if (decoded.startsWith(str)) {
            if (decoded.length() == str.length()) {
                return Comparison.EXACT_MATCH;
            } else if (addSlash
                && decoded.length() == str.length() + 1
                && decoded.endsWith("/") ) {
                return Comparison.SLASH_MATCH;
            }
        }
        return Comparison.NO_MATCH;

Should be a win and avoids the need for a new mismatch method here.

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

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


From duke at openjdk.org  Thu Feb  9 10:57:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 10:57:41 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <VYqYVkfokdGFn2g4AASmcf05PXYviK6mumcx1XYWbO4=.faa97241-953e-4ff9-8a4b-2d6f52585b28@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <VYqYVkfokdGFn2g4AASmcf05PXYviK6mumcx1XYWbO4=.faa97241-953e-4ff9-8a4b-2d6f52585b28@github.com>
Message-ID: <cNwIsLK6USpmJJkzT0KSthOWThf0Rak10tL0F5oyBDU=.3effe77a-2d59-4880-aac2-7929ada1da6c@github.com>

On Thu, 9 Feb 2023 10:05:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Should be a win and avoids the need for a new mismatch method here.

Interestingly, this is not a win:

PR:


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   73.633 ? 4.349  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   74.477 ? 1.667  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  108.352 ? 1.598  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  110.425 ? 1.867  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   21.921 ? 0.251  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   22.836 ? 0.279  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   51.890 ? 2.289  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   56.722 ? 0.701  ns/op


Claes:


BBenchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   84.518 ? 4.440  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   85.359 ? 1.484  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  117.003 ? 1.481  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  119.026 ? 1.073  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   22.027 ? 0.188  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   22.929 ? 0.282  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   52.513 ? 1.859  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   56.425 ? 0.699  ns/op


(I forced ZipCoder.compare here by simply removing UTFZipCoder.compare)

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

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


From redestad at openjdk.org  Thu Feb  9 11:09:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 11:09:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

Oh -- fun! Perhaps `startsWith` doesn't take advantage of the optimized intrinsic for `equals`. 

Could be interesting to see if special-casing `startsWith` to call `equals` when possible would help:

diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index 1897a06cd60..5a4fc200344 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -2267,6 +2267,9 @@ public final class String
      */
     public boolean startsWith(String prefix, int toffset) {
         // Note: toffset might be near -1>>>1.
+        if (toffset == 0 && length() == prefix.length()) {
+            return equals(prefix);
+        }
         if (toffset < 0 || toffset > length() - prefix.length()) {
             return false;
         }
         ```

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

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


From duke at openjdk.org  Thu Feb  9 11:20:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:20:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>
Message-ID: <HZZmFp8CQ64Esbj3xM6qHHMxppew5KZbBsg9KjcOqMs=.48840cb5-be37-49fe-aab5-7fcb1ebca9b3@github.com>

On Thu, 9 Feb 2023 11:07:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Could be interesting to see if special-casing `startsWith` to call `equals` when possible would help:

It helps... a lot!


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   72.800 ? 3.426  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   73.434 ? 0.671  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  107.538 ? 1.309  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  110.775 ? 2.252  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   22.022 ? 0.170  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.242 ? 1.569  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   50.946 ? 0.458  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   57.856 ? 3.021  ns/op

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

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


From duke at openjdk.org  Thu Feb  9 11:35:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:35:47 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <HZZmFp8CQ64Esbj3xM6qHHMxppew5KZbBsg9KjcOqMs=.48840cb5-be37-49fe-aab5-7fcb1ebca9b3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>
 <HZZmFp8CQ64Esbj3xM6qHHMxppew5KZbBsg9KjcOqMs=.48840cb5-be37-49fe-aab5-7fcb1ebca9b3@github.com>
Message-ID: <wXfgzL7CpzcCCJz2VjqcAwyB40ird4usIXR9nnObsaE=.b2714767-491c-4b13-888e-903ffbee507b@github.com>

On Thu, 9 Feb 2023 11:17:54 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> It helps... a lot!

I guess an update to String.startsWith should be handled separately from this PR.

If startsWith will be optimized, then I'm happy to update this PR to use startsWith as you suggested. Then ZipCoder will speed up for free with any later startsWith optimization.

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

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


From duke at openjdk.org  Thu Feb  9 11:46:59 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:46:59 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v8]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <QcfYEGkvkWVpructcsBm1Jl9Zuh6FRQ9kRmqSEmeAWc=.06abeef6-1c73-4332-99d0-112c0822b1ba@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Moving startsWith check first to avoid back-to-back equals,startsWith calls

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/3cb77dba..427ad671

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

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

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


From redestad at openjdk.org  Thu Feb  9 11:47:03 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 11:47:03 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

Yes, I'll file a PR to see if we can make `startsWith` a bit sharper. In addition to - or instead of - an `equals` shortcut then if coders are the same we could use `ArraysSupport.mismatch` which should get similar speed and help more generally.

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

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


From duke at openjdk.org  Thu Feb  9 11:49:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:49:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>
Message-ID: <oUVRygqci4pYyTmdVQA64YlkE-gV1VlGR0uTXGo10_g=.08da16a9-64b6-4ed9-bdbd-3748a6733753@github.com>

On Thu, 9 Feb 2023 11:39:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, I'll file a PR to see if we can make `startsWith` a bit sharper

Thanks! I pushed the change to ZipCoder.compare.

> In addition to - or instead of - an `equals` shortcut then if coders are the same we could use `ArraysSupport.mismatch` which should get similar speed and help more generally.

..and if String had (an optimized) mismatch method, then I bet all or most of the comparison methods (equals, compareTo, endsWith, startsWith, regionMatches) could delegate to that  :-)

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

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


From duke at openjdk.org  Thu Feb  9 12:07:04 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 12:07:04 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Revert accidental removal of UTF8ZipCoder.compare

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/427ad671..d94cbe38

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

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

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


From redestad at openjdk.org  Thu Feb  9 13:08:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 13:08:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <oUVRygqci4pYyTmdVQA64YlkE-gV1VlGR0uTXGo10_g=.08da16a9-64b6-4ed9-bdbd-3748a6733753@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>
 <oUVRygqci4pYyTmdVQA64YlkE-gV1VlGR0uTXGo10_g=.08da16a9-64b6-4ed9-bdbd-3748a6733753@github.com>
Message-ID: <JHZlRN3wF3Fvkgp9iRG9qE-Y7YOzSFKGoz_3QT8Qr8M=.b2d92463-1ebd-4131-b08a-f48fe855e940@github.com>

On Thu, 9 Feb 2023 11:46:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > In addition to - or instead of - an `equals` shortcut then if coders are the same we could use `ArraysSupport.mismatch` which should get similar speed and help more generally.
> 
> ..and if String had (an optimized) mismatch method, then I bet all or most of the comparison methods (equals, compareTo, endsWith, startsWith, regionMatches) could delegate to that :-)

A private mismatch method might make sense. A public method would require making a stronger case, I think, e.g. showing use cases a mismatcher would solve (elegantly, performantly) that can't be expressed with existing methods.

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

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


From mullan at openjdk.org  Thu Feb  9 18:22:00 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Feb 2023 18:22:00 GMT
Subject: Integrated: 8301260: Add system property to toggle XML Signature
 secure validation mode
In-Reply-To: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
References: <y34LsgUbuhXV_6apgvs42Jd7RMcw89H-ayzjZ3MKpTk=.bafa8b14-34fa-4d97-918d-b6e4421d3ec0@github.com>
Message-ID: <4Io4lbuBjP2Mf3rpzN2IYNRsrHczGkdIJw5aIHntXa4=.dd0c676d-b241-4318-a0d0-8b9a1ac206c2@github.com>

On Wed, 1 Feb 2023 14:46:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds a system property that can be used to enable/disable the XML Signature secure validation mode. This is useful for enabling/disabling the mode at runtime. The system property will supersede and have the same name as the XMLCryptoContext property that can be used to enable/disable the mode: "org.jcp.xml.dsig.secureValidation".

This pull request has now been integrated.

Changeset: 7901f459
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7901f459dc8e0d3235e3e250d9a6bcf31cb031a2
Stats:     156 lines in 5 files changed: 149 ins; 0 del; 7 mod

8301260: Add system property to toggle XML Signature secure validation mode

Reviewed-by: weijun, coffeys

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

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


From duke at openjdk.org  Thu Feb  9 18:24:59 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 9 Feb 2023 18:24:59 GMT
Subject: Integrated: 8298868: Update EngineCloseOnAlert.java for changes to TLS
 implementation
In-Reply-To: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
References: <o2geplAugwgBwhlWtpQfkkmNyTPX-Wah6txhD5JqliY=.545458fa-8aaf-4024-8b8d-a41375349dcd@github.com>
Message-ID: <sKEa0cI0vGi6bziYLv4KyfTnqxIERtM6Mw_DerkfiFU=.f261ae13-5b0e-4ae0-8794-0e37cc6d6bf2@github.com>

On Mon, 9 Jan 2023 12:19:27 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Refactored the code a little bit and updated the test for changes to the TLS state machine.

This pull request has now been integrated.

Changeset: 7fd440d9
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fd440d97c2bb7b7a6cd7094e7339d65d23e7815
Stats:     61 lines in 2 files changed: 14 ins; 14 del; 33 mod

8298868: Update EngineCloseOnAlert.java for changes to TLS implementation

Reviewed-by: rhalade

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

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


From rhalade at openjdk.org  Thu Feb  9 20:52:00 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 9 Feb 2023 20:52:00 GMT
Subject: Integrated: 8245654: Add Certigna Root CA
In-Reply-To: <QD8dU8-pLMiAvsdr-9k8FDXgqm0t-hhngz09Bb16mPU=.69c13db6-3ce6-4ea7-83ae-6eeaeb2253c9@github.com>
References: <QD8dU8-pLMiAvsdr-9k8FDXgqm0t-hhngz09Bb16mPU=.69c13db6-3ce6-4ea7-83ae-6eeaeb2253c9@github.com>
Message-ID: <k5t1iPif0LlYkwsRoIp3CeCocejDHqHZsnBnMRq71iY=.c765d505-0561-4820-a0c6-62811a62f615@github.com>

On Wed, 1 Feb 2023 21:28:25 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix adds Certigna root CA to cacerts trust store.

This pull request has now been integrated.

Changeset: 8c87a674
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c87a67419b91f254ed7e4dd8ac8d294b8c4735e
Stats:     262 lines in 3 files changed: 258 ins; 0 del; 4 mod

8245654: Add Certigna Root CA

Reviewed-by: mullan

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

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


From mullan at openjdk.org  Thu Feb  9 21:08:35 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Feb 2023 21:08:35 GMT
Subject: RFR: 8301700: Increase the default TLS Diffie-Hellman group size from
 1024-bit to 2048-bit
Message-ID: <obyTgDGT6M_EeEtbJ-itXd-WkcOSuhhVj4xW35DKIUA=.f936a1d9-6444-45b0-b57a-84b32660128e@github.com>

Please review this change to increase the default Diffie-Hellman group size used in the key exchange method of TLS_DHE cipher suites from 1024-bit to 2048-bit. This issue does not affect TLS 1.3.

See the CSR for more details on the rationale for this change and the expected compatibility risk (low).

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

Commit messages:
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/12502/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301700
  Stats: 30 lines in 2 files changed: 1 ins; 10 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12502/head:pull/12502

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


From kdriver at openjdk.org  Thu Feb  9 21:34:20 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Feb 2023 21:34:20 GMT
Subject: RFR: 8178806: Better exception logging in crypto code
Message-ID: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>

Updated this `template` file to not fail silently on `canUseProvider` check in debug mode to provide additional information to aid in debugging.

See: https://bugs.openjdk.org/browse/JDK-8178806

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

Commit messages:
 - 8178806: Better exception logging in crypto code

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

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


From valeriep at openjdk.org  Thu Feb  9 21:49:46 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 9 Feb 2023 21:49:46 GMT
Subject: RFR: 8178806: Better exception logging in crypto code
In-Reply-To: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
Message-ID: <ontRA0S4ffz6kJ8Yf8edQ3upo2Q0GdntND9c24MExnw=.ff80e435-c346-4667-a536-86516082f1ef@github.com>

On Thu, 9 Feb 2023 21:26:50 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Updated this `template` file to not fail silently on `canUseProvider` check in debug mode to provide additional information to aid in debugging.
> 
> See: https://bugs.openjdk.org/browse/JDK-8178806

src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 240:

> 238:         Exception e = getVerificationResult(p);
> 239:         if (debug != null) {
> 240:             if(e != null) {

line 239 and 240 can be combined into one line?

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

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


From kdriver at openjdk.org  Thu Feb  9 21:49:47 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Feb 2023 21:49:47 GMT
Subject: RFR: 8178806: Better exception logging in crypto code
In-Reply-To: <ontRA0S4ffz6kJ8Yf8edQ3upo2Q0GdntND9c24MExnw=.ff80e435-c346-4667-a536-86516082f1ef@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
 <ontRA0S4ffz6kJ8Yf8edQ3upo2Q0GdntND9c24MExnw=.ff80e435-c346-4667-a536-86516082f1ef@github.com>
Message-ID: <6BvUm38dVOOE9Lsn6DqzOlFyTfX9K8n35KutuGaSzOI=.0be2a57d-62cc-44b7-93ee-fc8294ca3411@github.com>

On Thu, 9 Feb 2023 21:45:35 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Updated this `template` file to not fail silently on `canUseProvider` check in debug mode to provide additional information to aid in debugging.
>> 
>> See: https://bugs.openjdk.org/browse/JDK-8178806
>
> src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 240:
> 
>> 238:         Exception e = getVerificationResult(p);
>> 239:         if (debug != null) {
>> 240:             if(e != null) {
> 
> line 239 and 240 can be combined into one line?

I thought about this, but logically they are not related... 

I can definitely combine, but I made this choice for readability. What do you think?

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

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


From kdriver at openjdk.org  Thu Feb  9 22:15:07 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Feb 2023 22:15:07 GMT
Subject: RFR: 8178806: Better exception logging in crypto code [v2]
In-Reply-To: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
Message-ID: <VPLChOB8RHMI0uTmGreK6iDXkqlyzcJkDIxoDuG-hMI=.d6570abd-4e9c-4607-a052-1e6fbc8ec37a@github.com>

> Updated this `template` file to not fail silently on `canUseProvider` check in debug mode to provide additional information to aid in debugging.
> 
> See: https://bugs.openjdk.org/browse/JDK-8178806

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

  just use default toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12504/files
  - new: https://git.openjdk.org/jdk/pull/12504/files/517ab671..d73df1b2

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

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

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


From kdriver at openjdk.org  Thu Feb  9 22:15:08 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Feb 2023 22:15:08 GMT
Subject: RFR: 8178806: Better exception logging in crypto code [v2]
In-Reply-To: <6BvUm38dVOOE9Lsn6DqzOlFyTfX9K8n35KutuGaSzOI=.0be2a57d-62cc-44b7-93ee-fc8294ca3411@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
 <ontRA0S4ffz6kJ8Yf8edQ3upo2Q0GdntND9c24MExnw=.ff80e435-c346-4667-a536-86516082f1ef@github.com>
 <6BvUm38dVOOE9Lsn6DqzOlFyTfX9K8n35KutuGaSzOI=.0be2a57d-62cc-44b7-93ee-fc8294ca3411@github.com>
Message-ID: <dk5LFxFOHXGKDz9JEJ2PpKtMwTcaunjf-Xd7UOLfftw=.1f271e47-ff8a-42d5-8fe1-996225b8b260@github.com>

On Thu, 9 Feb 2023 21:47:17 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 240:
>> 
>>> 238:         Exception e = getVerificationResult(p);
>>> 239:         if (debug != null) {
>>> 240:             if(e != null) {
>> 
>> line 239 and 240 can be combined into one line?
>
> I thought about this, but logically they are not related... 
> 
> I can definitely combine, but I made this choice for readability. What do you think?

resolved

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

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


From valeriep at openjdk.org  Thu Feb  9 22:19:42 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 9 Feb 2023 22:19:42 GMT
Subject: RFR: 8178806: Better exception logging in crypto code [v2]
In-Reply-To: <dk5LFxFOHXGKDz9JEJ2PpKtMwTcaunjf-Xd7UOLfftw=.1f271e47-ff8a-42d5-8fe1-996225b8b260@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
 <ontRA0S4ffz6kJ8Yf8edQ3upo2Q0GdntND9c24MExnw=.ff80e435-c346-4667-a536-86516082f1ef@github.com>
 <6BvUm38dVOOE9Lsn6DqzOlFyTfX9K8n35KutuGaSzOI=.0be2a57d-62cc-44b7-93ee-fc8294ca3411@github.com>
 <dk5LFxFOHXGKDz9JEJ2PpKtMwTcaunjf-Xd7UOLfftw=.1f271e47-ff8a-42d5-8fe1-996225b8b260@github.com>
Message-ID: <ZCHLljQ8Dwt3n9w1frRxdzKfUGwSMG1d9EelzjETyy8=.ad2aafd8-8c50-45c0-8c17-73bdc445d596@github.com>

On Thu, 9 Feb 2023 22:10:31 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> I thought about this, but logically they are not related... 
>> 
>> I can definitely combine, but I made this choice for readability. What do you think?
>
> resolved

Also, may just rely on the toString() impl instead of separate handling of getClass() and getMessage()?

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

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


From valeriep at openjdk.org  Thu Feb  9 22:26:44 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 9 Feb 2023 22:26:44 GMT
Subject: RFR: 8178806: Better exception logging in crypto code [v2]
In-Reply-To: <VPLChOB8RHMI0uTmGreK6iDXkqlyzcJkDIxoDuG-hMI=.d6570abd-4e9c-4607-a052-1e6fbc8ec37a@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
 <VPLChOB8RHMI0uTmGreK6iDXkqlyzcJkDIxoDuG-hMI=.d6570abd-4e9c-4607-a052-1e6fbc8ec37a@github.com>
Message-ID: <svZnpgU5yanqNr6BWpY4wYwDE9-ioilM7iwiCQYz8G0=.eb678c89-3139-4128-8139-22f42f8128a5@github.com>

On Thu, 9 Feb 2023 22:15:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Updated this `template` file to not fail silently on `canUseProvider` check in debug mode to provide additional information to aid in debugging.
>> 
>> See: https://bugs.openjdk.org/browse/JDK-8178806
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   just use default toString

Marked as reviewed by valeriep (Reviewer).

add noreg-xxx label to the bug record since there is no regression test?

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

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


From kdriver at openjdk.org  Thu Feb  9 22:26:46 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Feb 2023 22:26:46 GMT
Subject: RFR: 8178806: Better exception logging in crypto code [v2]
In-Reply-To: <ZCHLljQ8Dwt3n9w1frRxdzKfUGwSMG1d9EelzjETyy8=.ad2aafd8-8c50-45c0-8c17-73bdc445d596@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
 <ontRA0S4ffz6kJ8Yf8edQ3upo2Q0GdntND9c24MExnw=.ff80e435-c346-4667-a536-86516082f1ef@github.com>
 <6BvUm38dVOOE9Lsn6DqzOlFyTfX9K8n35KutuGaSzOI=.0be2a57d-62cc-44b7-93ee-fc8294ca3411@github.com>
 <dk5LFxFOHXGKDz9JEJ2PpKtMwTcaunjf-Xd7UOLfftw=.1f271e47-ff8a-42d5-8fe1-996225b8b260@github.com>
 <ZCHLljQ8Dwt3n9w1frRxdzKfUGwSMG1d9EelzjETyy8=.ad2aafd8-8c50-45c0-8c17-73bdc445d596@github.com>
Message-ID: <XEg5foEmRElDCMds6UheOZPURTXYge0mxjy4pmvVh_8=.91d1e874-5eef-42ec-a25a-e3553304fe3b@github.com>

On Thu, 9 Feb 2023 22:16:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> resolved
>
> Also, may just rely on the toString() impl instead of separate handling of getClass() and getMessage()?

That change was already in the previous commit.

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

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


From kdriver at openjdk.org  Thu Feb  9 22:33:54 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Feb 2023 22:33:54 GMT
Subject: Integrated: 8178806: Better exception logging in crypto code
In-Reply-To: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
References: <hUAeCh6KJBfMIEebyWX-GmLvpmtcch3aB7we4loDZok=.ea865d3e-eaf7-4555-86c9-c09cd72a117b@github.com>
Message-ID: <qmcb1Ff-bsHHo2EibGOJBx5WmpMw4tZEjGZy63i0A98=.dfa2a1b0-1bad-4a39-979f-bb8dd56f6f77@github.com>

On Thu, 9 Feb 2023 21:26:50 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Updated this `template` file to not fail silently on `canUseProvider` check in debug mode to provide additional information to aid in debugging.
> 
> See: https://bugs.openjdk.org/browse/JDK-8178806

This pull request has now been integrated.

Changeset: b814cfc3
Author:    Kevin Driver <kdriver at openjdk.org>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b814cfc39d2a49951e8e1839cb2f42d9b7cf705d
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8178806: Better exception logging in crypto code

Reviewed-by: valeriep

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

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


From peter.firmstone at zeus.net.au  Thu Feb  9 23:03:10 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 10 Feb 2023 09:03:10 +1000
Subject: Surviving JEP411 deprecation [WAS]: Implementing an Authorization
 framework on Java.
In-Reply-To: <6ff1e3d1-d55f-5d19-954e-4849981064ae@zeus.net.au>
References: <bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au>
 <6ff1e3d1-d55f-5d19-954e-4849981064ae@zeus.net.au>
Message-ID: <50be4e5e-7150-0a0b-6612-9fe5c70f02fe@zeus.net.au>

Maybe I had the wrong Subject?

I'm still trying to figure out how to migrate before removal of 
deprecated API's.

 1. Our software architecture is designed and currently relies on
    classes in JEP411 for authorisation decisions.
 2. It's not possible for our software to have security bolted on as an
    afterthought, following removal of authorization.
 3. Without authorization, we cannot allow the JVM to have access to
    sensitive information.
 4. We could place the JVM inside an isolated VM as suggested by JEP411
    proponents, but we can no longer allow the JVM to have access to
    sensitive information.?? It is technically possible to do this,
    provided we accept we could no longer use encryption or
    authentication, as we cannot introduce sensitive information into
    the JVM, then we could use observability tools as a watchdog, to
    shutdown and restart the VM if it becomes compromised.?? However,
    that leaves us with very limited functionality.

I realise that OpenJDK likely thinks this is BS, we can just safely 
remove SM, it's obsolete now right?

The problem is, we don't fit the standard category of server 
programming, eg: once the JVM's warmed up, it no longer dynamically 
loads classes, hotspot has compiled them to native binary code; a server 
that fits the publish subscribe model, where it only need parse and 
validate incoming data from clients, and publish responses.? Server 
programming is OpenJDK's target market, we get that.?? Anything in the 
client space is frowned upon, we get that too, but we're not in the 
client space.?? Our clients are also servers.

Our distributed service architecture provides dynamic discovery of 
services (globally over IPv6).?? We rely on Authentication, Encryption 
(Privacy) and Authorization.?? Clients of services are often required to 
download code dynamically, clients and services first discover and 
authenticate available service registrar's using an X500 IPv6 multicast 
discovery process, with checksums to validate details required to 
establish a unicast connection. Unicast IPv6 TCP with Encryption is used 
to ensure that communications are private between authenticated 
connections while establishing connections to service registrar's.

Nodes in the distributed network, aren't distinguished as servers and 
clients, a node that acts as a client will also provide services, even 
if it's just listening to an event service.?? All threads are run with 
authenticated client endpoint Subject's, and service responses with 
server Subject's, to allow the use of authenticated TLS connections.

After nodes have discovered each other, the connection is established 
like so:

 1. Authentication & Establish an Encrypted connection.
 2. The service provides the client with;? code signer certificates, if
    the service requires codebase download, or it may provide a security
    hash, used to validate files, it will also communicate a string that
    represents URL's from which code can be downloaded.? It will also
    communicate any permissions it requires.?? The client Subject is
    allowed to grant a restricted set of permissions.?? The client may
    elect to grant the requested permissions, if it has the privileges
    to do so.
 3. The client provisions a ClassLoader, that's a child of the
    ClassLoader that contains the Service's public API, the identity of
    this ClassLoader is determined by the CodeSource URI's as well as
    the Authenticated identity of the Service.?? The ClassLoader of the
    service proxy represents it's identity in authorization decisions at
    the client.?? Other service proxy's may use the same codebase URL's,
    but unless they have identical identity, cannot load their classes
    into another service proxy's ClassLoader.
 4. At this point, the client unmarshal's the service proxy's Object
    state into the ClassLoader, it doesn't use Java de-serialization to
    do this, just in case anyone is curious.
 5. Only ClassLoaders are responsible for Class resolution, codebase
    annotations are not used, neither is RMIClassLoader used to resolve
    classes.
 6. Now the client (and server) applies constraints to their service
    endpoints, placing restrictions on the level of encryption the
    service can use for network communications, or the Principal's the
    Subject that invokes the service must have.
 7. The client can now use the service, by passing parameters to the
    proxy's methods and accepting returns.?? The service proxy may
    accept or return other services, these services will have the same
    constraints applied, unless clients or services, apply new constraints.
 8. A JVM node may have any number of services proxy's while also
    providing services to other nodes, of many different identities,
    numerous services may participate in transactions, each one with
    it's own identity.

During this process permissions are granted as they are required, once a 
service is no longer used, its ClassLoader becomes unreachable, 
permissions granted dynamically are removed.?? The client environment is 
otherwise locked down with least privilege policy files, that were 
generated and audited during deployment.

We would like to continue to invest in the development of this software, 
it's performant, it scales, encryption is very fast, thanks to recent 
developments in Java session tickets.? We've eliminated unnecessary DNS 
calls (the JVM makes many of these, eg URL, SecureClassLoader, 
CodeSource), and cleared out synchronized and blocking code, replaced it 
with concurrent non blocking code where possible. ? It's well tested, 
much time has been invested into static analysis and cleaning up and 
modernizing code.?? All our hotspots are native JVM methods.?? I suspect 
this is why we are finding bugs in your TLS code, it isn't thread safe ;)

Hopefully there is a future for this software, however it will depend 
our ability to migrate to new versions of Java as they're released.

At least allow us just these few classes to remain (un-deprecated 
please, so developers aren't motivated to remove their privileged 
calls), even if they contain no implementation, so that we may 
instrument them, as we attempt to stay current with OpenJDK.

We are not asking OpenJDK to maintain OpenJDK security using an 
authorization framework, we are just asking you to make it possible for 
us to maintain our software's security ourselves while running on your 
platform.? It's not really possible for us to run on anything else.

-- 
Regards,
  
Peter.

On 9/02/2023 10:20 am, Peter Firmstone wrote:
>
> I don't think I'm really asking for much here.?? JEP411's plan will 
> destroy our ability to manage user and service authorization in our 
> existing software, at least cut us a little slack.? I wish we built 
> our software on some other authorization API, unfortunately we didn't.
>
> We're just trying to migrate as best we can to future versions of Java.
>
> -- 
> Regards,
>   
> Peter Firmstone
> On 7/02/2023 12:53 pm, Peter Firmstone wrote:
>>
>> Hello OpenJDK folk,
>>
>> SecurityManager, AccessController and AccessControlContext will be 
>> removed in a future version of Java.
>>
>> Just briefly: Our software is heavily dependant on Java's 
>> Authorization framework, we use ProtectionDomain's to represent 
>> remote services for authorization decisions.? We are working out how 
>> to implement a new authorization framework after SecurityManager's 
>> removal.
>>
>> Many libraries call AccessController#doPrivileged methods, when these 
>> methods are removed, we're going to have a big problem with viral 
>> permissions. ? Restricted authorization will become meaningless if it 
>> has to be granted to all domains on a call stack.
>>
>> https://github.com/opensearch-project/OpenSearch/issues/1687
>>
>> Retaining methods in the platform that developers can instrument will 
>> provide a common frame of reference for authorization decisions, 
>> that's runtime backward non-breaking, without burdening OpenJDK with 
>> maintenance.
>>
>> I'm requesting retaining the DomainController interface, 
>> AccessController, AccessControlContext and Subject methods as no-op's 
>> for instrumentation???? Please leave them deprecated as no-op's, but 
>> not "deprecated for removal".
>>
>> https://github.com/pfirmstone/HighPerformanceSecurity
>>
>> Some thoughts:
>>
>>  1. Ability to disable finalizers in Java 18 onwards is important to
>>     prevent finalizer attacks when instrumenting constructors to
>>     throw a RuntimeException.
>>  2. Guard#check methods can be no-op's for instrumentation. If I can
>>     replace all instances of SecurityManager#checkPermission in
>>     OpenJDK with Guard#check, I can contribute the patches, this will
>>     assist greatly in the transition process of retaining existing
>>     hooks, while developing replacements.
>>  3. Reduce the size of the Java Platform's trusted computing base by
>>     giving all system ProtectionDomain's a CodeSource with a non-null
>>     meaningful URL.?? Unfortunately Java Serialization is in the base
>>     module, so we cannot authorize it's use with a permission check,
>>     as the base module needs AllPermission, it has to be managed with
>>     serial filters
>>     (https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
>>     - perhaps someone will write a serialfilter generation tool that
>>     works similarly to our POLP policy generation tool?). Privileges
>>     cannot be elevated by an authenticated Subject, when all domains
>>     on the call stack are already privileged. If Serialization was in
>>     a different ProtectionDomain, then we could prevent
>>     de-serialization for unauthenticated Subject's.?? Perhaps OpenJDK
>>     might consider moving Serialization into a different module in
>>     future before it's eventual removal?
>>  4. Instrument all data parsing methods with guard checks, eg XML.??
>>     This allows authorization decisions to parse remote data based on
>>     the Principal's of the remotely authenticated Subject, to prevent
>>     injection attacks.
>>  5. We already have principle of least privilege policy generation
>>     tools and efficient policy checking tools for authorization in
>>     place.?? These allow for simple policy file generation, auditing,
>>     editing and deployment.
>>
>> -- 
>> Regards,
>>   
>> Peter Firmstone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230210/7ce11018/attachment.htm>

From peter.firmstone at zeus.net.au  Thu Feb  9 23:21:02 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 10 Feb 2023 09:21:02 +1000
Subject: Surviving JEP411 deprecation [WAS]: Implementing an Authorization
 framework on Java.
In-Reply-To: <50be4e5e-7150-0a0b-6612-9fe5c70f02fe@zeus.net.au>
References: <bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au>
 <6ff1e3d1-d55f-5d19-954e-4849981064ae@zeus.net.au>
 <50be4e5e-7150-0a0b-6612-9fe5c70f02fe@zeus.net.au>
Message-ID: <ebfeb6da-9ddd-bbd7-2527-d4da6df906fb@zeus.net.au>

Please undeprecate DomainController interface, AccessController, 
AccessControlContext and Subject methods, while removing the remaining 
methods in JEP411.

Just document that these methods don't do anything by default, and use 
the null object pattern where appropriate.

Deprecation is causing developers to remove code that we need, this is 
undoing years of hard work, I'm appealing to you to minimise harm where 
possible.

eg: https://github.com/apache/lucene/issues/11801

-- 
Regards,
  
Peter

On 10/02/2023 9:03 am, Peter Firmstone wrote:
>
> Maybe I had the wrong Subject?
>
> I'm still trying to figure out how to migrate before removal of 
> deprecated API's.
>
>  1. Our software architecture is designed and currently relies on
>     classes in JEP411 for authorisation decisions.
>  2. It's not possible for our software to have security bolted on as
>     an afterthought, following removal of authorization.
>  3. Without authorization, we cannot allow the JVM to have access to
>     sensitive information.
>  4. We could place the JVM inside an isolated VM as suggested by
>     JEP411 proponents, but we can no longer allow the JVM to have
>     access to sensitive information.?? It is technically possible to
>     do this, provided we accept we could no longer use encryption or
>     authentication, as we cannot introduce sensitive information into
>     the JVM, then we could use observability tools as a watchdog, to
>     shutdown and restart the VM if it becomes compromised.?? However,
>     that leaves us with very limited functionality.
>
> I realise that OpenJDK likely thinks this is BS, we can just safely 
> remove SM, it's obsolete now right?
>
> The problem is, we don't fit the standard category of server 
> programming, eg: once the JVM's warmed up, it no longer dynamically 
> loads classes, hotspot has compiled them to native binary code; a 
> server that fits the publish subscribe model, where it only need parse 
> and validate incoming data from clients, and publish responses.? 
> Server programming is OpenJDK's target market, we get that.?? Anything 
> in the client space is frowned upon, we get that too, but we're not in 
> the client space.?? Our clients are also servers.
>
> Our distributed service architecture provides dynamic discovery of 
> services (globally over IPv6).?? We rely on Authentication, Encryption 
> (Privacy) and Authorization.?? Clients of services are often required 
> to download code dynamically, clients and services first discover and 
> authenticate available service registrar's using an X500 IPv6 
> multicast discovery process, with checksums to validate details 
> required to establish a unicast connection.?? Unicast IPv6 TCP with 
> Encryption is used to ensure that communications are private between 
> authenticated connections while establishing connections to service 
> registrar's.
>
> Nodes in the distributed network, aren't distinguished as servers and 
> clients, a node that acts as a client will also provide services, even 
> if it's just listening to an event service.?? All threads are run with 
> authenticated client endpoint Subject's, and service responses with 
> server Subject's, to allow the use of authenticated TLS connections.
>
> After nodes have discovered each other, the connection is established 
> like so:
>
>  1. Authentication & Establish an Encrypted connection.
>  2. The service provides the client with;? code signer certificates,
>     if the service requires codebase download, or it may provide a
>     security hash, used to validate files, it will also communicate a
>     string that represents URL's from which code can be downloaded.?
>     It will also communicate any permissions it requires.?? The client
>     Subject is allowed to grant a restricted set of permissions.?? The
>     client may elect to grant the requested permissions, if it has the
>     privileges to do so.
>  3. The client provisions a ClassLoader, that's a child of the
>     ClassLoader that contains the Service's public API, the identity
>     of this ClassLoader is determined by the CodeSource URI's as well
>     as the Authenticated identity of the Service. The ClassLoader of
>     the service proxy represents it's identity in authorization
>     decisions at the client.?? Other service proxy's may use the same
>     codebase URL's, but unless they have identical identity, cannot
>     load their classes into another service proxy's ClassLoader.
>  4. At this point, the client unmarshal's the service proxy's Object
>     state into the ClassLoader, it doesn't use Java de-serialization
>     to do this, just in case anyone is curious.
>  5. Only ClassLoaders are responsible for Class resolution, codebase
>     annotations are not used, neither is RMIClassLoader used to
>     resolve classes.
>  6. Now the client (and server) applies constraints to their service
>     endpoints, placing restrictions on the level of encryption the
>     service can use for network communications, or the Principal's the
>     Subject that invokes the service must have.
>  7. The client can now use the service, by passing parameters to the
>     proxy's methods and accepting returns.?? The service proxy may
>     accept or return other services, these services will have the same
>     constraints applied, unless clients or services, apply new
>     constraints.
>  8. A JVM node may have any number of services proxy's while also
>     providing services to other nodes, of many different identities,
>     numerous services may participate in transactions, each one with
>     it's own identity.
>
> During this process permissions are granted as they are required, once 
> a service is no longer used, its ClassLoader becomes unreachable, 
> permissions granted dynamically are removed.?? The client environment 
> is otherwise locked down with least privilege policy files, that were 
> generated and audited during deployment.
>
> We would like to continue to invest in the development of this 
> software, it's performant, it scales, encryption is very fast, thanks 
> to recent developments in Java session tickets.? We've eliminated 
> unnecessary DNS calls (the JVM makes many of these, eg URL, 
> SecureClassLoader, CodeSource), and cleared out synchronized and 
> blocking code, replaced it with concurrent non blocking code where 
> possible. ? It's well tested, much time has been invested into static 
> analysis and cleaning up and modernizing code.?? All our hotspots are 
> native JVM methods.?? I suspect this is why we are finding bugs in 
> your TLS code, it isn't thread safe ;)
>
> Hopefully there is a future for this software, however it will depend 
> our ability to migrate to new versions of Java as they're released.
>
> At least allow us just these few classes to remain (un-deprecated 
> please, so developers aren't motivated to remove their privileged 
> calls), even if they contain no implementation, so that we may 
> instrument them, as we attempt to stay current with OpenJDK.
>
> We are not asking OpenJDK to maintain OpenJDK security using an 
> authorization framework, we are just asking you to make it possible 
> for us to maintain our software's security ourselves while running on 
> your platform.? It's not really possible for us to run on anything else.
>
> -- 
> Regards,
>   
> Peter.
> On 9/02/2023 10:20 am, Peter Firmstone wrote:
>>
>> I don't think I'm really asking for much here.?? JEP411's plan will 
>> destroy our ability to manage user and service authorization in our 
>> existing software, at least cut us a little slack.? I wish we built 
>> our software on some other authorization API, unfortunately we didn't.
>>
>> We're just trying to migrate as best we can to future versions of Java.
>>
>> -- 
>> Regards,
>>   
>> Peter Firmstone
>> On 7/02/2023 12:53 pm, Peter Firmstone wrote:
>>>
>>> Hello OpenJDK folk,
>>>
>>> SecurityManager, AccessController and AccessControlContext will be 
>>> removed in a future version of Java.
>>>
>>> Just briefly: Our software is heavily dependant on Java's 
>>> Authorization framework, we use ProtectionDomain's to represent 
>>> remote services for authorization decisions.? We are working out how 
>>> to implement a new authorization framework after SecurityManager's 
>>> removal.
>>>
>>> Many libraries call AccessController#doPrivileged methods, when 
>>> these methods are removed, we're going to have a big problem with 
>>> viral permissions. ? Restricted authorization will become 
>>> meaningless if it has to be granted to all domains on a call stack.
>>>
>>> https://github.com/opensearch-project/OpenSearch/issues/1687
>>>
>>> Retaining methods in the platform that developers can instrument 
>>> will provide a common frame of reference for authorization 
>>> decisions, that's runtime backward non-breaking, without burdening 
>>> OpenJDK with maintenance.
>>>
>>> I'm requesting retaining the DomainController interface, 
>>> AccessController, AccessControlContext and Subject methods as 
>>> no-op's for instrumentation???? Please leave them deprecated as 
>>> no-op's, but not "deprecated for removal".
>>>
>>> https://github.com/pfirmstone/HighPerformanceSecurity
>>>
>>> Some thoughts:
>>>
>>>  1. Ability to disable finalizers in Java 18 onwards is important to
>>>     prevent finalizer attacks when instrumenting constructors to
>>>     throw a RuntimeException.
>>>  2. Guard#check methods can be no-op's for instrumentation.?? If I
>>>     can replace all instances of SecurityManager#checkPermission in
>>>     OpenJDK with Guard#check, I can contribute the patches, this
>>>     will assist greatly in the transition process of retaining
>>>     existing hooks, while developing replacements.
>>>  3. Reduce the size of the Java Platform's trusted computing base by
>>>     giving all system ProtectionDomain's a CodeSource with a
>>>     non-null meaningful URL.?? Unfortunately Java Serialization is
>>>     in the base module, so we cannot authorize it's use with a
>>>     permission check, as the base module needs AllPermission, it has
>>>     to be managed with serial filters
>>>     (https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
>>>     - perhaps someone will write a serialfilter generation tool that
>>>     works similarly to our POLP policy generation tool?).?
>>>     Privileges cannot be elevated by an authenticated Subject, when
>>>     all domains on the call stack are already privileged.? If
>>>     Serialization was in a different ProtectionDomain, then we could
>>>     prevent de-serialization for unauthenticated Subject's.??
>>>     Perhaps OpenJDK might consider moving Serialization into a
>>>     different module in future before it's eventual removal?
>>>  4. Instrument all data parsing methods with guard checks, eg XML.??
>>>     This allows authorization decisions to parse remote data based
>>>     on the Principal's of the remotely authenticated Subject, to
>>>     prevent injection attacks.
>>>  5. We already have principle of least privilege policy generation
>>>     tools and efficient policy checking tools for authorization in
>>>     place.?? These allow for simple policy file generation,
>>>     auditing, editing and deployment.
>>>
>>> -- 
>>> Regards,
>>>   
>>> Peter Firmstone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230210/89b4bd7d/attachment.htm>

From peter.firmstone at zeus.net.au  Fri Feb 10 04:01:01 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 10 Feb 2023 14:01:01 +1000
Subject: Surviving JEP411 deprecation [WAS]: Implementing an Authorization
 framework on Java.
In-Reply-To: <ebfeb6da-9ddd-bbd7-2527-d4da6df906fb@zeus.net.au>
References: <bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au>
 <6ff1e3d1-d55f-5d19-954e-4849981064ae@zeus.net.au>
 <50be4e5e-7150-0a0b-6612-9fe5c70f02fe@zeus.net.au>
 <ebfeb6da-9ddd-bbd7-2527-d4da6df906fb@zeus.net.au>
Message-ID: <63dfca6b-0d91-26b0-ec63-3fe4ebd047da@zeus.net.au>

People believed Java Serialization was secure for a long time, I had 
arguments about that too, long before it was public knowledge, until it 
wasn't, then it couldn't be fixed fast enough to keep up with 
vulnerabilities.

You nonchalantly plan to remove the SM infrastructure while blocking us 
from developing a new Authorization framework.?? It's vandalism.

So after 20 years of developing Java, it's come to this.

It leaves a bad taste in my mouth.

Old man yells at cloud!

On 10/02/2023 9:21 am, Peter Firmstone wrote:
>
> Please undeprecate DomainController interface, AccessController, 
> AccessControlContext and Subject methods, while removing the remaining 
> methods in JEP411.
>
> Just document that these methods don't do anything by default, and use 
> the null object pattern where appropriate.
>
> Deprecation is causing developers to remove code that we need, this is 
> undoing years of hard work, I'm appealing to you to minimise harm 
> where possible.
>
> eg: https://github.com/apache/lucene/issues/11801
>
> -- 
> Regards,
>   
> Peter
> On 10/02/2023 9:03 am, Peter Firmstone wrote:
>>
>> Maybe I had the wrong Subject?
>>
>> I'm still trying to figure out how to migrate before removal of 
>> deprecated API's.
>>
>>  1. Our software architecture is designed and currently relies on
>>     classes in JEP411 for authorisation decisions.
>>  2. It's not possible for our software to have security bolted on as
>>     an afterthought, following removal of authorization.
>>  3. Without authorization, we cannot allow the JVM to have access to
>>     sensitive information.
>>  4. We could place the JVM inside an isolated VM as suggested by
>>     JEP411 proponents, but we can no longer allow the JVM to have
>>     access to sensitive information.?? It is technically possible to
>>     do this, provided we accept we could no longer use encryption or
>>     authentication, as we cannot introduce sensitive information into
>>     the JVM, then we could use observability tools as a watchdog, to
>>     shutdown and restart the VM if it becomes compromised.?? However,
>>     that leaves us with very limited functionality.
>>
>> I realise that OpenJDK likely thinks this is BS, we can just safely 
>> remove SM, it's obsolete now right?
>>
>> The problem is, we don't fit the standard category of server 
>> programming, eg: once the JVM's warmed up, it no longer dynamically 
>> loads classes, hotspot has compiled them to native binary code; a 
>> server that fits the publish subscribe model, where it only need 
>> parse and validate incoming data from clients, and publish 
>> responses.? Server programming is OpenJDK's target market, we get 
>> that.?? Anything in the client space is frowned upon, we get that 
>> too, but we're not in the client space.?? Our clients are also servers.
>>
>> Our distributed service architecture provides dynamic discovery of 
>> services (globally over IPv6).?? We rely on Authentication, 
>> Encryption (Privacy) and Authorization. Clients of services are often 
>> required to download code dynamically, clients and services first 
>> discover and authenticate available service registrar's using an X500 
>> IPv6 multicast discovery process, with checksums to validate details 
>> required to establish a unicast connection.?? Unicast IPv6 TCP with 
>> Encryption is used to ensure that communications are private between 
>> authenticated connections while establishing connections to service 
>> registrar's.
>>
>> Nodes in the distributed network, aren't distinguished as servers and 
>> clients, a node that acts as a client will also provide services, 
>> even if it's just listening to an event service.?? All threads are 
>> run with authenticated client endpoint Subject's, and service 
>> responses with server Subject's, to allow the use of authenticated 
>> TLS connections.
>>
>> After nodes have discovered each other, the connection is established 
>> like so:
>>
>>  1. Authentication & Establish an Encrypted connection.
>>  2. The service provides the client with;? code signer certificates,
>>     if the service requires codebase download, or it may provide a
>>     security hash, used to validate files, it will also communicate a
>>     string that represents URL's from which code can be downloaded.?
>>     It will also communicate any permissions it requires.?? The
>>     client Subject is allowed to grant a restricted set of
>>     permissions.?? The client may elect to grant the requested
>>     permissions, if it has the privileges to do so.
>>  3. The client provisions a ClassLoader, that's a child of the
>>     ClassLoader that contains the Service's public API, the identity
>>     of this ClassLoader is determined by the CodeSource URI's as well
>>     as the Authenticated identity of the Service.?? The ClassLoader
>>     of the service proxy represents it's identity in authorization
>>     decisions at the client. Other service proxy's may use the same
>>     codebase URL's, but unless they have identical identity, cannot
>>     load their classes into another service proxy's ClassLoader.
>>  4. At this point, the client unmarshal's the service proxy's Object
>>     state into the ClassLoader, it doesn't use Java de-serialization
>>     to do this, just in case anyone is curious.
>>  5. Only ClassLoaders are responsible for Class resolution, codebase
>>     annotations are not used, neither is RMIClassLoader used to
>>     resolve classes.
>>  6. Now the client (and server) applies constraints to their service
>>     endpoints, placing restrictions on the level of encryption the
>>     service can use for network communications, or the Principal's
>>     the Subject that invokes the service must have.
>>  7. The client can now use the service, by passing parameters to the
>>     proxy's methods and accepting returns.?? The service proxy may
>>     accept or return other services, these services will have the
>>     same constraints applied, unless clients or services, apply new
>>     constraints.
>>  8. A JVM node may have any number of services proxy's while also
>>     providing services to other nodes, of many different identities,
>>     numerous services may participate in transactions, each one with
>>     it's own identity.
>>
>> During this process permissions are granted as they are required, 
>> once a service is no longer used, its ClassLoader becomes 
>> unreachable, permissions granted dynamically are removed.?? The 
>> client environment is otherwise locked down with least privilege 
>> policy files, that were generated and audited during deployment.
>>
>> We would like to continue to invest in the development of this 
>> software, it's performant, it scales, encryption is very fast, thanks 
>> to recent developments in Java session tickets. We've eliminated 
>> unnecessary DNS calls (the JVM makes many of these, eg URL, 
>> SecureClassLoader, CodeSource), and cleared out synchronized and 
>> blocking code, replaced it with concurrent non blocking code where 
>> possible. ? It's well tested, much time has been invested into static 
>> analysis and cleaning up and modernizing code.?? All our hotspots are 
>> native JVM methods.?? I suspect this is why we are finding bugs in 
>> your TLS code, it isn't thread safe ;)
>>
>> Hopefully there is a future for this software, however it will depend 
>> our ability to migrate to new versions of Java as they're released.
>>
>> At least allow us just these few classes to remain (un-deprecated 
>> please, so developers aren't motivated to remove their privileged 
>> calls), even if they contain no implementation, so that we may 
>> instrument them, as we attempt to stay current with OpenJDK.
>>
>> We are not asking OpenJDK to maintain OpenJDK security using an 
>> authorization framework, we are just asking you to make it possible 
>> for us to maintain our software's security ourselves while running on 
>> your platform.? It's not really possible for us to run on anything else.
>>
>> -- 
>> Regards,
>>   
>> Peter.
>> On 9/02/2023 10:20 am, Peter Firmstone wrote:
>>>
>>> I don't think I'm really asking for much here.?? JEP411's plan will 
>>> destroy our ability to manage user and service authorization in our 
>>> existing software, at least cut us a little slack.? I wish we built 
>>> our software on some other authorization API, unfortunately we didn't.
>>>
>>> We're just trying to migrate as best we can to future versions of Java.
>>>
>>> -- 
>>> Regards,
>>>   
>>> Peter Firmstone
>>> On 7/02/2023 12:53 pm, Peter Firmstone wrote:
>>>>
>>>> Hello OpenJDK folk,
>>>>
>>>> SecurityManager, AccessController and AccessControlContext will be 
>>>> removed in a future version of Java.
>>>>
>>>> Just briefly: Our software is heavily dependant on Java's 
>>>> Authorization framework, we use ProtectionDomain's to represent 
>>>> remote services for authorization decisions.? We are working out 
>>>> how to implement a new authorization framework after 
>>>> SecurityManager's removal.
>>>>
>>>> Many libraries call AccessController#doPrivileged methods, when 
>>>> these methods are removed, we're going to have a big problem with 
>>>> viral permissions. ? Restricted authorization will become 
>>>> meaningless if it has to be granted to all domains on a call stack.
>>>>
>>>> https://github.com/opensearch-project/OpenSearch/issues/1687
>>>>
>>>> Retaining methods in the platform that developers can instrument 
>>>> will provide a common frame of reference for authorization 
>>>> decisions, that's runtime backward non-breaking, without burdening 
>>>> OpenJDK with maintenance.
>>>>
>>>> I'm requesting retaining the DomainController interface, 
>>>> AccessController, AccessControlContext and Subject methods as 
>>>> no-op's for instrumentation???? Please leave them deprecated as 
>>>> no-op's, but not "deprecated for removal".
>>>>
>>>> https://github.com/pfirmstone/HighPerformanceSecurity
>>>>
>>>> Some thoughts:
>>>>
>>>>  1. Ability to disable finalizers in Java 18 onwards is important
>>>>     to prevent finalizer attacks when instrumenting constructors to
>>>>     throw a RuntimeException.
>>>>  2. Guard#check methods can be no-op's for instrumentation.?? If I
>>>>     can replace all instances of SecurityManager#checkPermission in
>>>>     OpenJDK with Guard#check, I can contribute the patches, this
>>>>     will assist greatly in the transition process of retaining
>>>>     existing hooks, while developing replacements.
>>>>  3. Reduce the size of the Java Platform's trusted computing base
>>>>     by giving all system ProtectionDomain's a CodeSource with a
>>>>     non-null meaningful URL. Unfortunately Java Serialization is in
>>>>     the base module, so we cannot authorize it's use with a
>>>>     permission check, as the base module needs AllPermission, it
>>>>     has to be managed with serial filters
>>>>     (https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
>>>>     - perhaps someone will write a serialfilter generation tool
>>>>     that works similarly to our POLP policy generation tool?).?
>>>>     Privileges cannot be elevated by an authenticated Subject, when
>>>>     all domains on the call stack are already privileged.? If
>>>>     Serialization was in a different ProtectionDomain, then we
>>>>     could prevent de-serialization for unauthenticated Subject's.
>>>>     Perhaps OpenJDK might consider moving Serialization into a
>>>>     different module in future before it's eventual removal?
>>>>  4. Instrument all data parsing methods with guard checks, eg
>>>>     XML.?? This allows authorization decisions to parse remote data
>>>>     based on the Principal's of the remotely authenticated Subject,
>>>>     to prevent injection attacks.
>>>>  5. We already have principle of least privilege policy generation
>>>>     tools and efficient policy checking tools for authorization in
>>>>     place.?? These allow for simple policy file generation,
>>>>     auditing, editing and deployment.
>>>>
>>>> -- 
>>>> Regards,
>>>>   
>>>> Peter Firmstone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230210/a1c639c9/attachment.htm>

From xuelei at openjdk.org  Fri Feb 10 22:05:28 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 10 Feb 2023 22:05:28 GMT
Subject: RFR: 8301700: Increase the default TLS Diffie-Hellman group size
 from 1024-bit to 2048-bit
In-Reply-To: <obyTgDGT6M_EeEtbJ-itXd-WkcOSuhhVj4xW35DKIUA=.f936a1d9-6444-45b0-b57a-84b32660128e@github.com>
References: <obyTgDGT6M_EeEtbJ-itXd-WkcOSuhhVj4xW35DKIUA=.f936a1d9-6444-45b0-b57a-84b32660128e@github.com>
Message-ID: <-WldIL9Cf2qJ7wBVtgk3RZ1nweletR269UFhP8vAuB0=.01613c69-9866-47ec-91b7-43018b6f4f04@github.com>

On Thu, 9 Feb 2023 20:59:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to increase the default Diffie-Hellman group size used in the key exchange method of TLS_DHE cipher suites from 1024-bit to 2048-bit. This issue does not affect TLS 1.3 as the minimum DH group size is 2048 bits..
> 
> See the CSR for more details on the rationale for this change and the expected compatibility risk (low).

Looks good to me.  And thanks for the word smithing.

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

Marked as reviewed by xuelei (Reviewer).

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


From peter.firmstone at zeus.net.au  Sun Feb 12 08:37:24 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 12 Feb 2023 18:37:24 +1000
Subject: Should JAAS be renamed to JAS?
Message-ID: <4a4fddb6-6e96-fbd7-c4ae-03b3ef94b2d6@zeus.net.au>

Should JAAS should be renamed JAS??? Java will no longer have support 
for Authorization functionality, so this should be named "Java 
Authentication Service" JAS right?

I'm currently working on a new Authorization framework for Java, it 
works a little differently.

https://github.com/pfirmstone/HighPerformanceSecurity

A flaw in Java's authorization implementation, was if SecurityManager 
was enabled, privileges were turned on by default.?? What do I mean?? An 
example may help:

For a developer to enable the use of a logged in Subject's Principal's, 
they had to ensure that a CodeSource wasn't granted those permissions.? 
Often policy files granted AllPermission to known CodeSources, so how 
could the developer easily restrict permissions to Subjects?

Another problem was the Runnable interface was created in Java 1.0, 
prior to the security infrastructure in Java 1.2, so while a Thread's 
AccessControlContext could be recorded at the time of it's creation, 
Runnable tasks didn't have their AccessControlContext recorded at their 
time of creation, it would have worked if they were abstract classes...

Instead Authorization::privilegedCall overloaded methods accept a 
Callable parameter.?? The Callable parameter is decorated, and when 
guards perform their checks, the stack walk only captures the domains on 
the stack, back to the decorator.?? The domain of the caller is also 
recorded and stored in the decorator.

Basically, when a privilegedCall is made, the caller is requesting to 
use the privileges it has.?? If no privileged call has been made, then 
no privileges are enabled, to reduce the attack surface area.

Additionally, another method Authorization::getSubjectAuthorization, 
returns an Authorization containing an unprivileged CodeSource domain, 
containing the Subject's principals, such that only the privileges of 
the Subject will be used to determine permissions.?? Developers will use 
this method for data parsing (XML, deserialization, query's and 
scripts), this ensures that the decision to parse data will depend on 
how trustworthy the source of that data is.

Additionally there are these two methods:

Authorization::privilegesOn and Authorization::privilegesOff

Library code with Executor's that cannot be wrapped, need a way to be 
granted privileges.

These methods allow activating privileges for domains.

How do these methods work?

If there are no privilegedCall's in a Thread's stack, but all domains on 
the stack have their privileges turned on, then it will be treated as a 
privilegedCall, allowing guard checks to proceed.

Another improvement is a significant reduction in the size of the 
trusted codebase:

 ??? ??? ??? ??? CodeSource cs = t.getCodeSource();
 ??????????????? if (cs == null){ // Bootstrap ClassLoader?
 ??????????????????? Module module = declaringClass.getModule();
 ??????????????????? if (module.isNamed()){
 ??????????????????????? try {
 ??????????????????????????? cs = new CodeSource( new URL("jrt:/" + 
module.getName()), (Certificate[]) null);
 ??????????????????????? } catch (MalformedURLException ex) {
Logger.getLogger(Authorization.class.getName()).log(Level.SEVERE, null, ex);
 ??????????????????????? }
 ??????????????????? }
 ??????????????? }

In JGDMS, we have a POLP policy file generation tool, so we will need to 
do something similar here.

In Java's API we will need to instrument network and file access, among 
other things.

There is of course the problem of capturing the intent of 
AccessController::doPrivileged methods in the Java platform and existing 
code, we would like to preserve as many of these call as possible, so 
that we can capture the developers original intent of performing a 
privileged call.

Q: Why capture AccessController::doPrivileged calls?

A: Viral Permissions, we need to minimise the sections of code that 
require privileges and to reduce the amount of code that requires 
auditing, to be more targeted.

Once the JVM is instrumented, guards can be changed, but we have no 
plans to allow security to be turned off, instead tools will be provided 
to generate least privilege policies.? Think of it like a recording 
mode, where we record everything privileged the software needs to do, 
then everything that isn't necessary is switched off.

-- 
Regards,
  
Peter



From xuelei at openjdk.org  Mon Feb 13 20:00:27 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 13 Feb 2023 20:00:27 GMT
Subject: RFR: 8301274: update for deprecated sprintf for security
 components
In-Reply-To: <WLBv946onPcZHfKQXUuXmhx2W6nEzx4ONMjGVbThuZs=.39a8463a-e826-4302-b1a0-be3bf322299a@github.com>
References: <WLBv946onPcZHfKQXUuXmhx2W6nEzx4ONMjGVbThuZs=.39a8463a-e826-4302-b1a0-be3bf322299a@github.com>
Message-ID: <cYl5LN_MO21ZaxaCAj-3e8H1mCFuPLFjqNpyWE4jSxs=.285958e2-4eb4-4839-be0d-c1c8b8071cfe@github.com>

On Fri, 27 Jan 2023 20:21:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in security components.

ping ...

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

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


From ascarpino at openjdk.org  Mon Feb 13 20:52:27 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 13 Feb 2023 20:52:27 GMT
Subject: RFR: 8301274: update for deprecated sprintf for security
 components
In-Reply-To: <WLBv946onPcZHfKQXUuXmhx2W6nEzx4ONMjGVbThuZs=.39a8463a-e826-4302-b1a0-be3bf322299a@github.com>
References: <WLBv946onPcZHfKQXUuXmhx2W6nEzx4ONMjGVbThuZs=.39a8463a-e826-4302-b1a0-be3bf322299a@github.com>
Message-ID: <_S0ByK-RZqJ34sQ-iOskMzVsn68FIxftteVWhaL2GOo=.83617d82-3ddb-4f32-830b-877ff2a77edd@github.com>

On Fri, 27 Jan 2023 20:21:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in security components.

look good to me

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

Marked as reviewed by ascarpino (Reviewer).

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


From lancea at openjdk.org  Mon Feb 13 21:25:38 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Feb 2023 21:25:38 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
Message-ID: <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>

On Thu, 9 Feb 2023 12:07:04 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental removal of UTF8ZipCoder.compare

Thank you Eirik for your efforts here.  I am running your latest changes through our internal Mach5 systems.

Additional comments below which are meant to add clarity for future maintainers

src/java.base/share/classes/java/util/zip/ZipCoder.java line 66:

> 64:         NO_MATCH
> 65:     }
> 66: 

Please add a comment indicating what the values mean

src/java.base/share/classes/java/util/zip/ZipCoder.java line 210:

> 208:      * is known and matches the charset of this ZipCoder.
> 209:      */
> 210:     Comparison compare(String str, byte[] b, int off, int len, boolean addSlash) {

If you could add an `@param` comments, that would be awesome ?

src/java.base/share/classes/java/util/zip/ZipFile.java line 1665:

> 1663:             }
> 1664:             // No exact match found, will return either slashMatch or -1
> 1665:             return slashMatch;

This gets a bit confusing as we return `pos` when we have an exact match so it would be helpful to had more clarity via additional comments(it might not have been clear with the previous comments but I think if we are going to add `slashMatch` we should take the time to beef up the comments

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:

> 88:             expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
> 89:     public void shouldRejectInvalidName() throws IOException {
> 90:         try (ZipFile zf = new ZipFile(invalidName.toFile())) {

If you could please convert to use `expectThrows` to get to validate the message name

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 127:

> 125:     }
> 126: 
> 127:     @Test

Please add a comment introducing the test

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 143:

> 141:         }
> 142:     }
> 143:     @Test(dataProvider = "all-charsets")

Please add a comment introducing the test

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 307:

> 305:                 ze.setCrc(crc.getValue());
> 306:             }
> 307:             ze.setTime(1675862371399L);

Please add a comment indicating what the time is

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

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


From duke at openjdk.org  Tue Feb 14 08:34:15 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:34:15 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v10]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <yROFGpFoZeG5UrTg-GozeIlF39x2ykhGBNwh_Y7Oz-s=.edc0f431-e20c-4b51-a9cc-f1c3c40547d3@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Improve documentation of ZipCoder.compare and the Comparison enum values. Describe rationale for the tests added to TestZipFileEncodings. Revert unintended change in setTime in TestZipFileEncodings. Rename Comparison.SLASH_MATCH to DIRECTORY_MATCH.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/d94cbe38..a633d270

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

  Stats: 98 lines in 3 files changed: 68 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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


From duke at openjdk.org  Tue Feb 14 08:45:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:45:47 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v10]
In-Reply-To: <yROFGpFoZeG5UrTg-GozeIlF39x2ykhGBNwh_Y7Oz-s=.edc0f431-e20c-4b51-a9cc-f1c3c40547d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <yROFGpFoZeG5UrTg-GozeIlF39x2ykhGBNwh_Y7Oz-s=.edc0f431-e20c-4b51-a9cc-f1c3c40547d3@github.com>
Message-ID: <bH2CPdJ6FKxAoMG4pf05RqRqx1_NeJIzFLc1aEmjh0w=.95ac32d9-65a6-41e0-a247-d28ae1b7a384@github.com>

On Tue, 14 Feb 2023 08:34:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve documentation of ZipCoder.compare and the Comparison enum values. Describe rationale for the tests added to TestZipFileEncodings. Revert unintended change in setTime in TestZipFileEncodings. Rename Comparison.SLASH_MATCH to DIRECTORY_MATCH.

Thanks for your thorough and helpful review, Lance.

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

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


From duke at openjdk.org  Tue Feb 14 08:45:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:45:55 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
Message-ID: <I2uk-mq607dC7enbmnLPjtnv8dIo6ibbKcPnhijlS0M=.e1cbbdda-c8ac-4ad8-bc41-2a3398e95d82@github.com>

On Mon, 13 Feb 2023 20:00:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental removal of UTF8ZipCoder.compare
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 66:
> 
>> 64:         NO_MATCH
>> 65:     }
>> 66: 
> 
> Please add a comment indicating what the values mean

I added comments to the enum and each of the values.

> src/java.base/share/classes/java/util/zip/ZipCoder.java line 210:
> 
>> 208:      * is known and matches the charset of this ZipCoder.
>> 209:      */
>> 210:     Comparison compare(String str, byte[] b, int off, int len, boolean addSlash) {
> 
> If you could add an `@param` comments, that would be awesome ?

I improved the Javadoc of this method and added `@param` comments.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1665:
> 
>> 1663:             }
>> 1664:             // No exact match found, will return either slashMatch or -1
>> 1665:             return slashMatch;
> 
> This gets a bit confusing as we return `pos` when we have an exact match so it would be helpful to had more clarity via additional comments(it might not have been clear with the previous comments but I think if we are going to add `slashMatch` we should take the time to beef up the comments

The dual-modality of this method certainly allows for some head-scratch trying to find a succinct way to describe its logic. I have made an attempt to improve it, but I'm sure it could be even better.

The `slashPos` name was probably ok as a local variable, but now that it is part of the contract of ZipCoder.compare, I think it helps to rename the enum value to `DIRECTORY_NAME` and update `slashPos` to `dirPos` accordingly. 

Do you have any suggestions on how to improve the comments in the last version?

> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 127:
> 
>> 125:     }
>> 126: 
>> 127:     @Test
> 
> Please add a comment introducing the test

I described the rationale of adding this test in a comment.

> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 143:
> 
>> 141:         }
>> 142:     }
>> 143:     @Test(dataProvider = "all-charsets")
> 
> Please add a comment introducing the test

I described the rationale of adding this test in a comment.

> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 307:
> 
>> 305:                 ze.setCrc(crc.getValue());
>> 306:             }
>> 307:             ze.setTime(1675862371399L);
> 
> Please add a comment indicating what the time is

This change was accidentaly introduced, I have reverted it. Good catch.

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

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


From duke at openjdk.org  Tue Feb 14 08:49:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:49:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
Message-ID: <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>

On Mon, 13 Feb 2023 20:20:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental removal of UTF8ZipCoder.compare
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:
> 
>> 88:             expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
>> 89:     public void shouldRejectInvalidName() throws IOException {
>> 90:         try (ZipFile zf = new ZipFile(invalidName.toFile())) {
> 
> If you could please convert to use `expectThrows` to get to validate the message name

The message is already validated using `expectedExceptionsMessageRegExp` in the `@Test` annotation.

Would you prefer if I use expectThrows instead, or perhaps inline the `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?

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

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


From duke at openjdk.org  Tue Feb 14 09:01:12 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 09:01:12 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v11]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <lm-RQtUTEAXqTk0NgaY1RkxhdbtL9WPsqIojyRS6-w0=.23038e9e-eadd-42c3-911e-ec858e168e16@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Remove accidentally introduced trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/a633d270..21cdb732

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

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

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


From lancea at openjdk.org  Tue Feb 14 11:24:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 14 Feb 2023 11:24:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
 <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>
Message-ID: <hT1xmxAHP7Rg53Tf_XhCABe-gNiaE2CaqoTwYSAAsZw=.fe11d665-0206-4457-8c64-2665e388219c@github.com>

On Tue, 14 Feb 2023 08:47:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:
>> 
>>> 88:             expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
>>> 89:     public void shouldRejectInvalidName() throws IOException {
>>> 90:         try (ZipFile zf = new ZipFile(invalidName.toFile())) {
>> 
>> If you could please convert to use `expectThrows` to get to validate the message name
>
> The message is already validated using `expectedExceptionsMessageRegExp` in the `@Test` annotation.
> 
> Would you prefer if I use expectThrows instead, or perhaps inline the `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?

Sorry if this was not clear,  we have gone away from using the annotation element `exepectedExceptions` for new and updated tests and  have tried to standardize on `assertThrows` and  `expectThrows` instead which is the basis for my suggestion.


Thank you for your other updates.  I will go through them later today

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

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


From duke at openjdk.org  Tue Feb 14 11:49:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 11:49:23 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Prefer expectThrows with asserts over test annotation regex

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/21cdb732..4981abd3

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

  Stats: 18 lines in 1 file changed: 7 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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


From duke at openjdk.org  Tue Feb 14 12:24:39 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 14 Feb 2023 12:24:39 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
Message-ID: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>

* Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
* Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
* Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

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

Commit messages:
 - fixed compilation errors
 - Merge branch 'master' into templates
 - 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates

Changes: https://git.openjdk.org/jdk/pull/12555/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284047
  Stats: 3704 lines in 26 files changed: 931 ins; 2467 del; 306 mod
  Patch: https://git.openjdk.org/jdk/pull/12555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12555/head:pull/12555

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


From xuelei at openjdk.org  Tue Feb 14 15:41:38 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 14 Feb 2023 15:41:38 GMT
Subject: Integrated: 8301274: update for deprecated sprintf for security
 components
In-Reply-To: <WLBv946onPcZHfKQXUuXmhx2W6nEzx4ONMjGVbThuZs=.39a8463a-e826-4302-b1a0-be3bf322299a@github.com>
References: <WLBv946onPcZHfKQXUuXmhx2W6nEzx4ONMjGVbThuZs=.39a8463a-e826-4302-b1a0-be3bf322299a@github.com>
Message-ID: <vGtsjFaLP4jeX9K5Ryw6exMVX0nX9MrbqXq7rkSX5BE=.37927b02-cf66-4a71-b81c-2812c7465bc5@github.com>

On Fri, 27 Jan 2023 20:21:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in security components.

This pull request has now been integrated.

Changeset: f7dee77d
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7dee77d734fdfca29ebf8b8602e1bf04324d44c
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8301274: update for deprecated sprintf for security components

Reviewed-by: ascarpino

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

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


From duke at openjdk.org  Tue Feb 14 23:13:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 23:13:45 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <hT1xmxAHP7Rg53Tf_XhCABe-gNiaE2CaqoTwYSAAsZw=.fe11d665-0206-4457-8c64-2665e388219c@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
 <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>
 <hT1xmxAHP7Rg53Tf_XhCABe-gNiaE2CaqoTwYSAAsZw=.fe11d665-0206-4457-8c64-2665e388219c@github.com>
Message-ID: <OW9pogQH8RHKn0yMHvpI6xgaXM_RZQ0aHS76kiCLvJA=.c0ef684d-433f-4cc7-88c5-7aa9061a3ca7@github.com>

On Tue, 14 Feb 2023 11:21:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> The message is already validated using `expectedExceptionsMessageRegExp` in the `@Test` annotation.
>> 
>> Would you prefer if I use expectThrows instead, or perhaps inline the `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?
>
> Sorry if this was not clear,  we have gone away from using the annotation element `exepectedExceptions` for new and updated tests and  have tried to standardize on `assertThrows` and  `expectThrows` instead which is the basis for my suggestion.
> 
> 
> Thank you for your other updates.  I will go through them later today

No worries, this makes sense. Updated to expectThrows with assertEquals.

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

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


From lancea at openjdk.org  Tue Feb 14 23:21:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 14 Feb 2023 23:21:45 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
Message-ID: <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>

On Tue, 14 Feb 2023 11:49:23 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefer expectThrows with asserts over test annotation regex

Thank you Eirik,  it looks much better.

I will kick off another run tomorrow and make another  pass as it has been a long day  :-)

Thank you again for your work here to improve the Zip code base

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 91:

> 89:     public void shouldRejectInvalidName() throws IOException {
> 90:         ZipException ex = expectThrows(ZipException.class, () -> {
> 91:             openZipFile(invalidName);

You could just do


ZipException ex = expectThrows(ZipException.class, () -> {
             new ZipFile(invalidName.toFile())
});

versus adding _openZipFile()_

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

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


From valeriep at openjdk.org  Wed Feb 15 02:31:29 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Feb 2023 02:31:29 GMT
Subject: RFR: 8302225: SunJCE Provider doesn't validate key sizes when using
 'constrained' transforms for AES/KW and AES/KWP
Message-ID: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>

Due to an error in the existing regression test, this bug remain undiscovered until now. Added the key size check to the KeyWrapCipher class and fixed the regression test.

Please help review this trivial fix.

Thanks in advance,
Valerie

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

Commit messages:
 - 8302225: SunJCE Provider doesn't validate key sizes when using 'constrained' transforms for AES/KW and AES/KWP

Changes: https://git.openjdk.org/jdk/pull/12569/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12569&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302225
  Stats: 29 lines in 2 files changed: 23 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12569.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12569/head:pull/12569

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


From xuelei at openjdk.org  Wed Feb 15 05:33:42 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 15 Feb 2023 05:33:42 GMT
Subject: RFR: 8302225: SunJCE Provider doesn't validate key sizes when
 using 'constrained' transforms for AES/KW and AES/KWP
In-Reply-To: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
References: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
Message-ID: <7aU846nhtY_pMlhLFQaYRfOxVB7Fl1KFSr8MCnHm5i8=.7cea5475-3318-474e-9ca9-85c7b10861b8@github.com>

On Wed, 15 Feb 2023 02:23:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Due to an error in the existing regression test, this bug remain undiscovered until now. Added the key size check to the KeyWrapCipher class and fixed the regression test.
> 
> Please help review this trivial fix.
> 
> Thanks in advance,
> Valerie

src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 302:

> 300:         if (fixedKeySize != -1 && fixedKeySize != keyBytes.length) {
> 301:             throw new InvalidKeyException("Invalid key length: " +
> 302:                     keyBytes.length + " bytes, should be " + fixedKeySize);

Is it necessary to check that the key algorithm is "AES", and the size is a valid AES key size, as the code in engineGetKeySize()?

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

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


From duke at openjdk.org  Wed Feb 15 09:55:36 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 09:55:36 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v13]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <m_QdbKFg_P5Xau4LSMHbYmd3MHF8vi8VbJCRmO2Zml4=.afba0ee0-10b2-471f-913e-c203f49c336e@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Inline openZipFile and remove TwR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/4981abd3..49ad8d35

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

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

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


From duke at openjdk.org  Wed Feb 15 09:57:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 09:57:55 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
 <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
Message-ID: <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>

On Tue, 14 Feb 2023 23:12:38 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prefer expectThrows with asserts over test annotation regex
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 91:
> 
>> 89:     public void shouldRejectInvalidName() throws IOException {
>> 90:         ZipException ex = expectThrows(ZipException.class, () -> {
>> 91:             openZipFile(invalidName);
> 
> You could just do
> 
> 
> ZipException ex = expectThrows(ZipException.class, () -> {
>              new ZipFile(invalidName.toFile())
> });
> 
> versus adding _openZipFile()_

The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.

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

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


From duke at openjdk.org  Wed Feb 15 10:13:51 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 10:13:51 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v14]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <aUBsP2Q6WMHpdopp7xIcdJW0OlR2CW8vUru8rM4Yw-s=.34631bad-8389-4892-b9aa-831f7ec80dab@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Update javadocs for ZipCoder.Comparison to first clarify that the "encoded string" refers to those found in the CEN byte array and to use the term "the encoded string" instead of the more convoluted "the string encoded in the byte array".

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/49ad8d35..9b83002a

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

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

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


From lancea at openjdk.org  Wed Feb 15 11:35:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Feb 2023 11:35:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
 <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
 <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>
Message-ID: <ctLS4d0pc7vDoM_iTDNcTjjfJ-u2hS9_nRcWRwJC32c=.5e2e8486-233a-44c2-90ae-f461a485b1b4@github.com>

On Wed, 15 Feb 2023 09:55:04 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.

Agree, thanks for addressing the suggestion as it makes the test cleaner given expects/assertThrows should  react to the Exception being thrown by `new ZipFile(...)`

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

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


From duke at openjdk.org  Wed Feb 15 11:44:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 11:44:17 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v15]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

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

  Fix a regression where the invalidName was tested instead of comment in the invalid comment test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/9b83002a..08160a1a

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

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

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


From duke at openjdk.org  Wed Feb 15 11:44:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 11:44:17 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <ctLS4d0pc7vDoM_iTDNcTjjfJ-u2hS9_nRcWRwJC32c=.5e2e8486-233a-44c2-90ae-f461a485b1b4@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
 <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
 <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>
 <ctLS4d0pc7vDoM_iTDNcTjjfJ-u2hS9_nRcWRwJC32c=.5e2e8486-233a-44c2-90ae-f461a485b1b4@github.com>
Message-ID: <e49_4WJW4mV6ydPudH6DeMvcuUCBAUNFSYlJM77COWo=.5bfbf250-bfa6-45e5-943b-cf684d8359a2@github.com>

On Wed, 15 Feb 2023 11:32:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.
>
>> The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.
> 
> Agree, thanks for addressing the suggestion as it makes the test cleaner given expects/assertThrows should  react to the Exception being thrown by `new ZipFile(...)`

My inlining accidentally made the shouldRejectInvalidComment test the invalid name file. Fixed with last commit.

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

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


From mullan at openjdk.org  Wed Feb 15 13:28:56 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Feb 2023 13:28:56 GMT
Subject: Integrated: 8301700: Increase the default TLS Diffie-Hellman group
 size from 1024-bit to 2048-bit
In-Reply-To: <obyTgDGT6M_EeEtbJ-itXd-WkcOSuhhVj4xW35DKIUA=.f936a1d9-6444-45b0-b57a-84b32660128e@github.com>
References: <obyTgDGT6M_EeEtbJ-itXd-WkcOSuhhVj4xW35DKIUA=.f936a1d9-6444-45b0-b57a-84b32660128e@github.com>
Message-ID: <3UMra-MOFE4pEydNvEvrWMAwIwZ3qJvNKDHhgzx-gdA=.c71da495-31d1-42af-b2f2-c697146e105e@github.com>

On Thu, 9 Feb 2023 20:59:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to increase the default Diffie-Hellman group size used in the key exchange method of TLS_DHE cipher suites from 1024-bit to 2048-bit. This issue does not affect TLS 1.3 as the minimum DH group size is 2048 bits..
> 
> See the CSR for more details on the rationale for this change and the expected compatibility risk (low).

This pull request has now been integrated.

Changeset: 26b111d7
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26b111d714c3ee62bd10a5e2ab44be01c13ff42e
Stats:     30 lines in 2 files changed: 1 ins; 10 del; 19 mod

8301700: Increase the default TLS Diffie-Hellman group size from 1024-bit to 2048-bit

Reviewed-by: xuelei

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

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


From mbaesken at openjdk.org  Wed Feb 15 15:03:30 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 15 Feb 2023 15:03:30 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v2]
In-Reply-To: <sNUc88AeQVDSFN6TsgXDWtmVpv5otYGt6CwaxZURPww=.e3134c2e-03d8-4b14-b631-89e807d99972@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <sNUc88AeQVDSFN6TsgXDWtmVpv5otYGt6CwaxZURPww=.e3134c2e-03d8-4b14-b631-89e807d99972@github.com>
Message-ID: <p3SpEgmI7PpDg_Dc0xz74Ig3BEk9egJba8cxvPjqJnY=.ec6bf904-1333-4f06-9f89-20df8e693cc5@github.com>

On Mon, 30 Jan 2023 12:26:57 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299817: Update copyright

Hi Lutz, is the  JIT_TIMER  still needed ?

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

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


From valeriep at openjdk.org  Wed Feb 15 20:30:30 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Feb 2023 20:30:30 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 165:

> 163:                 getInfo();
> 164:                 this.version.major = pInfo.cryptokiVersion.major;
> 165:                 this.version.minor = pInfo.cryptokiVersion.minor;

Now that you added getInfo(), then the C_GetInfo() could be made private, so that all callers can just leverage getInfo(), right?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java line 1192:

> 1190:                                         /* (CKM_NSS + 31) */ = 0xCE53436FL;
> 1191:     public static final long  CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN
> 1192:                                         /* (CKM_NSS + 32) */ = 0xCE534370L;

For user-friendly sake, now that you added these mechanisms, you should add the string name mapping for these native NSS mechanisms into the sun.security.pkcs11.wrapper.Functions class through its addMech(long, String) method.

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

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


From valeriep at openjdk.org  Thu Feb 16 00:29:13 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Feb 2023 00:29:13 GMT
Subject: RFR: 8302225: SunJCE Provider doesn't validate key sizes when
 using 'constrained' transforms for AES/KW and AES/KWP
In-Reply-To: <7aU846nhtY_pMlhLFQaYRfOxVB7Fl1KFSr8MCnHm5i8=.7cea5475-3318-474e-9ca9-85c7b10861b8@github.com>
References: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
 <7aU846nhtY_pMlhLFQaYRfOxVB7Fl1KFSr8MCnHm5i8=.7cea5475-3318-474e-9ca9-85c7b10861b8@github.com>
Message-ID: <zwa7dwIo3JcsRsVw_eVcCQFRFVOvTylVlfCYQOm56Ho=.2c7faa6e-ee32-429e-9c46-c83907c9e5ff@github.com>

On Wed, 15 Feb 2023 05:30:06 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Due to an error in the existing regression test, this bug remain undiscovered until now. Added the key size check to the KeyWrapCipher class and fixed the regression test.
>> 
>> Please help review this trivial fix.
>> 
>> Thanks in advance,
>> Valerie
>
> src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 302:
> 
>> 300:         if (fixedKeySize != -1 && fixedKeySize != keyBytes.length) {
>> 301:             throw new InvalidKeyException("Invalid key length: " +
>> 302:                     keyBytes.length + " bytes, should be " + fixedKeySize);
> 
> Is it necessary to check that the key algorithm is "AES", and the size is a valid AES key size, as the code in engineGetKeySize()?

Makes sense to have a consistent check, I will refactor it. Thanks for the comment~

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

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


From valeriep at openjdk.org  Thu Feb 16 01:30:49 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Feb 2023 01:30:49 GMT
Subject: RFR: 8302225: SunJCE Provider doesn't validate key sizes when
 using 'constrained' transforms for AES/KW and AES/KWP [v2]
In-Reply-To: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
References: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
Message-ID: <iSEfs8oBtN0wrZBIMLhl-nznr3kwQVZhI-WA6fnyYYY=.da7d07ad-ca4f-4da1-b2ee-08d603add5fc@github.com>

> Due to an error in the existing regression test, this bug remain undiscovered until now. Added the key size check to the KeyWrapCipher class and fixed the regression test.
> 
> Please help review this trivial fix.
> 
> Thanks in advance,
> Valerie

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

  Refactor to address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12569/files
  - new: https://git.openjdk.org/jdk/pull/12569/files/e3ba3672..38851051

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

  Stats: 42 lines in 1 file changed: 19 ins; 18 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12569.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12569/head:pull/12569

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


From xuelei at openjdk.org  Thu Feb 16 04:40:58 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 16 Feb 2023 04:40:58 GMT
Subject: RFR: 8302225: SunJCE Provider doesn't validate key sizes when
 using 'constrained' transforms for AES/KW and AES/KWP [v2]
In-Reply-To: <iSEfs8oBtN0wrZBIMLhl-nznr3kwQVZhI-WA6fnyYYY=.da7d07ad-ca4f-4da1-b2ee-08d603add5fc@github.com>
References: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
 <iSEfs8oBtN0wrZBIMLhl-nznr3kwQVZhI-WA6fnyYYY=.da7d07ad-ca4f-4da1-b2ee-08d603add5fc@github.com>
Message-ID: <g82FhgMaf4Q0wGytYUWzicc0AnTEg1DILqzlLCs03VA=.6885ea07-0cee-46c6-b979-2ccd526324a0@github.com>

On Thu, 16 Feb 2023 01:30:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Due to an error in the existing regression test, this bug remain undiscovered until now. Added the key size check to the KeyWrapCipher class and fixed the regression test.
>> 
>> Please help review this trivial fix.
>> 
>> Thanks in advance,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to address review comments

Looks good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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


From mbalao at openjdk.org  Thu Feb 16 04:55:27 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 16 Feb 2023 04:55:27 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>
Message-ID: <REUAryBRGClxDoF4-W8hldJ0eSJCaOH4zr9GLPUXuk4=.342b8185-23a4-4cf0-9d95-93ea0e98dae3@github.com>

On Wed, 15 Feb 2023 19:35:07 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 165:
> 
>> 163:                 getInfo();
>> 164:                 this.version.major = pInfo.cryptokiVersion.major;
>> 165:                 this.version.minor = pInfo.cryptokiVersion.minor;
> 
> Now that you added getInfo(), then the C_GetInfo() could be made private, so that all callers can just leverage getInfo(), right?

Right! We will make C_GetInfo private and delete the overload in SynchronizedPKCS11 for the next iteration.

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

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


From christoph.langer at sap.com  Thu Feb 16 07:54:47 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 16 Feb 2023 07:54:47 +0000
Subject: Update Public Suffix list?
Message-ID: <DB6PR0202MB2694561DEA85F9369409BA758AA09@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Hi,

the last update to the public suffix list happened about a year ago with JDK-8255266 [0]. Are there plans for a next update?

Thanks
Christoph

[0] https://bugs.openjdk.org/browse/JDK-8255266

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230216/d9670af8/attachment.htm>

From mbaesken at openjdk.org  Thu Feb 16 08:30:32 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Feb 2023 08:30:32 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v2]
In-Reply-To: <sNUc88AeQVDSFN6TsgXDWtmVpv5otYGt6CwaxZURPww=.e3134c2e-03d8-4b14-b631-89e807d99972@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <sNUc88AeQVDSFN6TsgXDWtmVpv5otYGt6CwaxZURPww=.e3134c2e-03d8-4b14-b631-89e807d99972@github.com>
Message-ID: <W2r5HUT7BhZiw4AZ0rTD1MFiXO75gQLgxFePKM1SUEU=.7ff21258-8226-48a8-b6a4-fa0d166ab745@github.com>

On Mon, 30 Jan 2023 12:26:57 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299817: Update copyright

Some small typos found 

nesessary  ->  necessary
sace extended SP ->  save extended SP

Why do you clear memory only in the ASSERT case here ?

src/hotspot/cpu/s390/stubGenerator_s390.cpp

#ifdef ASSERT
    __ clear_mem(Address(Z_SP, (intptr_t)8), resize_len - 8);
#endif

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

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


From jpai at openjdk.org  Thu Feb 16 10:52:21 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 Feb 2023 10:52:21 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar
Message-ID: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>

Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.

As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.

On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):


JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total


JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 

No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.

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

Commit messages:
 - 8302623: jarsigner - use BufferedOutputStream to improve performance while creating the signed jar

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

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


From lucy at openjdk.org  Thu Feb 16 11:51:59 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 16 Feb 2023 11:51:59 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v3]
In-Reply-To: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
Message-ID: <ysYJXc0EMUKqp7YiKZSzYbUQv0112U1qR2kpUdcYlpA=.8d801a81-0cc6-438d-b5d6-26fdaa7ad7bb@github.com>

> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
> 
> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
> 
> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
> 
> **Reviews and comments are very much appreciated.**
> 
> @backwaterred could you please run some "official" s390 tests? Thanks.

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

  829817: fixed typos, removed JIT_TIMER references

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11967/files
  - new: https://git.openjdk.org/jdk/pull/11967/files/33722f27..ca40de84

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

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

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


From mbaesken at openjdk.org  Thu Feb 16 11:56:30 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Feb 2023 11:56:30 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v3]
In-Reply-To: <ysYJXc0EMUKqp7YiKZSzYbUQv0112U1qR2kpUdcYlpA=.8d801a81-0cc6-438d-b5d6-26fdaa7ad7bb@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <ysYJXc0EMUKqp7YiKZSzYbUQv0112U1qR2kpUdcYlpA=.8d801a81-0cc6-438d-b5d6-26fdaa7ad7bb@github.com>
Message-ID: <m_VlXxrPS_1CfPORwzCJba5VJNpdOHxFx0Y4h7ivPZM=.f90b31af-e30b-4718-a395-9a2a21a5a6c5@github.com>

On Thu, 16 Feb 2023 11:51:59 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   829817: fixed typos, removed JIT_TIMER references

Marked as reviewed by mbaesken (Reviewer).

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

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


From lucy at openjdk.org  Thu Feb 16 11:56:31 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 16 Feb 2023 11:56:31 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v2]
In-Reply-To: <sNUc88AeQVDSFN6TsgXDWtmVpv5otYGt6CwaxZURPww=.e3134c2e-03d8-4b14-b631-89e807d99972@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <sNUc88AeQVDSFN6TsgXDWtmVpv5otYGt6CwaxZURPww=.e3134c2e-03d8-4b14-b631-89e807d99972@github.com>
Message-ID: <jZuJ5A3V_ErhXsBooJQGOk6OJrjnUYHzPDhzhoNifmk=.24c3c810-b9e9-4282-90ce-903c658d1126@github.com>

On Mon, 30 Jan 2023 12:26:57 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299817: Update copyright

Typos repaired, JIT_TIMER references removed.
The allocated stack space is cleared for debugging purposes only.
Thanks for having a look, @MBaesken

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

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


From jpai at openjdk.org  Thu Feb 16 14:55:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 Feb 2023 14:55:10 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v2]
In-Reply-To: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
Message-ID: <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>

> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
> 
> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
> 
> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
> 
> 
> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
> 
> 
> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
> 
> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.

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

 - merge latest from master branch
 - 8302623: jarsigner - use BufferedOutputStream to improve performance while creating the signed jar

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12588/files
  - new: https://git.openjdk.org/jdk/pull/12588/files/487afe26..fcb7ee45

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

  Stats: 512 lines in 22 files changed: 213 ins; 258 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/12588.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12588/head:pull/12588

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


From sean.mullan at oracle.com  Thu Feb 16 15:56:47 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 16 Feb 2023 10:56:47 -0500
Subject: Update Public Suffix list?
In-Reply-To: <DB6PR0202MB2694561DEA85F9369409BA758AA09@DB6PR0202MB2694.eurprd02.prod.outlook.com>
References: <DB6PR0202MB2694561DEA85F9369409BA758AA09@DB6PR0202MB2694.eurprd02.prod.outlook.com>
Message-ID: <98f396cd-07a7-faf3-9482-957cf6d3288c@oracle.com>

Hi Christoph,

It's too late for JDK 20, but we will be looking into updating it for 
JDK 21 [1].

--Sean

[1] https://bugs.openjdk.org/browse/JDK-8302182

On 2/16/23 2:54 AM, Langer, Christoph wrote:
> Hi,
> 
> the last update to the public suffix list happened about a year ago with 
> JDK-8255266 [0]. Are there plans for a next update?
> 
> Thanks
> 
> Christoph
> 
> [0] https://bugs.openjdk.org/browse/JDK-8255266 
> <https://bugs.openjdk.org/browse/JDK-8255266>
> 


From lancea at openjdk.org  Thu Feb 16 18:05:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 16 Feb 2023 18:05:35 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v15]
In-Reply-To: <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
Message-ID: <43GNnUEnJ94Y37Gj0M4EGqG3nZbZ7WNI_rRKndcEFCM=.a9c77260-c719-4a0d-8c6f-7162551d05a1@github.com>

On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a regression where the invalidName was tested instead of comment in the invalid comment test

As soon as my last set of Mach5 runs complete I will approve this change.  The JCK tests in this area also look good.

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

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


From rhalade at openjdk.org  Thu Feb 16 18:29:28 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 16 Feb 2023 18:29:28 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <iteDOzNcx5U4qlRx_z1jrxk9ZxH_eZLJyWCyOpv_4SA=.5c33a552-3d78-409d-b8fd-6700fd451bc4@github.com>

On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java line 2:

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

Can you please check test `sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java` as this template test was a copy of it? Suggest you to check if this template copy can be removed now as we have other template classes for SSLSocket/SSLEngine client and server.

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

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


From rhalade at openjdk.org  Thu Feb 16 18:34:28 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 16 Feb 2023 18:34:28 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <gkzeT1xHwkU5FRYfes9v_JkrFTD8zMaozE-XOfv9jYQ=.ac173945-017f-468f-a333-9edba82151ab@github.com>

On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 31:

> 29:  * @bug 8051498 8145849 8158978 8170282
> 30:  * @summary JEP 244: TLS Application-Layer Protocol Negotiation Extension
> 31:  * @compile MyX509ExtendedKeyManager.java

Suggest you to delete file `MyX509ExtendedKeyManager.java` if it is not needed anymore.

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

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


From rhalade at openjdk.org  Thu Feb 16 18:40:31 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 16 Feb 2023 18:40:31 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <MCzjMgb6rSjgvcccR5DU9NBgNVTXJZ4eKnH5shHqy9A=.3d5435e6-928f-440c-a69d-dbad5a2cade0@github.com>

On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

test/jdk/javax/net/ssl/TLSCommon/TLSWithEdDSA.java line 266:

> 264:      */
> 265:     @Override
> 266:     public SSLContext createClientSSLContext() throws Exception {

Why is this change needed, may be unintentional?

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

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


From rhalade at openjdk.org  Thu Feb 16 18:44:29 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 16 Feb 2023 18:44:29 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <picZF3BW8ka23zdUi7fbCB97zcM03K3zD2yDcw0KFsU=.19ac056e-b0c6-4ecd-bcb7-e348f7edc556@github.com>

On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

test/jdk/javax/net/ssl/templates/SSLContextTemplate.java line 395:

> 393:         CA_RSA_512( // for DisabledShortRSAKeys test
> 394:                 "RSA",
> 395:                 "-----BEGIN CERTIFICATE-----\n" +

Please add a comment with validity and algorithms similar to other entries in this enum. There are few other entries to update as well.

test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 111:

> 109: 
> 110:     @Override
> 111:     public SSLContext createServerSSLContext() throws Exception {

revert this as well.

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

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


From rhalade at openjdk.org  Thu Feb 16 19:02:28 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 16 Feb 2023 19:02:28 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <FZ76lJLMbHMhhaZJpKyOaY4rhW3f1XHJDoF8n3akogg=.bf350c8c-ad6d-4f7e-9676-17bd391514e2@github.com>

On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

test/jdk/sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS13.java line 2:

> 1: /*
> 2:  * Copyright (C) 2021, 2023 THL A29 Limited, a Tencent company. All rights reserved.

Missing comma and this is not Oracle copyright so I am not sure if it should be modified.

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

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


From rhalade at openjdk.org  Thu Feb 16 19:02:29 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 16 Feb 2023 19:02:29 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <FZ76lJLMbHMhhaZJpKyOaY4rhW3f1XHJDoF8n3akogg=.bf350c8c-ad6d-4f7e-9676-17bd391514e2@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <FZ76lJLMbHMhhaZJpKyOaY4rhW3f1XHJDoF8n3akogg=.bf350c8c-ad6d-4f7e-9676-17bd391514e2@github.com>
Message-ID: <Iu-fOmpSyy4g4eMgUXHRqTphYxcyO5e_aaGM6-c5S-o=.d3fbef32-ba6d-4f86-ac58-f9ccebc130de@github.com>

On Thu, 16 Feb 2023 18:57:26 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
>> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
>> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.
>
> test/jdk/sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS13.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (C) 2021, 2023 THL A29 Limited, a Tencent company. All rights reserved.
> 
> Missing comma and this is not Oracle copyright so I am not sure if it should be modified.

May be you can revert this file, change is unintentional.

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

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


From valeriep at openjdk.org  Thu Feb 16 23:16:55 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Feb 2023 23:16:55 GMT
Subject: RFR: 8302225: SunJCE Provider doesn't validate key sizes when
 using 'constrained' transforms for AES/KW and AES/KWP [v2]
In-Reply-To: <g82FhgMaf4Q0wGytYUWzicc0AnTEg1DILqzlLCs03VA=.6885ea07-0cee-46c6-b979-2ccd526324a0@github.com>
References: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
 <iSEfs8oBtN0wrZBIMLhl-nznr3kwQVZhI-WA6fnyYYY=.da7d07ad-ca4f-4da1-b2ee-08d603add5fc@github.com>
 <g82FhgMaf4Q0wGytYUWzicc0AnTEg1DILqzlLCs03VA=.6885ea07-0cee-46c6-b979-2ccd526324a0@github.com>
Message-ID: <QrHKaZZ4vSpeA9EOaZndDVeNrYsYnZ_2tPcIBk9zy0k=.5a6e45b0-adef-4b08-a45d-b3d231788934@github.com>

On Thu, 16 Feb 2023 04:38:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Looks good to me. Thanks!

Thanks for the review~

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

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


From valeriep at openjdk.org  Thu Feb 16 23:17:01 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Feb 2023 23:17:01 GMT
Subject: Integrated: 8302225: SunJCE Provider doesn't validate key sizes when
 using 'constrained' transforms for AES/KW and AES/KWP
In-Reply-To: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
References: <gMngR5nUC-3SBqBunxp3cTlgJouVr4uiMY5GbotKzB4=.f9fba12d-c5d2-4191-8c9f-597054cef61a@github.com>
Message-ID: <OPD1MUuAHuCfu5uAAYbGXXXhJ56oPsx3M2Z6YQBGCb0=.dd29acee-eb7f-4d90-977c-cc28600e17c0@github.com>

On Wed, 15 Feb 2023 02:23:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Due to an error in the existing regression test, this bug remain undiscovered until now. Added the key size check to the KeyWrapCipher class and fixed the regression test.
> 
> Please help review this trivial fix.
> 
> Thanks in advance,
> Valerie

This pull request has now been integrated.

Changeset: 4ce493f0
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ce493f09ea3a34322462e82fd73b8375be1cba5
Stats:     60 lines in 2 files changed: 36 ins; 13 del; 11 mod

8302225: SunJCE Provider doesn't validate key sizes when using 'constrained' transforms for AES/KW and AES/KWP

Reviewed-by: xuelei

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

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


From mbalao at openjdk.org  Thu Feb 16 23:23:37 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 16 Feb 2023 23:23:37 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>
Message-ID: <X-i4Bfp7X08-GxA2qKVJPSU3xVj14RMT0czsBJmCHzo=.44d57597-e761-4dc4-ba7a-a7064de33db6@github.com>

On Wed, 15 Feb 2023 19:47:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java line 1192:
> 
>> 1190:                                         /* (CKM_NSS + 31) */ = 0xCE53436FL;
>> 1191:     public static final long  CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN
>> 1192:                                         /* (CKM_NSS + 32) */ = 0xCE534370L;
> 
> For user-friendly sake, now that you added these mechanisms, you should add the string name mapping for these native NSS mechanisms into the sun.security.pkcs11.wrapper.Functions class through its addMech(long, String) method.

That's right. As part of the next iteration we will fix that and better align the order, grouping NSS mechanisms together in PKCS11Constants.java.

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

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


From jpai at openjdk.org  Fri Feb 17 05:48:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Feb 2023 05:48:29 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v2]
In-Reply-To: <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
 <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>
Message-ID: <FSKRxRo8a2_Jka3avFkXnD48-fjDU45ZZs8vwfj6uGk=.8d18da22-3975-4568-9106-34f6fd41ff92@github.com>

On Thu, 16 Feb 2023 14:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
>> 
>> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
>> 
>> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
>> 
>> 
>> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
>> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
>> 
>> 
>> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
>> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
>> 
>> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - merge latest from master branch
>  - 8302623: jarsigner - use BufferedOutputStream to improve performance while creating the signed jar

> tier testing is currently in progress.

tier1, tier2 and tier3 all passed successfully.

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

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


From christoph.langer at sap.com  Fri Feb 17 07:15:06 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 17 Feb 2023 07:15:06 +0000
Subject: Update Public Suffix list?
In-Reply-To: <98f396cd-07a7-faf3-9482-957cf6d3288c@oracle.com>
References: <DB6PR0202MB2694561DEA85F9369409BA758AA09@DB6PR0202MB2694.eurprd02.prod.outlook.com>
 <98f396cd-07a7-faf3-9482-957cf6d3288c@oracle.com>
Message-ID: <DB6PR0202MB26948A38C5DD02A894FD48298AA19@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Thanks Sean, I'll monitor the bug then.

> -----Original Message-----
> From: security-dev <security-dev-retn at openjdk.org> On Behalf Of Sean Mullan
> Sent: Donnerstag, 16. Februar 2023 16:57
> To: security-dev at openjdk.org
> Subject: Re: Update Public Suffix list?
> 
> Hi Christoph,
> 
> It's too late for JDK 20, but we will be looking into updating it for JDK 21 [1].
> 
> --Sean
> 
> [1] https://bugs.openjdk.org/browse/JDK-8302182
> 
> On 2/16/23 2:54 AM, Langer, Christoph wrote:
> > Hi,
> >
> > the last update to the public suffix list happened about a year ago
> > with
> > JDK-8255266 [0]. Are there plans for a next update?
> >
> > Thanks
> >
> > Christoph
> >
> > [0] https://bugs.openjdk.org/browse/JDK-8255266
> > <https://bugs.openjdk.org/browse/JDK-8255266>
> >

From weijun at openjdk.org  Fri Feb 17 15:06:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Feb 2023 15:06:58 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v2]
In-Reply-To: <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
 <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>
Message-ID: <ilfxzJ7-ciohySC40eAKXAtmXnOojumtdJCqWCMCrvE=.747bd32d-5d55-44f4-8fed-e70a8a359603@github.com>

On Thu, 16 Feb 2023 14:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
>> 
>> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
>> 
>> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
>> 
>> 
>> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
>> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
>> 
>> 
>> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
>> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
>> 
>> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - merge latest from master branch
>  - 8302623: jarsigner - use BufferedOutputStream to improve performance while creating the signed jar

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1970:

> 1968:         FileOutputStream fos = null;
> 1969:         try {
> 1970:             fos = new FileOutputStream(signedJarFile);

Can we make this change right at https://github.com/openjdk/jdk/blob/5dfc4ec7d94af9fe39fdee9d83b06101b827a3c6/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java#L691 or at least inside that class?

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

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


From jpai at openjdk.org  Fri Feb 17 15:49:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Feb 2023 15:49:56 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v3]
In-Reply-To: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
Message-ID: <hPyzuZs7bsu3rn2ywJHoXfoELm6ebQTmZzbwvY05wl8=.47616cb6-5c5c-4a67-b4e3-290e881690cc@github.com>

> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
> 
> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
> 
> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
> 
> 
> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
> 
> 
> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
> 
> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.

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

  Review comment - move the BufferedOutputStream creation to Jarsigner class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12588/files
  - new: https://git.openjdk.org/jdk/pull/12588/files/fcb7ee45..a6e7ff78

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

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

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


From weijun at openjdk.org  Fri Feb 17 15:49:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Feb 2023 15:49:57 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v3]
In-Reply-To: <hPyzuZs7bsu3rn2ywJHoXfoELm6ebQTmZzbwvY05wl8=.47616cb6-5c5c-4a67-b4e3-290e881690cc@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
 <hPyzuZs7bsu3rn2ywJHoXfoELm6ebQTmZzbwvY05wl8=.47616cb6-5c5c-4a67-b4e3-290e881690cc@github.com>
Message-ID: <kU3OBbu7yTBxaJ6Ea6q7masgQ6s0ogsR5BMthe4rA9A=.fba0db40-3d19-4fc1-8986-f75b6a2a2f71@github.com>

On Fri, 17 Feb 2023 15:36:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
>> 
>> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
>> 
>> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
>> 
>> 
>> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
>> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
>> 
>> 
>> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
>> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
>> 
>> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment - move the BufferedOutputStream creation to Jarsigner class

Looks fine. Thanks.

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

Marked as reviewed by weijun (Reviewer).

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


From jpai at openjdk.org  Fri Feb 17 15:52:20 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Feb 2023 15:52:20 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v3]
In-Reply-To: <ilfxzJ7-ciohySC40eAKXAtmXnOojumtdJCqWCMCrvE=.747bd32d-5d55-44f4-8fed-e70a8a359603@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
 <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>
 <ilfxzJ7-ciohySC40eAKXAtmXnOojumtdJCqWCMCrvE=.747bd32d-5d55-44f4-8fed-e70a8a359603@github.com>
Message-ID: <hp2Cw1YwhMrNXFIxv0nkaSBtCKclYFediBZ-xLFkxJY=.24d0c5fb-93d9-4825-bee2-1a2b8f565c62@github.com>

On Fri, 17 Feb 2023 14:58:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment - move the BufferedOutputStream creation to Jarsigner class
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1970:
> 
>> 1968:         OutputStream os = null;
>> 1969:         try {
>> 1970:             os = new BufferedOutputStream(new FileOutputStream(signedJarFile));
> 
> Can we make this change right at https://github.com/openjdk/jdk/blob/5dfc4ec7d94af9fe39fdee9d83b06101b827a3c6/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java#L691 or at least inside that class?

Hello Max, what you suggest sounds fine to me. I've updated the PR to follow this suggestion. The only difference now would be that in the previous proposed patch if any exception happened during the jarsiging the `BufferedOutputStream` would be (flushed and) closed from the finally block of the main method. However, in the newer version, there can be a case that if an exception occurs then the underlying BufferedOutputStream, constructed in the `JarSigner` class may not be flushed/closed, but that I think should be fine, because we anyway delete the temporary signed jar file, in the main method, if any exception occurs.

With this new change, I again ran the test against a 3GB and 6GB file and the numbers continue to show the improvement. I'll trigger the tier testing too.

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

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


From weijun at openjdk.org  Fri Feb 17 15:53:20 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Feb 2023 15:53:20 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v3]
In-Reply-To: <hp2Cw1YwhMrNXFIxv0nkaSBtCKclYFediBZ-xLFkxJY=.24d0c5fb-93d9-4825-bee2-1a2b8f565c62@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
 <Mx1mW1UounultoLdt8jYZjh9BZMrRp3cCo56skkUwhQ=.85904109-14ee-411a-bdac-e593e433b121@github.com>
 <ilfxzJ7-ciohySC40eAKXAtmXnOojumtdJCqWCMCrvE=.747bd32d-5d55-44f4-8fed-e70a8a359603@github.com>
 <hp2Cw1YwhMrNXFIxv0nkaSBtCKclYFediBZ-xLFkxJY=.24d0c5fb-93d9-4825-bee2-1a2b8f565c62@github.com>
Message-ID: <9aJRIXG_yhKbjjbddmGmILs4IqhF-yRStu1yj2LwrHw=.0607d9cf-a67e-4f88-b2b7-927999107312@github.com>

On Fri, 17 Feb 2023 15:30:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1970:
>> 
>>> 1968:         OutputStream os = null;
>>> 1969:         try {
>>> 1970:             os = new BufferedOutputStream(new FileOutputStream(signedJarFile));
>> 
>> Can we make this change right at https://github.com/openjdk/jdk/blob/5dfc4ec7d94af9fe39fdee9d83b06101b827a3c6/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java#L691 or at least inside that class?
>
> Hello Max, what you suggest sounds fine to me. I've updated the PR to follow this suggestion. The only difference now would be that in the previous proposed patch if any exception happened during the jarsiging the `BufferedOutputStream` would be (flushed and) closed from the finally block of the main method. However, in the newer version, there can be a case that if an exception occurs then the underlying BufferedOutputStream, constructed in the `JarSigner` class may not be flushed/closed, but that I think should be fine, because we anyway delete the temporary signed jar file, in the main method, if any exception occurs.
> 
> With this new change, I again ran the test against a 3GB and 6GB file and the numbers continue to show the improvement. I'll trigger the tier testing too.

Correct, `jarsigner` the tool won't damage the original JAR file if an error occurs. For people directly calling the `JarSigner` API, I think they should not have any expectation on what is written into the output stream when there is an error.

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

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


From mbalao at redhat.com  Fri Feb 17 18:52:21 2023
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 17 Feb 2023 13:52:21 -0500
Subject: RFD: Services lockdown for security providers
Message-ID: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>

Hi,

We would like to discuss a limitation in the current configuration 
capabilities for security providers and possible solutions that we are 
exploring (?).

As you know, current configuration capabilities in java.security allow 
users to install security providers, decide their priority in a list 
(security.provider.<n> properties) and even circumvent this priority for 
specific algorithms (jdk.security.provider.preferred property). However, 
there is no granularity in terms of what service types and algorithms 
are enabled once a security provider is installed: it's an all or 
nothing scheme. It is worth noting that security providers can bring 
with them a diverse range of service types. As an example, the SUN 
security provider comes with the following service types: SecureRandom, 
Signature, KeyPairGenerator, AlgorithmParameterGenerator, 
AlgorithmParameters, KeyFactory, MessageDigest, CertificateFactory, 
KeyStore, CertStore, Policy, Configuration, CertPathBuilder and 
CertPathValidator [1].

In some cases, the user may need to enforce that all cryptographic 
primitives come from a specific security provider. This could happen, 
for example, when operating in a FIPS-compliant environment or under 
strict security policies. To better illustrate, let's say that the user 
requires that all cryptographic operations are performed in a Hardware 
Security Module (HSM). On the OpenJDK side, this means that the 
implementation for Cipher, Signature, Mac and other cryptographic 
services must be the one in the SunPKCS11 security provider. Let's also 
suppose that other non-cryptographic services such as those for 
certificates validation and TLS are required, and their implementation 
is in the SUN and SunJSSE security providers respectively. Setting 
SunPKCS11 at the highest priority of the list is not a strong guarantee 
to ensure that all cryptographic operations come from it: it's possible 
that an algorithm for Signature is not implemented in SunPKCS11 or in 
its underlying token but in the SUN security provider. Disabling the SUN 
security provider wouldn't be an option in this case because we need its 
certificates validation service.

This problem goes beyond OpenJDK default security providers. Even if we 
come up with a new layout for service types, algorithms and providers 
?putting backward compatibility issues aside?, there is always the 
possibility that a 3rd party security provider does not follow any 
services grouping convention. It might also be the case that we need to 
disable a specific algorithm only ?i.e. for cryptographic policy 
reasons? and TLS or JAR signing properties fall short.

In our view, it would be beneficial to add more configuration 
flexibility and control to the existing API in which any security 
provider can be plugged in, in the form of deciding which service types 
and algorithms are enabled for each installed provider.

There are 2 alternatives that we are exploring to tackle this problem.

Alternative #1
===========================

Introduce a new security property to decide which service types and 
algorithms are enabled for each security provider. The default value for 
this property would be empty, which keeps this feature disabled and all 
services from installed security providers available.

As for the new property's syntax and semantics, we've been considering 
an allow-list along the lines of:

jdk.security.provider.enabled = security-provider-1 { service-type-1 : 
alg-1, ... ; ... } , ...

Note: we need a formal syntax specification, this is for illustration only.

As part of the syntax we are considering the use of wildcards (*) to 
match multiple security providers, service types and algorithms, and 
minus signs (-) to remove service types. When a service type is removed, 
the action applies to all algorithms and any attempt to specify them 
explicitly would be an error. The minus sign cannot be used at the 
algorithm level. We are also thinking that in case of a partial or total 
contradiction between conditions, the right-most value applies on top of 
the others. If a security provider, service type or algorithm does not 
exist, we can simply write a debug warning and ignore it. As for the 
name of the algorithms, we can also include Ciphers transformations.

Example:

jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : 
AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature }

This would be interpreted as:

  * Irrespective of the provider (*), Cipher services should be removed 
(-). This rule would be superfluous in this case because the property 
itself is an allow-list and there is nothing to the left that enables 
Cipher service types for any provider.
  * From the SunJCE security provider, Cipher services with 
AES/GCM/NoPadding and DES transformations are allowed, and Signature 
services with any algorithm are allowed. Notice that there is a shortcut 
here: the algorithm list that follows the service name, "': alg-1, ..." 
is optional. When omitted all the service's algorithms are enabled.
  * From the SUN security provider, every service type is allowed except 
Signature (recall that a minus sign can only apply to a service, 
removing all associated algorithms).

It's not the goal of this proposal to invalidate property values that 
lead to inconsistent internal states, such as "the Cipher service of 
SunJCE depends on AlgorithmParameters from SUN". This is because the 
combinations for a check are virtually infinite: there can be 3rd party 
security providers with their own semantics and dependencies. In the 
same way, we cannot determine at start time any application 
dependencies. It's up to the user to analyze all types of dependencies 
before setting a value.


Alternative #2
===========================

Introduce a boolean security property to turn the value of the existing 
jdk.security.provider.preferred property into the only combinations of 
algorithm, service and provider that are allowed:

jdk.security.provider.preferredOnly = true

The default value for the new property would be "false", keeping the 
current "preferred" behavior in which all algorithms and services from 
installed security providers are available.

Contrary to Alternative #1, the user has to explicitly list the 
algorithms and cannot rely on wildcards to express wide categories such 
as "all Cipher algorithms from SunJCE" or "all algorithms from SunJCE". 
The use of minus signs to remove service types or algorithms wouldn't be 
available either.

In order to mitigate the burden on users we can consider extending 
jdk.security.provider.preferred syntax as long as we keep 
backward-compatibility and stay within the boundaries of a "preferred" 
semantics. For example, we can accept a value of 
"jdk.security.provider.preferred=SunJCE" to mean that any service and 
any algorithm from SunJCE is either preferred or allowed, depending on 
the value of jdk.security.provider.preferredOnly. This case would be a 
service type and algorithm wildcard. We can also define an 
algorithms-only wildcard, such as Cipher.*:SunJCE.

Alternative #2 has the advantage of reusing most or all of the existing 
syntax. However, it's worth noticing that it implies an overloaded 
semantic that can turn confusing or inconvenient in some cases. As an 
example, a user that relies on the prioritized security providers list 
for most of the algorithms and has only a few preferred exceptions, 
would need to express preferences by extension upon turning on this 
feature. Alternative #1 keeps preferences and availability as two 
separate concepts, in a more clear way.


Thanks,
Martin.-

--
[1] - 
https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D
(?) - Thanks to @fferrari for his contributions to this proposal.



From lancea at openjdk.org  Sat Feb 18 11:56:40 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 18 Feb 2023 11:56:40 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v15]
In-Reply-To: <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
Message-ID: <XGRNyk93g5-AALDEkYVpn21EX29r0vNQS6r9IfKo7K4=.ba8ae55f-bf7b-44c0-8e7e-5112f54c9a40@github.com>

On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a regression where the invalidName was tested instead of comment in the invalid comment test

Thank you Eirik for your patience through the review and testing of your PR.

I think we are in good shape overall.  Mach5 tiers1-6 look good as do the JCK tests for Zip

Best
Lance

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

Marked as reviewed by lancea (Reviewer).

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


From jpai at openjdk.org  Sat Feb 18 12:00:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Feb 2023 12:00:33 GMT
Subject: RFR: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar [v3]
In-Reply-To: <hPyzuZs7bsu3rn2ywJHoXfoELm6ebQTmZzbwvY05wl8=.47616cb6-5c5c-4a67-b4e3-290e881690cc@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
 <hPyzuZs7bsu3rn2ywJHoXfoELm6ebQTmZzbwvY05wl8=.47616cb6-5c5c-4a67-b4e3-290e881690cc@github.com>
Message-ID: <0v24Vo-vIvKZH6Fp6emqeaJxXZi4H_iU6JrR8FdurWI=.2fe12f01-ce23-4d32-afc9-736556522a47@github.com>

On Fri, 17 Feb 2023 15:49:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
>> 
>> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
>> 
>> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
>> 
>> 
>> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
>> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
>> 
>> 
>> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
>> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
>> 
>> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment - move the BufferedOutputStream creation to Jarsigner class

Thank you Max for the review. tier1,tier2,tier3 tests passed with the latest state of this PR.

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

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


From jpai at openjdk.org  Sat Feb 18 12:00:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Feb 2023 12:00:35 GMT
Subject: Integrated: 8302623: jarsigner - use BufferedOutputStream to improve
 performance while creating the signed jar
In-Reply-To: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
References: <0j5W1m5jCkrvPLbqc1tAOHqo4CMSz1kFejQKbKPvqEo=.0b3f0850-e9cc-4730-abce-d73121a994cd@github.com>
Message-ID: <6Y9OeNXn_d9smkWrqIaSfpHu1sGzt23CbF38jRz-Gbw=.007c5791-c8b7-49d4-b5b4-c26b0fd2a3d3@github.com>

On Thu, 16 Feb 2023 10:43:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which improves the jarsigner tool's performance (especially) when dealing with large jar files? This addresses https://bugs.openjdk.org/browse/JDK-8302623.
> 
> As noted in the JBS issue, wrapping the target `FileOutputStream` with the `BufferedOutputStream` reduces the amount of write calls that happen on the file and has shown to improve the amount of time it takes to sign the jar files.
> 
> On a macOS M1, the numbers before and after this change are as follows (`time` command was used to get these numbers):
> 
> 
> JDK 19, 3GB file: 144.52s user 19.79s system 98% cpu 2:46.80 total
> JDK with this change, (same) 3GB file: 139.27s user 4.86s system 97% cpu 2:27.41 total
> 
> 
> JDK 19, 6GB file: 289.38s user 38.87s system 99% cpu 5:28.90 total
> JDK with this change, (same) 6GB file: 279.69s user 9.93s system 99% cpu 4:49.88 total 
> 
> No new tests have been added for this change. The current existing tests in `test/jdk/sun/security/tools/jarsigner` continue to pass locally. tier testing is currently in progress.

This pull request has now been integrated.

Changeset: f82385e5
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f82385e58741aa83dccc4876ae69a6033217d9ed
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8302623: jarsigner - use BufferedOutputStream to improve performance while creating the signed jar

Reviewed-by: weijun

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

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


From duke at openjdk.org  Sat Feb 18 12:42:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 18 Feb 2023 12:42:40 GMT
Subject: Integrated: 8301873: Avoid string decoding in
 ZipFile.Source.getEntryPos
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <PTKDkIXCZwb-NgmjihEkFkt6JcoMJKTpMuJTvWL1T6U=.a2a18456-8594-4bff-b34d-29fe0472b7c3@github.com>

On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

This pull request has now been integrated.

Changeset: 78f71b4d
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78f71b4d41f8682ea10b1573106b11c00f150a1c
Stats:     384 lines in 4 files changed: 359 ins; 9 del; 16 mod

8301873: Avoid string decoding in ZipFile.Source.getEntryPos

Reviewed-by: redestad, lancea

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

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


From lucy at openjdk.org  Mon Feb 20 12:21:27 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 20 Feb 2023 12:21:27 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v4]
In-Reply-To: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
Message-ID: <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>

> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
> 
> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
> 
> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
> 
> **Reviews and comments are very much appreciated.**
> 
> @backwaterred could you please run some "official" s390 tests? Thanks.

Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge master to resolve copyright conflict
 - 829817: fixed typos, removed JIT_TIMER references
 - 8299817: Update copyright
 - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls

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

Changes: https://git.openjdk.org/jdk/pull/11967/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11967&range=03
  Stats: 719 lines in 5 files changed: 509 ins; 64 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/11967.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11967/head:pull/11967

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


From lucy at openjdk.org  Mon Feb 20 16:44:35 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 20 Feb 2023 16:44:35 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v4]
In-Reply-To: <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
Message-ID: <H5DGkK6rz6GmS4f7abEOvPqt494navt_z3TBqM3VsVg=.2ee54f97-3eb7-4510-b5e9-744f3e7302f2@github.com>

On Mon, 20 Feb 2023 12:21:27 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge master to resolve copyright conflict
>  - 829817: fixed typos, removed JIT_TIMER references
>  - 8299817: Update copyright
>  - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls

Being an s390-only PR, failures on arm build and linux-x85 tests are unrelated.

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

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


From duke at openjdk.org  Wed Feb 22 11:37:07 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 22 Feb 2023 11:37:07 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v4]
In-Reply-To: <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
Message-ID: <RetPE2cz4Smunj6k3BwSSpqldnGBZcZ0P5m2HKjTWB8=.e64b2fe7-8961-408f-85d7-84a396d171f2@github.com>

On Mon, 20 Feb 2023 12:21:27 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge master to resolve copyright conflict
>  - 829817: fixed typos, removed JIT_TIMER references
>  - 8299817: Update copyright
>  - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls

Build and Testing done for tier1 in fastdebug, slowdebug and release build on z15/s390x machine.

 LGTM

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

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

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


From amol.borole at gmail.com  Wed Feb 22 20:14:16 2023
From: amol.borole at gmail.com (amol borole)
Date: Wed, 22 Feb 2023 12:14:16 -0800
Subject: RSASSA-PSS support for TLS 1.3
Message-ID: <CAMyA8YkqBrYkfvbMNzVi3hzRmbzT66X4EGdnXA-wJPLAXeKWYQ@mail.gmail.com>

Hello,

When using TLS 1.3 and certificate generated by the keytool command like
'keytool -genkey -keyalg RSASSA-PSS ..." , it gets the same error
'javax.net.ssl.SSLHandshakeException:
No available authentication scheme' as listed in
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8211426.

This handshake errors with RSASSA-PSS certificates has been seen in OpenJDK
1.8.0.342-b07 as well as in OpenJDK 19.0.2+7-44. So question is
whether RSASSA-PSS is supported for TLS 1.3 at all? Which OpenJDK versions
claim TLS 1.3 support for RSASSA-PSS certificates? Is it possible support
was added in intermediate versions like 11 or 12 but not in the latest
version 19?

Note: No handshake errors if RSA/ECDSA certificates (also generated using
keytool) are used with TLS 1.3, those certificates seem to work fine in all
JDK versions.

Thanks,
Amol.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230222/b65f289b/attachment.htm>

From duke at openjdk.org  Thu Feb 23 21:51:49 2023
From: duke at openjdk.org (Ahmed Muhsin)
Date: Thu, 23 Feb 2023 21:51:49 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown
Message-ID: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>

This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.

The build and tier1 tests pass locally on mac-aarch64.

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

Commit messages:
 - instantiate BadPaddingException only when it needs to be thrown

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

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


From duke at openjdk.org  Thu Feb 23 21:55:06 2023
From: duke at openjdk.org (Ahmed Muhsin)
Date: Thu, 23 Feb 2023 21:55:06 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <CgzDdzkdyorqYMjBhTTUCzHVZANNUkusYofA6NrvzLc=.eddcc558-1c50-471c-977b-c4cd4996ffe5@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

There is one failure in the pre-submit tests which I believe is unrelated to this change:
`compiler/vectorization/runner/LoopRangeStrideTest.java`

TEST RESULT: Failed. Execution failed: `main' threw exception: compiler.lib.ir_framework.driver.irmatching.IRViolationException: There were one or multiple IR rule failures. Please check stderr for more information.

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

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


From cslucas at openjdk.org  Fri Feb 24 17:08:11 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Feb 2023 17:08:11 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <CgzDdzkdyorqYMjBhTTUCzHVZANNUkusYofA6NrvzLc=.eddcc558-1c50-471c-977b-c4cd4996ffe5@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <CgzDdzkdyorqYMjBhTTUCzHVZANNUkusYofA6NrvzLc=.eddcc558-1c50-471c-977b-c4cd4996ffe5@github.com>
Message-ID: <b4BQXtkq2biowBSYh0t1ydea-YvB5fgGsAr9xlCLyfU=.b05811da-07ec-4333-86e4-611521fb79fe@github.com>

On Thu, 23 Feb 2023 21:52:14 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> There is one failure in the pre-submit tests which I believe is unrelated to this change:

The same test is failing in at least one other PR: https://github.com/openjdk/jdk/pull/12735/checks?check_run_id=11564672673

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

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


From anthony.scarpino at oracle.com  Fri Feb 24 19:49:33 2023
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 24 Feb 2023 11:49:33 -0800
Subject: RFD: Services lockdown for security providers
In-Reply-To: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
Message-ID: <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>

Hi Martin,

Interesting proposal.  I think Alternative 1 is a better direction to 
explore from a code structure standpoint.  If I remember correctly, 
Preferred Provider is accessed when getting a service or instance of the 
algorithm.  That happens on a per-operation basis.  What you describe is 
something that would reshape contents of the ProviderList where 
algorithms or services would not be in the list at all.  That is were I 
think #2 gets too complex in trying to handle both in the same property. 
  #2 may end up putting all checks in a per-operation check, hindering 
performance every time as the list grows.

I agree this is mostly used in the FIPS situation or where someone wants 
to disable an algorithm completely, say MD5.  In those cases it's best 
to just prevent the algorithm from ever being available.

On the smaller details side that you list.  I think the name ".enabled" 
doesn't fit, particularly as the first thing in the example disables all 
Ciphers :).  I don't have any suggestions at this time.

As far as the syntax.  I think it maybe a bit difficult to parse in code 
and mental to disable all Ciphers, then enable just for SunJCE and SUN. 
The SUN '*" confused me until I realized you were enabling Ciphers. 
Seems too easy to get wrong.  I know you weren't making a formal spec, 
but we have to start somewhere.

thanks

Tony


On 2/17/23 10:52 AM, Martin Balao wrote:
> Hi,
> 
> We would like to discuss a limitation in the current configuration 
> capabilities for security providers and possible solutions that we are 
> exploring (?).
> 
> As you know, current configuration capabilities in java.security allow 
> users to install security providers, decide their priority in a list 
> (security.provider.<n> properties) and even circumvent this priority for 
> specific algorithms (jdk.security.provider.preferred property). However, 
> there is no granularity in terms of what service types and algorithms 
> are enabled once a security provider is installed: it's an all or 
> nothing scheme. It is worth noting that security providers can bring 
> with them a diverse range of service types. As an example, the SUN 
> security provider comes with the following service types: SecureRandom, 
> Signature, KeyPairGenerator, AlgorithmParameterGenerator, 
> AlgorithmParameters, KeyFactory, MessageDigest, CertificateFactory, 
> KeyStore, CertStore, Policy, Configuration, CertPathBuilder and 
> CertPathValidator [1].
> 
> In some cases, the user may need to enforce that all cryptographic 
> primitives come from a specific security provider. This could happen, 
> for example, when operating in a FIPS-compliant environment or under 
> strict security policies. To better illustrate, let's say that the user 
> requires that all cryptographic operations are performed in a Hardware 
> Security Module (HSM). On the OpenJDK side, this means that the 
> implementation for Cipher, Signature, Mac and other cryptographic 
> services must be the one in the SunPKCS11 security provider. Let's also 
> suppose that other non-cryptographic services such as those for 
> certificates validation and TLS are required, and their implementation 
> is in the SUN and SunJSSE security providers respectively. Setting 
> SunPKCS11 at the highest priority of the list is not a strong guarantee 
> to ensure that all cryptographic operations come from it: it's possible 
> that an algorithm for Signature is not implemented in SunPKCS11 or in 
> its underlying token but in the SUN security provider. Disabling the SUN 
> security provider wouldn't be an option in this case because we need its 
> certificates validation service.
> 
> This problem goes beyond OpenJDK default security providers. Even if we 
> come up with a new layout for service types, algorithms and providers 
> ?putting backward compatibility issues aside?, there is always the 
> possibility that a 3rd party security provider does not follow any 
> services grouping convention. It might also be the case that we need to 
> disable a specific algorithm only ?i.e. for cryptographic policy 
> reasons? and TLS or JAR signing properties fall short.
> 
> In our view, it would be beneficial to add more configuration 
> flexibility and control to the existing API in which any security 
> provider can be plugged in, in the form of deciding which service types 
> and algorithms are enabled for each installed provider.
> 
> There are 2 alternatives that we are exploring to tackle this problem.
> 
> Alternative #1
> ===========================
> 
> Introduce a new security property to decide which service types and 
> algorithms are enabled for each security provider. The default value for 
> this property would be empty, which keeps this feature disabled and all 
> services from installed security providers available.
> 
> As for the new property's syntax and semantics, we've been considering 
> an allow-list along the lines of:
> 
> jdk.security.provider.enabled = security-provider-1 { service-type-1 : 
> alg-1, ... ; ... } , ...
> 
> Note: we need a formal syntax specification, this is for illustration only.
> 
> As part of the syntax we are considering the use of wildcards (*) to 
> match multiple security providers, service types and algorithms, and 
> minus signs (-) to remove service types. When a service type is removed, 
> the action applies to all algorithms and any attempt to specify them 
> explicitly would be an error. The minus sign cannot be used at the 
> algorithm level. We are also thinking that in case of a partial or total 
> contradiction between conditions, the right-most value applies on top of 
> the others. If a security provider, service type or algorithm does not 
> exist, we can simply write a debug warning and ignore it. As for the 
> name of the algorithms, we can also include Ciphers transformations.
> 
> Example:
> 
> jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : 
> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature }
> 
> This would be interpreted as:
> 
>  ?* Irrespective of the provider (*), Cipher services should be removed 
> (-). This rule would be superfluous in this case because the property 
> itself is an allow-list and there is nothing to the left that enables 
> Cipher service types for any provider.
>  ?* From the SunJCE security provider, Cipher services with 
> AES/GCM/NoPadding and DES transformations are allowed, and Signature 
> services with any algorithm are allowed. Notice that there is a shortcut 
> here: the algorithm list that follows the service name, "': alg-1, ..." 
> is optional. When omitted all the service's algorithms are enabled.
>  ?* From the SUN security provider, every service type is allowed except 
> Signature (recall that a minus sign can only apply to a service, 
> removing all associated algorithms).
> 
> It's not the goal of this proposal to invalidate property values that 
> lead to inconsistent internal states, such as "the Cipher service of 
> SunJCE depends on AlgorithmParameters from SUN". This is because the 
> combinations for a check are virtually infinite: there can be 3rd party 
> security providers with their own semantics and dependencies. In the 
> same way, we cannot determine at start time any application 
> dependencies. It's up to the user to analyze all types of dependencies 
> before setting a value.
> 
> 
> Alternative #2
> ===========================
> 
> Introduce a boolean security property to turn the value of the existing 
> jdk.security.provider.preferred property into the only combinations of 
> algorithm, service and provider that are allowed:
> 
> jdk.security.provider.preferredOnly = true
> 
> The default value for the new property would be "false", keeping the 
> current "preferred" behavior in which all algorithms and services from 
> installed security providers are available.
> 
> Contrary to Alternative #1, the user has to explicitly list the 
> algorithms and cannot rely on wildcards to express wide categories such 
> as "all Cipher algorithms from SunJCE" or "all algorithms from SunJCE". 
> The use of minus signs to remove service types or algorithms wouldn't be 
> available either.
> 
> In order to mitigate the burden on users we can consider extending 
> jdk.security.provider.preferred syntax as long as we keep 
> backward-compatibility and stay within the boundaries of a "preferred" 
> semantics. For example, we can accept a value of 
> "jdk.security.provider.preferred=SunJCE" to mean that any service and 
> any algorithm from SunJCE is either preferred or allowed, depending on 
> the value of jdk.security.provider.preferredOnly. This case would be a 
> service type and algorithm wildcard. We can also define an 
> algorithms-only wildcard, such as Cipher.*:SunJCE.
> 
> Alternative #2 has the advantage of reusing most or all of the existing 
> syntax. However, it's worth noticing that it implies an overloaded 
> semantic that can turn confusing or inconvenient in some cases. As an 
> example, a user that relies on the prioritized security providers list 
> for most of the algorithms and has only a few preferred exceptions, 
> would need to express preferences by extension upon turning on this 
> feature. Alternative #1 keeps preferences and availability as two 
> separate concepts, in a more clear way.
> 
> 
> Thanks,
> Martin.-
> 
> -- 
> [1] - 
> https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D
> (?) - Thanks to @fferrari for his contributions to this proposal.
> 


From mbalao at openjdk.org  Fri Feb 24 21:35:05 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 24 Feb 2023 21:35:05 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <REUAryBRGClxDoF4-W8hldJ0eSJCaOH4zr9GLPUXuk4=.342b8185-23a4-4cf0-9d95-93ea0e98dae3@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>
 <REUAryBRGClxDoF4-W8hldJ0eSJCaOH4zr9GLPUXuk4=.342b8185-23a4-4cf0-9d95-93ea0e98dae3@github.com>
Message-ID: <NaOl7ddgCbzYxmvN9Ve-Eha0qhRi54Z0sWJMqwE0JAw=.2e3bb564-bfed-4939-826c-f67764511dc5@github.com>

On Thu, 16 Feb 2023 04:52:57 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 165:
>> 
>>> 163:                 getInfo();
>>> 164:                 this.version.major = pInfo.cryptokiVersion.major;
>>> 165:                 this.version.minor = pInfo.cryptokiVersion.minor;
>> 
>> Now that you added getInfo(), then the C_GetInfo() could be made private, so that all callers can just leverage getInfo(), right?
>
> Right! We will make C_GetInfo private and delete the overload in SynchronizedPKCS11 for the next iteration.

We have analyzed this issue further and think that we need one more iteration. It's possible that the constructor of PKCS11 finishes with PKCS11::pInfo in null. In fact, it's very likely to happen and PKCS11::getInfo is not multi-thread safe. The second problem is that it's possible that a SyncrhonizedPKCS11 instance ends up calling a non-synchronized version of PKCS11::C_GetInfo, if we remove the override. The reason why we added PKCS11::getInfo in the first place was because PKCS11::getVersion is not currently available in 17u ?where this feature was originally developed? and there were 2 calls to PKCS11::C_GetInfo. We can safely undo the PKCS11::getInfo change and call PKCS11::getVersion in P11SecretKeyFactory::derivePBEKey.

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

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


From duke at openjdk.org  Sat Feb 25 02:42:04 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Sat, 25 Feb 2023 02:42:04 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <zNFNS1Z7Kd2eXepPrLa_MPdubRbZE5GvjcLegQMvZQk=.2d37906f-6650-4348-9fbb-b0aa3eae1c77@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 370:

> 368: 
> 369:         if (bp) {
> 370:             throw new BadPaddingException("Decryption error");

I assume the reason it was originally written this way was to ensure both the successful and unsuccessful paths are constant time to avoid timing attacks here, see the comment on method.

I am not a cryptographer but I'm wondering if you could use a preallocated `BadPaddingException` and/or overriding `fillInStackTrace() { return this; }` 

https://github.com/openjdk/jdk/blob/caef0a589cb31e97e0ef9e8355d4aa3325908140/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L331-L333

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

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


From mdoerr at openjdk.org  Sat Feb 25 07:55:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 25 Feb 2023 07:55:09 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v4]
In-Reply-To: <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
Message-ID: <FHFPKXQhlZoe32qLA3LA33dgWAG7Ryehwx_RuKr4Qn8=.537ccf06-4cab-46ef-84ba-aa2ab44d2e93@github.com>

On Mon, 20 Feb 2023 12:21:27 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge master to resolve copyright conflict
>  - 829817: fixed typos, removed JIT_TIMER references
>  - 8299817: Update copyright
>  - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls

Not a detailed review, but I couldn't spot anything bad.

test/hotspot/jtreg/compiler/codegen/aes/Test8299817.java line 67:

> 65:     public static void main(String[] args) throws Exception {
> 66:         if (!DEBUG_MODE) {
> 67:             if (!Compiler.isIntrinsicAvailable(CompilerWhiteBoxTest.COMP_LEVEL_FULL_OPTIMIZATION, "com.sun.crypto.provider.CounterMode", "implCrypt", byte[].class, int.class, int.class, byte[].class, int.class)) {

Maybe break the large lines?

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

Marked as reviewed by mdoerr (Reviewer).

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


From lucy at openjdk.org  Mon Feb 27 09:03:57 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 27 Feb 2023 09:03:57 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v4]
In-Reply-To: <FHFPKXQhlZoe32qLA3LA33dgWAG7Ryehwx_RuKr4Qn8=.537ccf06-4cab-46ef-84ba-aa2ab44d2e93@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <EIWs2k9jUkWJq1q1boN3eKG9QHvDsxx01iPIfPcCl1M=.7a8d3e5c-ab3d-4153-9976-7aabc9fe646f@github.com>
 <FHFPKXQhlZoe32qLA3LA33dgWAG7Ryehwx_RuKr4Qn8=.537ccf06-4cab-46ef-84ba-aa2ab44d2e93@github.com>
Message-ID: <rv5BQBphi9gJ_4h2ilu9w097vuZIqroaGazzF-F8An8=.f73a5837-55a8-4455-b28e-5b016cfe9e2c@github.com>

On Sat, 25 Feb 2023 07:51:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge master to resolve copyright conflict
>>  - 829817: fixed typos, removed JIT_TIMER references
>>  - 8299817: Update copyright
>>  - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls
>
> test/hotspot/jtreg/compiler/codegen/aes/Test8299817.java line 67:
> 
>> 65:     public static void main(String[] args) throws Exception {
>> 66:         if (!DEBUG_MODE) {
>> 67:             if (!Compiler.isIntrinsicAvailable(CompilerWhiteBoxTest.COMP_LEVEL_FULL_OPTIMIZATION, "com.sun.crypto.provider.CounterMode", "implCrypt", byte[].class, int.class, int.class, byte[].class, int.class)) {
> 
> Maybe break the large lines?

Lines split.
Thank you very much for your reviews, @TheRealMDoerr @offamitkumar @MBaesken

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

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


From lucy at openjdk.org  Mon Feb 27 09:03:49 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 27 Feb 2023 09:03:49 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v5]
In-Reply-To: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
Message-ID: <pdqy5QUwhuuqsI1RKlgvkm1uR5PEdljcv6vdmbzV9wU=.0e81787e-0de2-4109-be62-72c684076c7b@github.com>

> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
> 
> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
> 
> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
> 
> **Reviews and comments are very much appreciated.**
> 
> @backwaterred could you please run some "official" s390 tests? Thanks.

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

  8299817: split some excessively long lines in Test8299817.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11967/files
  - new: https://git.openjdk.org/jdk/pull/11967/files/0c8ced1e..6de4aef7

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

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

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


From lucy at openjdk.org  Mon Feb 27 11:50:18 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 27 Feb 2023 11:50:18 GMT
Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls [v5]
In-Reply-To: <pdqy5QUwhuuqsI1RKlgvkm1uR5PEdljcv6vdmbzV9wU=.0e81787e-0de2-4109-be62-72c684076c7b@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
 <pdqy5QUwhuuqsI1RKlgvkm1uR5PEdljcv6vdmbzV9wU=.0e81787e-0de2-4109-be62-72c684076c7b@github.com>
Message-ID: <2ePC020NWUVyA4CrP1NirZAZ5UXZRV5VhYkdWReWaAQ=.46649f78-6f94-40f4-80c2-6873120b637c@github.com>

On Mon, 27 Feb 2023 09:03:49 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
>> 
>> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
>> 
>> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
>> 
>> **Reviews and comments are very much appreciated.**
>> 
>> @backwaterred could you please run some "official" s390 tests? Thanks.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299817: split some excessively long lines in Test8299817.java

Build and test failures seem unrelated to this s390-only fix.

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

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


From duke at openjdk.org  Mon Feb 27 18:38:35 2023
From: duke at openjdk.org (Ahmed Muhsin)
Date: Mon, 27 Feb 2023 18:38:35 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <zNFNS1Z7Kd2eXepPrLa_MPdubRbZE5GvjcLegQMvZQk=.2d37906f-6650-4348-9fbb-b0aa3eae1c77@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <zNFNS1Z7Kd2eXepPrLa_MPdubRbZE5GvjcLegQMvZQk=.2d37906f-6650-4348-9fbb-b0aa3eae1c77@github.com>
Message-ID: <PmWzlgE3UmEnj_r6GYVM9ndjKUFKDwfmwIVbSoYyQQE=.3a52e4a2-d61e-4513-83a7-f9a242e2c73d@github.com>

On Sat, 25 Feb 2023 02:38:47 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
>> 
>> The build and tier1 tests pass locally on mac-aarch64.
>
> src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 370:
> 
>> 368: 
>> 369:         if (bp) {
>> 370:             throw new BadPaddingException("Decryption error");
> 
> I assume the reason it was originally written this way was to ensure both the successful and unsuccessful paths are constant time to avoid timing attacks here, see the comment on method.
> 
> I am not a cryptographer but I'm wondering if you could use a preallocated `BadPaddingException` and/or overriding `fillInStackTrace() { return this; }` 
> 
> https://github.com/openjdk/jdk/blob/caef0a589cb31e97e0ef9e8355d4aa3325908140/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L331-L333

@schlosna you are right, that is the reason that it was originally written that way. However, based on the comments made by @djelinski and @bradfordwetmore in the [JBS work item](https://bugs.openjdk.org/browse/JDK-8302017),  that wasn't needed to meet the mandates set by [RFC 8017](https://www.rfc-editor.org/rfc/rfc8017). In particular:

Note: Care must be taken to ensure that an opponent cannot
      distinguish the different error conditions in Step 3.g, whether by
      error message or timing, and, more generally, that an opponent
      cannot learn partial information about the encoded message EM.
      Otherwise, an opponent may be able to obtain useful information
      about the decryption of the ciphertext C, leading to a chosen-
      ciphertext attack such as the one observed by Manger [[MANGER](https://www.rfc-editor.org/rfc/rfc8017#ref-MANGER)].

Which only requires that the different error cases be indistinguishable. Success cases are allowed to be distinguishable from failures though.

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

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


From duke at openjdk.org  Mon Feb 27 19:14:33 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 19:14:33 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <gkzeT1xHwkU5FRYfes9v_JkrFTD8zMaozE-XOfv9jYQ=.ac173945-017f-468f-a333-9edba82151ab@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <gkzeT1xHwkU5FRYfes9v_JkrFTD8zMaozE-XOfv9jYQ=.ac173945-017f-468f-a333-9edba82151ab@github.com>
Message-ID: <L9NFTf7xiATWmDN2OIxKO_dd3V-6a1DLwFOr8JVpy-4=.acc6a88e-5aab-49f9-83fa-99481dfd77f1@github.com>

On Thu, 16 Feb 2023 18:31:30 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
>> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
>> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.
>
> test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 31:
> 
>> 29:  * @bug 8051498 8145849 8158978 8170282
>> 30:  * @summary JEP 244: TLS Application-Layer Protocol Negotiation Extension
>> 31:  * @compile MyX509ExtendedKeyManager.java
> 
> Suggest you to delete file `MyX509ExtendedKeyManager.java` if it is not needed anymore.

removed

> test/jdk/javax/net/ssl/TLSCommon/TLSWithEdDSA.java line 266:
> 
>> 264:      */
>> 265:     @Override
>> 266:     public SSLContext createClientSSLContext() throws Exception {
> 
> Why is this change needed, may be unintentional?

reverted the file

> test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Can you please check test `sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java` as this template test was a copy of it? Suggest you to check if this template copy can be removed now as we have other template classes for SSLSocket/SSLEngine client and server.

Removed SSLSocketSSLEngine.java

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

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


From duke at openjdk.org  Mon Feb 27 19:22:27 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 19:22:27 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <picZF3BW8ka23zdUi7fbCB97zcM03K3zD2yDcw0KFsU=.19ac056e-b0c6-4ecd-bcb7-e348f7edc556@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <picZF3BW8ka23zdUi7fbCB97zcM03K3zD2yDcw0KFsU=.19ac056e-b0c6-4ecd-bcb7-e348f7edc556@github.com>
Message-ID: <hPD2Hc-xNxb0oX9e16A1_9ZivyCwxr86hfK3b2m0SVY=.4f70e2e3-9462-4377-a4d2-752a671451b8@github.com>

On Thu, 16 Feb 2023 18:40:56 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
>> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
>> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.
>
> test/jdk/javax/net/ssl/templates/SSLContextTemplate.java line 395:
> 
>> 393:         CA_RSA_512( // for DisabledShortRSAKeys test
>> 394:                 "RSA",
>> 395:                 "-----BEGIN CERTIFICATE-----\n" +
> 
> Please add a comment with validity and algorithms similar to other entries in this enum. There are few other entries to update as well.

done

> test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 111:
> 
>> 109: 
>> 110:     @Override
>> 111:     public SSLContext createServerSSLContext() throws Exception {
> 
> revert this as well.

reverted

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

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


From duke at openjdk.org  Mon Feb 27 19:22:29 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 19:22:29 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <Iu-fOmpSyy4g4eMgUXHRqTphYxcyO5e_aaGM6-c5S-o=.d3fbef32-ba6d-4f86-ac58-f9ccebc130de@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <FZ76lJLMbHMhhaZJpKyOaY4rhW3f1XHJDoF8n3akogg=.bf350c8c-ad6d-4f7e-9676-17bd391514e2@github.com>
 <Iu-fOmpSyy4g4eMgUXHRqTphYxcyO5e_aaGM6-c5S-o=.d3fbef32-ba6d-4f86-ac58-f9ccebc130de@github.com>
Message-ID: <jQZe6iB1Xd_yZLTyB6Fu83xjaW3cgN0HUUz0sk1vHzs=.c5066fa6-85f5-4dfd-ada1-99fc494fce6a@github.com>

On Thu, 16 Feb 2023 18:59:15 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS13.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (C) 2021, 2023 THL A29 Limited, a Tencent company. All rights reserved.
>> 
>> Missing comma and this is not Oracle copyright so I am not sure if it should be modified.
>
> May be you can revert this file, change is unintentional.

reverted

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

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


From duke at openjdk.org  Mon Feb 27 20:12:47 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 20:12:47 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v2]
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <p8WMn7uiZtR_HPC8EOeOpem7Lm3OfmEQuNKBusuiab4=.bf44be3f-309e-48a8-ae1b-ce95975525c5@github.com>

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

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

 - updated certificate info
 - Merge branch 'master' into templates
 - reverted changes, removed SSLSocketSSLEngineTemplate, updated SSLEngineBadBufferArrayAccess.java
 - fixed compilation errors
 - Merge branch 'master' into templates
 - 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12555/files
  - new: https://git.openjdk.org/jdk/pull/12555/files/3a88fbeb..7e4c0740

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

  Stats: 24721 lines in 945 files changed: 13574 ins; 6583 del; 4564 mod
  Patch: https://git.openjdk.org/jdk/pull/12555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12555/head:pull/12555

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


From valeriep at openjdk.org  Mon Feb 27 22:54:52 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 27 Feb 2023 22:54:52 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <TyLb9DhpT9FM44g5i6LINM9oF7_utLHWttDakSI5XkE=.52e3e90d-b650-405e-9c44-575180b6d7b0@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h line 71:

> 69: 
> 70: #define CKA_NETSCAPE_BASE                       (0x80000000 + 0x4E534350)
> 71: /*             ^ now known as CKM_NSS   (CKM_VENDOR_DEFINED | NSSCK_VENDOR_NSS) */

nit: "                ^" part seems un-necessary.

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

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


From lucy at openjdk.org  Tue Feb 28 12:55:20 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 28 Feb 2023 12:55:20 GMT
Subject: Integrated: 8299817: [s390] AES-CTR mode intrinsic fails with multiple
 short update() calls
In-Reply-To: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
References: <T74rRuRd-JMM5a32uAJm5sQudG8l_pVjIs_vkzqK-fg=.76580ae6-dad7-4572-9b14-c839b342854f@github.com>
Message-ID: <tLyeWzPeSYv4JUp9XNgYhRrjVSzsW7Bll1J-I-SCgQc=.23cd6a79-df80-47e9-a46c-215c730c3953@github.com>

On Thu, 12 Jan 2023 14:29:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect.
> 
> This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand.
> 
> Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. 
> 
> **Reviews and comments are very much appreciated.**
> 
> @backwaterred could you please run some "official" s390 tests? Thanks.

This pull request has now been integrated.

Changeset: e144783e
Author:    Lutz Schmidt <lucy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e144783eb2d2a4437d0f992c964e34a932bfa54b
Stats:     729 lines in 5 files changed: 519 ins; 64 del; 146 mod

8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls

Reviewed-by: mbaesken, mdoerr

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

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


From mbaesken at openjdk.org  Tue Feb 28 15:25:11 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Feb 2023 15:25:11 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m needs
 CFRelease call in early potential CHECK_NULL return
Message-ID: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>

We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.

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

Commit messages:
 - JDK-8303354

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

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


From clanger at openjdk.org  Tue Feb 28 17:58:11 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 28 Feb 2023 17:58:11 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
Message-ID: <r0ML1QUKkITkOliCmLxEJCEgBHxVT07qZUS2k63e3Fk=.17b2fb36-0170-4dde-a882-84c360b3d30a@github.com>

On Tue, 28 Feb 2023 15:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.

Makes sense.

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

Marked as reviewed by clanger (Reviewer).

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


From eirbjo at gmail.com  Tue Feb 28 19:17:19 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 28 Feb 2023 20:17:19 +0100
Subject: Remove com.sun.jarsigner package with related options
Message-ID: <CA+pBWhu53JwD9QfRv8gkY6MSGv1unhJWbtUY8Z=53AxBpk1pfg@mail.gmail.com>

Hi,

The following PR suggests we remove the com.sun.jarsigner package with
related jarsigner options -altsigner and -altsignerpath options. These have
been deprecated since Java 9, for removal since 16:

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

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230228/5a11e807/attachment.htm>

From valeriep at openjdk.org  Tue Feb 28 23:00:05 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Feb 2023 23:00:05 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <mL4PBATk8MKIh9F7tlUc_MQYtLodhYOffwwgJ7vFbbY=.dab7da4e-896a-49d7-80fc-bd35208050c6@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java line 66:

> 64:  *   CK_ULONG ulPrfDataLen;
> 65:  *   CK_UTF8CHAR_PTR pPassword;
> 66:  *   CK_ULONG_PTR ulPasswordLen;

This does not match the one in PKCS#11 spec, the 'ulPasswordLen' should be CK_ULONG type.
I see that you added another CK_PKCS5_PBKD2_PARAMS class matching the spec definition. Is this to work around some existing bug? It seems strange to put the inconsistent type in the original class and the correct one in the new class.

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

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


From weijun.wang at oracle.com  Tue Feb 28 23:48:24 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Tue, 28 Feb 2023 23:48:24 +0000
Subject: Remove com.sun.jarsigner package with related options
In-Reply-To: <CA+pBWhu53JwD9QfRv8gkY6MSGv1unhJWbtUY8Z=53AxBpk1pfg@mail.gmail.com>
References: <CA+pBWhu53JwD9QfRv8gkY6MSGv1unhJWbtUY8Z=53AxBpk1pfg@mail.gmail.com>
Message-ID: <D429F5A7-1210-448D-913F-617DB8A9BBE4@oracle.com>

Hi Eirik,

I've filed https://bugs.openjdk.org/browse/JDK-8303410.

This needs a CSR and a release note. Do you volunteer to write them? If yes, you can write as comments in the PR and I can move them into JBS. You can look at the CSRs for the 2 related bugs.

Thanks,
Weijun

> On Feb 28, 2023, at 2:17 PM, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:
> 
> Hi,
> 
> The following PR suggests we remove the com.sun.jarsigner package with related jarsigner options -altsigner and -altsignerpath options. These have been deprecated since Java 9, for removal since 16:
> 
> https://github.com/openjdk/jdk/pull/12791
> 
> Thanks,
> Eirik.


From valeriep at openjdk.org  Tue Feb 28 23:51:51 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 28 Feb 2023 23:51:51 GMT
Subject: RFR: 8295425: Match the default priv exp length between SunPKCS11
 and other JDK providers [v2]
In-Reply-To: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>
References: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>
Message-ID: <yBdPYvjTwviENyIxRp1o2wWKcGGb7uZrqJaXiumrErQ=.344cfe90-6f38-46b0-98f4-650f88c78c4e@github.com>

> This changes the SunPKCS11 provider to use the same default private exponent length as the value used by SunJCE provider when initializing the DH Key Pair Generator impl using key size. In addition, the generated key pair will contain the specified parameters. If the supplied parameter does not contain the optional private exponent length, then we will leave it to the underlying PKCS11 library.
> 
> Thanks in advance for the review~
> Valerie

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

  fixed comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12466/files
  - new: https://git.openjdk.org/jdk/pull/12466/files/b22274ca..fa765f2f

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

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

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


From weijun at openjdk.org  Tue Feb 28 23:56:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Feb 2023 23:56:04 GMT
Subject: RFR: 8295425: Match the default priv exp length between SunPKCS11
 and other JDK providers [v2]
In-Reply-To: <yBdPYvjTwviENyIxRp1o2wWKcGGb7uZrqJaXiumrErQ=.344cfe90-6f38-46b0-98f4-650f88c78c4e@github.com>
References: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>
 <yBdPYvjTwviENyIxRp1o2wWKcGGb7uZrqJaXiumrErQ=.344cfe90-6f38-46b0-98f4-650f88c78c4e@github.com>
Message-ID: <llW_LsSOBY3hIOmYghF78VOi1_PfM4acU6t8qIqdDfQ=.2f3989ef-5102-48ae-8c06-ead64a3d0478@github.com>

On Tue, 28 Feb 2023 23:51:51 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This changes the SunPKCS11 provider to use the same default private exponent length as the value used by SunJCE provider when initializing the DH Key Pair Generator impl using key size. In addition, the generated key pair will contain the specified parameters. If the supplied parameter does not contain the optional private exponent length, then we will leave it to the underlying PKCS11 library.
>> 
>> Thanks in advance for the review~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment.

Marked as reviewed by weijun (Reviewer).

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

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