From jjiang at openjdk.org  Sat Jun  1 06:01:07 2024
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 1 Jun 2024 06:01:07 GMT
Subject: RFR: 8333046: Clean codes in sun.security.util.math
In-Reply-To: <CSgAyDNc7bdZe_MznJy1gBvH_MiD62Y0Rf394H32ryU=.6bcf28d7-82e3-4d2c-87a3-d3bec657cbf9@github.com>
References: <BrSJ75X4PDe9nLVDUpGeoeAVLDPMbGfJc-RmZleZ2Z4=.25426a76-27d4-4714-81aa-b3af2711f23a@github.com>
 <CSgAyDNc7bdZe_MznJy1gBvH_MiD62Y0Rf394H32ryU=.6bcf28d7-82e3-4d2c-87a3-d3bec657cbf9@github.com>
Message-ID: <P-Xd-SIiIA6WLp39HQF3MLS7_P7F_5DrP-RNy-aK5Xg=.f3580cde-75f0-41d1-93f8-f57bd1d65d69@github.com>

On Fri, 31 May 2024 13:53:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> A simple cleanup on the changes introduced by JDK-8329538.
>
> Looks good. Thanks for the cleanup.

@wangweij 
Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/19429#issuecomment-2143311471


From jjiang at openjdk.org  Sat Jun  1 06:01:07 2024
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 1 Jun 2024 06:01:07 GMT
Subject: Integrated: 8333046: Clean codes in sun.security.util.math
In-Reply-To: <BrSJ75X4PDe9nLVDUpGeoeAVLDPMbGfJc-RmZleZ2Z4=.25426a76-27d4-4714-81aa-b3af2711f23a@github.com>
References: <BrSJ75X4PDe9nLVDUpGeoeAVLDPMbGfJc-RmZleZ2Z4=.25426a76-27d4-4714-81aa-b3af2711f23a@github.com>
Message-ID: <5ctIjITGDduLYzJhAQOMeCRgcSZ1xWN8T7syoi9x6_A=.d42d1dc3-8ef1-4be5-9314-03c295d63295@github.com>

On Tue, 28 May 2024 14:42:13 GMT, John Jiang <jjiang at openjdk.org> wrote:

> A simple cleanup on the changes introduced by JDK-8329538.

This pull request has now been integrated.

Changeset: c0ce7d87
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0ce7d871f09df6bf4a21be3579f3f39a49a77bd
Stats:     9 lines in 6 files changed: 0 ins; 3 del; 6 mod

8333046: Clean codes in sun.security.util.math

Reviewed-by: weijun

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

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


From fguallini at openjdk.org  Mon Jun  3 09:54:16 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 3 Jun 2024 09:54:16 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v2]
In-Reply-To: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
Message-ID: <fU1Kn_9HJAU7tS_XEp9eTO9nShOjMrA-wb-BIuaB6rI=.218ce299-519a-4cfd-9e66-651c427e764d@github.com>

> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
> 
> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
> 3. Adding othervm flag to run in isolation.
> 
> Test runs in tier2

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

 - Merge branch 'openjdk:master' into JDK-8028127
 - Merge branch 'openjdk:master' into JDK-8028127
 - Regtest java/security/Security/SynchronizedAccess.java is  incorrect.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19480/files
  - new: https://git.openjdk.org/jdk/pull/19480/files/61b56f0a..1549cc59

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

  Stats: 5703 lines in 200 files changed: 3363 ins; 1647 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/19480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19480/head:pull/19480

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


From volker.simonis at gmail.com  Mon Jun  3 15:03:28 2024
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 3 Jun 2024 17:03:28 +0200
Subject: Status of project "Brisbane"?
Message-ID: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>

Hi,

What's the status of Project Brisbane? According to [1], the Project
was approved two month ago on April 4th, but until now I can't find it
listed on openjdk.org nor can I find a corresponding mailing list?

Best regards,
Volker

[1] https://mail.openjdk.org/pipermail/announce/2024-April/000350.html


From mdonovan at openjdk.org  Mon Jun  3 16:48:39 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 3 Jun 2024 16:48:39 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <DZNUaZvt51u1inYmCslRuMiIK0YLBo-OO64Tm-PiP6U=.d153eb33-f524-4aaf-927b-71ed496e39a3@github.com>
References: <DZNUaZvt51u1inYmCslRuMiIK0YLBo-OO64Tm-PiP6U=.d153eb33-f524-4aaf-927b-71ed496e39a3@github.com>
Message-ID: <HXX-m9uBa5xCxohuVss01cV4oWBMAQR9stLDwm-8drM=.a66da7f2-20db-4013-857f-e7f840b3dcd3@github.com>

> For this PR, I identified TLS tests that can fail due to hard-code certificates expiring. I updated those tests to use certificates that are generated programmatically. This includes adding some helper methods to the CertificateBuilder class to create builder objects with common default values. The builder can be further customized to meet the needs of the test. I also refactored some of the tests to put common functionality in base classes, further reducing duplicated code.
> 
> This PR does not include changes to SSLContextTemplate and the tests that use it. These tests require significant refactoring to incorporate programmatically generated certificates and should be a separate task.

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 five additional commits since the last revision:

 - made new methods for creating server and client certificates
 - Merge branch 'master' into certbuilding
 - renamed CertificateBuilder methods, updated tests, and removed duplication
 - Merge branch 'master' into certbuilding
 - 8325766: Review seclibs tests for cert expiry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18958/files
  - new: https://git.openjdk.org/jdk/pull/18958/files/d52e1265..b6ffb24b

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

  Stats: 102236 lines in 1995 files changed: 69895 ins; 20667 del; 11674 mod
  Patch: https://git.openjdk.org/jdk/pull/18958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18958/head:pull/18958

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


From mdonovan at openjdk.org  Mon Jun  3 16:53:03 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 3 Jun 2024 16:53:03 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <4H90D7UgJnkjpx1WLoSu3-r0d0KAGOtsr9F4O9Y4NQw=.bde1aa17-ace2-40d1-8639-5dd12d6d380a@github.com>
References: <DZNUaZvt51u1inYmCslRuMiIK0YLBo-OO64Tm-PiP6U=.d153eb33-f524-4aaf-927b-71ed496e39a3@github.com>
 <KYM2RmwTL7j-CjnPot_I8pgSC4RiDsG9sTAvoOqyTv4=.ab633852-0e1d-44ce-ae12-cad69afd2dd7@github.com>
 <GwlSbFIcMwTfPAxWfrCDD2KSLVWYeB58BYJgLSrXIKk=.7efacd66-6509-462d-afd1-2866bdcfbd33@github.com>
 <4H90D7UgJnkjpx1WLoSu3-r0d0KAGOtsr9F4O9Y4NQw=.bde1aa17-ace2-40d1-8639-5dd12d6d380a@github.com>
Message-ID: <kwlztnaoJMWmJbtmTy3GSBncCrY2ya7yiKhGlcu14Ds=.2416b0e8-48e8-4569-87c8-c31d1649afad@github.com>

On Thu, 23 May 2024 18:23:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I renamed the method. 
>> 
>> I don't want to over-generalize the code when I don't know what we'll need/want in the future. The tests in this PR just create CA and end-entity certs and with a couple exceptions, the tests in this PR are all of the tests that fail when the system clock is set to 2050. The exceptions are also client/server tests that don't need code signer and TSA certificates. 
>> 
>> When considering your comment, I went through the tests in this PR and found and removed some additional redundancy.
>
> The problem with generalizing an end-entity certificate is that there is not much you can generalize other than the cA field of the BasicConstraints extension being false (or not including the BC extension). Right now the newEndEntity() method looks like it is for TLS server certificates based on the KeyUsage extension (but it is also missing the KeyAgreement bit). But you could go further and add the EKU extension with the TLS server bit set. It shouldn't be used for TLS client certificates because they would have different KU extension values. Same for code signing end entity certificates. If you don't make it more specific, I feel that it is likely to be used to create certificates incorrectly.
> 
> So if you only need to create TLS server certs, I suggest renaming this method to newTLSServer() to make it clear it is for TLS server certs only. 
> 
> If a test needs to create certs which don't conform to a specific profile or have invalid fields, then it is probably better off calling CertificateBuilder methods itself rather than trying to create a helper method that satisfies all types of use cases.

The intent of these methods was not to create full certificates to satisfy lots of use cases but to create a CertificateBuilder object with the common fields (subject, serial number, validity, etc.) set. 

I see what you're saying about some of the extensions and created `newServerCertificateBuilder` and `newClientCertificateBuilder` methods that set key usage and the EKU extension for each.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18958#discussion_r1624772738


From valeriep at openjdk.org  Mon Jun  3 21:52:35 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 3 Jun 2024 21:52:35 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
Message-ID: <5IWr647dWoTsdzFl4-NjyYqdRRzu_LpVvpfAKgASSAU=.6bcf6d72-2553-422b-9b7a-6bad8aee5382@github.com>

On Wed, 29 May 2024 22:30:33 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
> 
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Fix cipher tests logging
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Implement integer constants as enum
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Arrange parameters of native methods evenly
>    
>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>    
>    If the call doesn't fit on a single line, use the following order:
>         long hSession,
>      [  long directIn,  byte[] in,  int inOfs,  int inLen,  ]
>         long directOut, byte[] out, int outOfs, int outLen
>    
>    [ ]: optional, not present in ...

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 621:

> 619:                     int flushFromPadBuffer;
> 620:                     int fillLen = getBytesToCompleteBlock(padBufferLen);
> 621:                     if (dataForP11Update >= padBufferLen + fillLen) {

Maybe use `if (inLen >= fillLen)` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625094389


From valeriep at openjdk.org  Mon Jun  3 22:16:54 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 3 Jun 2024 22:16:54 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
Message-ID: <sssXP-zOzpaB8FS_HXZeVarAXjt0Q9oJ63ceLXvJriY=.4a149b1e-74ee-4bd6-9606-55048039a4ca@github.com>

On Wed, 29 May 2024 22:30:33 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
> 
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Fix cipher tests logging
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Implement integer constants as enum
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Arrange parameters of native methods evenly
>    
>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>    
>    If the call doesn't fit on a single line, use the following order:
>         long hSession,
>      [  long directIn,  byte[] in,  int inOfs,  int inLen,  ]
>         long directOut, byte[] out, int outOfs, int outLen
>    
>    [ ]: optional, not present in ...

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 782:

> 780:                         int flushFromPadBuffer;
> 781:                         int fillLen = getBytesToCompleteBlock(padBufferLen);
> 782:                         if (dataForP11Update >= padBufferLen + fillLen) {

Same suggestion as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625111009


From mbalao at openjdk.org  Mon Jun  3 22:33:52 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 3 Jun 2024 22:33:52 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <5IWr647dWoTsdzFl4-NjyYqdRRzu_LpVvpfAKgASSAU=.6bcf6d72-2553-422b-9b7a-6bad8aee5382@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <5IWr647dWoTsdzFl4-NjyYqdRRzu_LpVvpfAKgASSAU=.6bcf6d72-2553-422b-9b7a-6bad8aee5382@github.com>
Message-ID: <LRiUT8nhqBJcq5gHzEdSrNsSV9fSmYR1WXETO-NT6qk=.e6937001-949e-4f17-bf31-c20c2c20293f@github.com>

On Mon, 3 Jun 2024 21:49:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
>> 
>>  - Improve handling when the token variant is unknown
>>    
>>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>>    the token CTS variant has not been specified in the configuration. Make
>>    NSS an exception, as we know that it uses the CS1 variant.
>>    
>>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>>    also slightly improving the error message.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Revert re-arrangement of native methods parameters
>>    
>>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>>    the copyright which is retained as 2024.
>>    
>>    NOTE: new calls of the same methods are retained in the re-arrangement
>>    style, as we didn't introduce this re-arrangement, it was already
>>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Fix cipher tests logging
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Implement integer constants as enum
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Arrange parameters of native methods evenly
>>    
>>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>>    
>>    If the call doesn't fit on a single line, use the following order:
>>         long hSession,
>>      [  long directIn,  byte[] in,  int inOfs,  int inLen,...
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 621:
> 
>> 619:                     int flushFromPadBuffer;
>> 620:                     int fillLen = getBytesToCompleteBlock(padBufferLen);
>> 621:                     if (dataForP11Update >= padBufferLen + fillLen) {
> 
> Maybe use `if (inLen >= fillLen)` ?

`dataForP11Update >= padBufferLen + fillLen` is not the same as `inLen >= fillLen` (the equivalent would be `inLen - newPadBufferLen >= fillLen`, but I personally find the proposed condition more clear). We will flush the entire `padBuffer` only if there are enough bytes in `inLen` to fill `padBuffer` with whatever we need (0 or more bytes) and fulfill the new buffering requirement. Regarding `fillLen > 0`, that is not strictly needed to flush the entire `padBuffer`. If we are buffering 3 blocks (e.g. for NSS), we may have 1 block buffered in `padBuffer` and `fillLen == 0` (no need to borrow to complete `padBuffer` to a multiple of a block size).

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 782:
> 
>> 780:                         int flushFromPadBuffer;
>> 781:                         int fillLen = getBytesToCompleteBlock(padBufferLen);
>> 782:                         if (dataForP11Update >= padBufferLen + fillLen) {
> 
> Same suggestion as before.

Replied above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625121859
PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625122157


From valeriep at openjdk.org  Mon Jun  3 23:53:07 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 3 Jun 2024 23:53:07 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
Message-ID: <3IeHSwsWzgLO4j8S5Kw9h4PdwXxuMvgh3qyY4zbyEZE=.d4cf8b41-d75d-4365-b436-3e78edd19c9e@github.com>

On Wed, 29 May 2024 22:30:33 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
> 
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Fix cipher tests logging
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Implement integer constants as enum
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Arrange parameters of native methods evenly
>    
>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>    
>    If the call doesn't fit on a single line, use the following order:
>         long hSession,
>      [  long directIn,  byte[] in,  int inOfs,  int inLen,  ]
>         long directOut, byte[] out, int outOfs, int outLen
>    
>    [ ]: optional, not present in ...

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 922:

> 920:                             0, out, outOfs, outLen);
> 921:                 }
> 922:                 if (paddingObj != null) {

Why not put this if-block inside an else-block of the `if (blockMode == Mode.CTS),` so it's clear that CTS mode won't use paddingObj?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625169386


From valeriep at openjdk.org  Tue Jun  4 00:28:04 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 4 Jun 2024 00:28:04 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
Message-ID: <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>

On Wed, 29 May 2024 22:30:33 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
> 
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Fix cipher tests logging
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Implement integer constants as enum
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Arrange parameters of native methods evenly
>    
>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>    
>    If the call doesn't fit on a single line, use the following order:
>         long hSession,
>      [  long directIn,  byte[] in,  int inOfs,  int inLen,  ]
>         long directOut, byte[] out, int outOfs, int outLen
>    
>    [ ]: optional, not present in ...

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 950:

> 948:                         0, out, (outOfs + k), (outLen - k));
> 949:                 if (blockMode == Mode.CTS) {
> 950:                     convertCTSVariant(null, out, outOfs + k);

The 3rd argument of the convertCTSVariant() method is the data length which is used to determine the penultimate block size? It looks incorrect to use `outOfs + k` for that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625186969


From mpowers at openjdk.org  Tue Jun  4 02:38:21 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Jun 2024 02:38:21 GMT
Subject: RFR: 8333364: Minor cleanup could be done in com.sun.crypto.provider
Message-ID: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>

https://bugs.openjdk.org/browse/JDK-8333364

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

Commit messages:
 - second iteration
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/19535/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19535&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333364
  Stats: 413 lines in 48 files changed: 47 ins; 102 del; 264 mod
  Patch: https://git.openjdk.org/jdk/pull/19535.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19535/head:pull/19535

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


From mpowers at openjdk.org  Tue Jun  4 02:40:01 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Jun 2024 02:40:01 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <z5I316KTvp0ibac14mkDscPfhsrdLsAp1n6kRZSPsnM=.e7f73bec-d923-41ee-8c67-380c686abb7b@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This is the last cleanup bug. After integration, the umbrella bug can be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19535#issuecomment-2146459913


From mbalao at openjdk.org  Tue Jun  4 02:58:12 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 4 Jun 2024 02:58:12 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <3IeHSwsWzgLO4j8S5Kw9h4PdwXxuMvgh3qyY4zbyEZE=.d4cf8b41-d75d-4365-b436-3e78edd19c9e@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <3IeHSwsWzgLO4j8S5Kw9h4PdwXxuMvgh3qyY4zbyEZE=.d4cf8b41-d75d-4365-b436-3e78edd19c9e@github.com>
Message-ID: <J1cjOOZdo7bhXn3bp_hboKsKSe_b-M7b1jqZMpdtDcg=.fd7ecd78-6367-4ddc-8132-e4d711266b6c@github.com>

On Mon, 3 Jun 2024 23:50:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
>> 
>>  - Improve handling when the token variant is unknown
>>    
>>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>>    the token CTS variant has not been specified in the configuration. Make
>>    NSS an exception, as we know that it uses the CS1 variant.
>>    
>>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>>    also slightly improving the error message.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Revert re-arrangement of native methods parameters
>>    
>>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>>    the copyright which is retained as 2024.
>>    
>>    NOTE: new calls of the same methods are retained in the re-arrangement
>>    style, as we didn't introduce this re-arrangement, it was already
>>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Fix cipher tests logging
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Implement integer constants as enum
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Arrange parameters of native methods evenly
>>    
>>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>>    
>>    If the call doesn't fit on a single line, use the following order:
>>         long hSession,
>>      [  long directIn,  byte[] in,  int inOfs,  int inLen,...
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 922:
> 
>> 920:                             0, out, outOfs, outLen);
>> 921:                 }
>> 922:                 if (paddingObj != null) {
> 
> Why not put this if-block inside an else-block of the `if (blockMode == Mode.CTS),` so it's clear that CTS mode won't use paddingObj?

I'd rather not add a level of indentation to the else-block, but perhaps we can add an else-if block to the `paddingObj != null` block. @franferrax, what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625266517


From mbalao at openjdk.org  Tue Jun  4 05:07:14 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 4 Jun 2024 05:07:14 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
Message-ID: <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>

On Tue, 4 Jun 2024 00:25:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet 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 ten additional commits since the last revision:
>> 
>>  - Improve handling when the token variant is unknown
>>    
>>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>>    the token CTS variant has not been specified in the configuration. Make
>>    NSS an exception, as we know that it uses the CS1 variant.
>>    
>>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>>    also slightly improving the error message.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Revert re-arrangement of native methods parameters
>>    
>>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>>    the copyright which is retained as 2024.
>>    
>>    NOTE: new calls of the same methods are retained in the re-arrangement
>>    style, as we didn't introduce this re-arrangement, it was already
>>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Fix cipher tests logging
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Implement integer constants as enum
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Arrange parameters of native methods evenly
>>    
>>    C_EncryptUpdate / C_DecryptUpdate / C_EncryptFinal / C_DecryptFinal
>>    
>>    If the call doesn't fit on a single line, use the following order:
>>         long hSession,
>>      [  long directIn,  byte[] in,  int inOfs,  int inLen,...
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 950:
> 
>> 948:                         0, out, (outOfs + k), (outLen - k));
>> 949:                 if (blockMode == Mode.CTS) {
>> 950:                     convertCTSVariant(null, out, outOfs + k);
> 
> The 3rd argument of the convertCTSVariant() method is the data length which is used to determine the penultimate block size? It looks incorrect to use `outOfs + k` for that?

`convertCTSVariant` needs the total output's length to determine the penultimate block size and do the slicing in the `out` array. The assumption here is that `outOfs` has the previously generated output (if any) starting at offset 0. In the CTS case, `k` has all the bytes (potentially) added to the output after flushing `padBuffer` with `C_EncryptUpdate` and all the bytes added after `C_EncryptFinal`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625350395


From peter.firmstone at zeus.net.au  Tue Jun  4 06:32:51 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 4 Jun 2024 16:32:51 +1000
Subject: Status of project "Brisbane"?
In-Reply-To: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>
References: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>
Message-ID: <3741f167-6d6d-4a16-b7f6-cc0824a3749e@zeus.net.au>

Hmm, makes me think of Bin Chickens... Project Bin Chick (cough) 
Brisbane.? Not as cool as "Blowfish", but hey we've got a lot of Ibis in 
here Brisbane, Aussies call them Bin Chickens.

Cheers,
  
Peter

On 4/06/2024 1:03 am, Volker Simonis wrote:
> Hi,
>
> What's the status of Project Brisbane? According to [1], the Project
> was approved two month ago on April 4th, but until now I can't find it
> listed on openjdk.org nor can I find a corresponding mailing list?
>
> Best regards,
> Volker
>
> [1] https://mail.openjdk.org/pipermail/announce/2024-April/000350.html


From syan at openjdk.org  Tue Jun  4 07:51:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Jun 2024 07:51:36 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
Message-ID: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>

Hi all,
  This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.

Thanks.

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

Commit messages:
 - 8333477: Delete extra empty spaces in Makefiles

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

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


From fferrari at openjdk.org  Tue Jun  4 12:53:11 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 4 Jun 2024 12:53:11 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <J1cjOOZdo7bhXn3bp_hboKsKSe_b-M7b1jqZMpdtDcg=.fd7ecd78-6367-4ddc-8132-e4d711266b6c@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <3IeHSwsWzgLO4j8S5Kw9h4PdwXxuMvgh3qyY4zbyEZE=.d4cf8b41-d75d-4365-b436-3e78edd19c9e@github.com>
 <J1cjOOZdo7bhXn3bp_hboKsKSe_b-M7b1jqZMpdtDcg=.fd7ecd78-6367-4ddc-8132-e4d711266b6c@github.com>
Message-ID: <y4ZCbcxnr-Z_sOkF9gUu22zDalC8G2eNbdlIKbYvKp4=.67a833f8-b153-4668-8721-0b420594eca3@github.com>

On Tue, 4 Jun 2024 02:55:30 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 922:
>> 
>>> 920:                             0, out, outOfs, outLen);
>>> 921:                 }
>>> 922:                 if (paddingObj != null) {
>> 
>> Why not put this if-block inside an else-block of the `if (blockMode == Mode.CTS),` so it's clear that CTS mode won't use paddingObj?
>
> I'd rather not add a level of indentation to the else-block, but perhaps we can add an else-if block to the `paddingObj != null` block. @franferrax, what do you think?

I wouldn't increase indentation either. Regarding adding an `else if`, I'm neither for nor against it, so I can do that if that's your preference.

I agree that added here in line **922** of encryption case, it would make it clearer that CTS mode won't use `paddingObj`:

https://github.com/openjdk/jdk/blob/997777e86c6fa03f070dcf0f219813c11cb480ce/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L917-L940

However, it would also introduce an asymmetry with the decryption case in line **965**, where we can't do the same, since the code inside the `else` of line **983** must also be executed in CTS mode:

https://github.com/openjdk/jdk/blob/997777e86c6fa03f070dcf0f219813c11cb480ce/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L957-L987

----

NOTE: this discussion also applies to the [same block in the `ByteBuffer` version of `P11Cipher::implDoFinal()`](https://github.com/openjdk/jdk/blob/997777e86c6fa03f070dcf0f219813c11cb480ce/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L1030-L1104): an `else if` can be introduced line **1036** but not in line **1079**.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1625948565


From syan at openjdk.org  Tue Jun  4 12:58:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Jun 2024 12:58:11 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <mQZHfdS_ok6O6dLazsSYrUXBkojv8GVa_HsRDxHbPzo=.38469b85-ad58-4500-aea7-8b22559a39d7@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

> /label build

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147467980


From mullan at openjdk.org  Tue Jun  4 13:00:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Jun 2024 13:00:22 GMT
Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API
 (Preview) [v78]
In-Reply-To: <0-Gw19nnQU8fGBp918-W6NQnGTSPV-jzcRkLTeLXOzI=.349347f5-1359-48bd-9105-d0cadafdbf0e@github.com>
References: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
 <0-Gw19nnQU8fGBp918-W6NQnGTSPV-jzcRkLTeLXOzI=.349347f5-1359-48bd-9105-d0cadafdbf0e@github.com>
Message-ID: <Z5yEWbaYyg-Sdp1-lOSiQPXkzQ02_cmmkN6bp1JitXw=.fa27bd2a-e9dd-4062-9580-e5a32457ad87@github.com>

On Thu, 23 May 2024 15:49:57 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 98 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
>    # Please enter a commit message to explain why this merge is necessary,
>    # especially if it merges an updated upstream into a topic branch.
>    #
>    # Lines starting with '#' will be ignored, and an empty message aborts
>    # the commit.
>  - javadoc formatting
>  - javadoc formatting
>  - remove unused declared exception in impls
>  - throw a ProviderException instead of "eating" an NSAE for Mac
>  - fix edge-case in consolidateKeyMaterial
>  - change thrown exception in engineDeriveKey in impl code
>  - edge case handling in deriveXXX methods and a few javadoc fixes
>  - getInstance javadoc consistency
>  - getInstance javadoc consistency
>  - ... and 88 more: https://git.openjdk.org/jdk/compare/3ee1f70a...ef718cbf

As part of this API, we should also add a KEY_DERIVATION enum to the `java.security.CryptoPrimitive` class.

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

PR Comment: https://git.openjdk.org/jdk/pull/18924#issuecomment-2147471151


From erikj at openjdk.org  Tue Jun  4 13:01:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Jun 2024 13:01:12 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <-zitWvnM2OMNoksPkobR-GY7ydETAQyBLwcrdcoiLWE=.c1e182c2-7b34-43e9-a96f-e3bf1b367f8f@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2096319123


From chagedorn at openjdk.org  Tue Jun  4 16:11:03 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 4 Jun 2024 16:11:03 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <R_z406J_82pGfaVP_3M5mmQ4zGsuS3H4rCPOr-a5Ti8=.ac63077f-25ac-4bb0-b486-b48e4ffffa12@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Looks good! Somehow the integrate command did not work.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2096615859


From syan at openjdk.org  Tue Jun  4 16:11:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Jun 2024 16:11:05 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <DsmVGdauwSMGAL3nJElLM_iKxrfM7vK4ujpQadJozNQ=.d43b195b-e33d-4a72-82ee-5cb6ecec6a2c@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Thanks for the review.

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147523325
PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147711173


From fferrari at openjdk.org  Tue Jun  4 18:00:27 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 4 Jun 2024 18:00:27 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Apply code-review suggestion
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/997777e8..0d82e7e9

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

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

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


From fferrari at openjdk.org  Tue Jun  4 18:02:58 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 4 Jun 2024 18:02:58 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <y4ZCbcxnr-Z_sOkF9gUu22zDalC8G2eNbdlIKbYvKp4=.67a833f8-b153-4668-8721-0b420594eca3@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <3IeHSwsWzgLO4j8S5Kw9h4PdwXxuMvgh3qyY4zbyEZE=.d4cf8b41-d75d-4365-b436-3e78edd19c9e@github.com>
 <J1cjOOZdo7bhXn3bp_hboKsKSe_b-M7b1jqZMpdtDcg=.fd7ecd78-6367-4ddc-8132-e4d711266b6c@github.com>
 <y4ZCbcxnr-Z_sOkF9gUu22zDalC8G2eNbdlIKbYvKp4=.67a833f8-b153-4668-8721-0b420594eca3@github.com>
Message-ID: <KOc2Z4UtbTlF-OMxp3AFNXHflIoPvwxz-60Xd7NBi7o=.36f74305-0dab-4bea-a755-feef6a3524b9@github.com>

On Tue, 4 Jun 2024 12:50:44 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> I'd rather not add a level of indentation to the else-block, but perhaps we can add an else-if block to the `paddingObj != null` block. @franferrax, what do you think?
>
> I wouldn't increase indentation either. Regarding adding an `else if`, I'm neither for nor against it, so I can do that if that's your preference.
> 
> I agree that added here in line **922** of the encryption case, it would make it clearer that CTS mode won't use `paddingObj`:
> 
> https://github.com/openjdk/jdk/blob/997777e86c6fa03f070dcf0f219813c11cb480ce/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L917-L940
> 
> However, it would also introduce an asymmetry with the decryption case in line **965**, where we can't do the same, since the code inside the `else` of line **983** must also be executed in CTS mode:
> 
> https://github.com/openjdk/jdk/blob/997777e86c6fa03f070dcf0f219813c11cb480ce/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L957-L987
> 
> ----
> 
> NOTE: this discussion also applies to the [same block in the `ByteBuffer` version of `P11Cipher::implDoFinal()`](https://github.com/openjdk/jdk/blob/997777e86c6fa03f070dcf0f219813c11cb480ce/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L1030-L1104): an `else if` could be introduced in line **1036** but not in line **1079**.

Changed in 0d82e7e9444f1807b271e16410a6dd83bda0613a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1626416664


From liach at openjdk.org  Wed Jun  5 00:55:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Jun 2024 00:55:03 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <wpd5Ftokgz40YYJdiWk4pJAwrR5HFWcc3Ok2uxoWPAI=.cb28a3a2-1814-4392-85ee-28b4e785fca9@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

@altrisi As trivial and low-effort as this seems, this is actually fixing some technical debt for legacy Makefiles last changed before 8e7a855ee8f085cee080395058f79c8a75bfef40 when trailing whitespace checks applied to Makefiles.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2148641237


From valeriep at openjdk.org  Wed Jun  5 01:27:58 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 01:27:58 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
 <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>
Message-ID: <pjreTvYi45gnSTCMHKk2OEYuMXpchWauE-oa9WH1NRw=.0d1954f1-4087-4e2a-864f-d988a80ab19c@github.com>

On Tue, 4 Jun 2024 05:04:45 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 950:
>> 
>>> 948:                         0, out, (outOfs + k), (outLen - k));
>>> 949:                 if (blockMode == Mode.CTS) {
>>> 950:                     convertCTSVariant(null, out, outOfs + k);
>> 
>> The 3rd argument of the convertCTSVariant() method is the data length which is used to determine the penultimate block size? It looks incorrect to use `outOfs + k` for that?
>
> `convertCTSVariant` needs the total output's length to determine the penultimate block size and do the slicing in the `out` array. The assumption here is that `outOfs` has the previously generated output (if any) starting at offset 0. In the CTS case, `k` has all the bytes (potentially) added to the output after flushing `padBuffer` with `C_EncryptUpdate` and all the bytes added after `C_EncryptFinal`.

I understand the meaning of `k`. It seems that the code here assumes `outOfs = 0`, but this may not always be the case when operating on user-supplied output byte array, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1626806896


From duke at openjdk.org  Wed Jun  5 02:07:06 2024
From: duke at openjdk.org (duke)
Date: Wed, 5 Jun 2024 02:07:06 GMT
Subject: Withdrawn: 8320219: Actually resolve issues with goto labels in sspi
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <3EgYRJZ_JRqp7iWxyNXRf_edyeLsXsEe5zJT0D8sbVQ=.b51aa956-d408-4dbb-a612-2909027681a5@github.com>

On Thu, 16 Nov 2023 04:22:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

This pull request has been closed without being integrated.

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

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


From valeriep at openjdk.org  Wed Jun  5 02:09:01 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 02:09:01 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <LRiUT8nhqBJcq5gHzEdSrNsSV9fSmYR1WXETO-NT6qk=.e6937001-949e-4f17-bf31-c20c2c20293f@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <5IWr647dWoTsdzFl4-NjyYqdRRzu_LpVvpfAKgASSAU=.6bcf6d72-2553-422b-9b7a-6bad8aee5382@github.com>
 <LRiUT8nhqBJcq5gHzEdSrNsSV9fSmYR1WXETO-NT6qk=.e6937001-949e-4f17-bf31-c20c2c20293f@github.com>
Message-ID: <R50CvSuOWr9e1iuKjXdYLjPo22JQpjLaLGQSufoeOkw=.787f8451-646c-4efd-82d6-01d4e88fef7b@github.com>

On Mon, 3 Jun 2024 22:26:04 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 621:
>> 
>>> 619:                     int flushFromPadBuffer;
>>> 620:                     int fillLen = getBytesToCompleteBlock(padBufferLen);
>>> 621:                     if (dataForP11Update >= padBufferLen + fillLen) {
>> 
>> Maybe use `if (inLen >= fillLen)` ?
>
> `dataForP11Update >= padBufferLen + fillLen` is not the same as `inLen >= fillLen` (the equivalent would be `inLen - newPadBufferLen >= fillLen`, but I personally find the proposed condition more clear). We will flush the entire `padBuffer` only if there are enough bytes in `inLen` to fill `padBuffer` with whatever we need (0 or more bytes) and fulfill the new buffering requirement. Regarding `fillLen > 0`, that is not strictly needed to flush the entire `padBuffer`. If we are buffering 3 blocks (e.g. for NSS), we may have 1 block buffered in `padBuffer` and `fillLen == 0` (no need to borrow to complete `padBuffer` to a multiple of a block size).

I see, thanks for the explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1626829385


From valeriep at openjdk.org  Wed Jun  5 02:45:00 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 02:45:00 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
Message-ID: <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>

On Tue, 4 Jun 2024 18:00:27 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code-review suggestion
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1183:

> 1181:                 // Temporary buffer to the penultimate block
> 1182:                 ciphertextBuf.put(start, tmp);
> 1183:             } else {

Personally, I find it easier to follow if this code block follows the decrypt case (line 1184-1190), the allocated `tmp` could be smaller, e.g.
Suggestion:

                byte[] tmp = new byte[pad];
                // .... pp[pp] ffff -> .... ffff pp[pp]
                ciphertextBuf.get(start, tmp);
                ciphertextBuf.put(start, ciphertextBuf, end - blockSize, blockSize);
                ciphertextBuf.put(end - pad, tmp);

Have you considered this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1626847217


From mbalao at openjdk.org  Wed Jun  5 03:30:57 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 5 Jun 2024 03:30:57 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <pjreTvYi45gnSTCMHKk2OEYuMXpchWauE-oa9WH1NRw=.0d1954f1-4087-4e2a-864f-d988a80ab19c@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
 <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>
 <pjreTvYi45gnSTCMHKk2OEYuMXpchWauE-oa9WH1NRw=.0d1954f1-4087-4e2a-864f-d988a80ab19c@github.com>
Message-ID: <pnmdgkin-gYGdkGEDeW0Dcg_d17aq4fUKQI8Wruiu6o=.9864a1fa-87ab-4302-baaf-2563a281d64c@github.com>

On Wed, 5 Jun 2024 01:25:24 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> `convertCTSVariant` needs the total output's length to determine the penultimate block size and do the slicing in the `out` array. The assumption here is that `outOfs` has the previously generated output (if any) starting at offset 0. In the CTS case, `k` has all the bytes (potentially) added to the output after flushing `padBuffer` with `C_EncryptUpdate` and all the bytes added after `C_EncryptFinal`.
>
> I understand the meaning of `k`. It seems that the code here assumes `outOfs = 0`, but this may not always be the case when operating on user-supplied output byte array, right?

The code does not assume that `outOfs = 0` but that the content of `out` (between 0 and `outOfs`) is previously generated output of a multi-part operation (not the whole output but one that is multiple of the block size). `outOfs + k` is an offset that we need to know and pass to `convertCTSVariant` for the `out` slicing. @franferrax , do you see possible to determine the penultimate block size from `k` only? (i.e. `int pad = k % blockSize;`) This would be more resilient for handling a user-supplied value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1626870291


From mbalao at openjdk.org  Wed Jun  5 03:51:59 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 5 Jun 2024 03:51:59 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
 <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>
Message-ID: <8XTkOdTnZ5niN3hvVgxbqDfNRPxEmlwgvFHbZ_EIOkg=.5f4445b8-50e6-4d98-8c32-6b58e204909b@github.com>

On Wed, 5 Jun 2024 02:41:35 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply code-review suggestion
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1183:
> 
>> 1181:                 // Temporary buffer to the penultimate block
>> 1182:                 ciphertextBuf.put(start, tmp);
>> 1183:             } else {
> 
> Personally, I find it easier to follow if this code block follows the decrypt case (line 1184-1190), the allocated `tmp` could be smaller, e.g.
> Suggestion:
> 
>                 byte[] tmp = new byte[pad];
>                 // .... pp[pp] ffff -> .... ffff pp[pp]
>                 ciphertextBuf.get(start, tmp);
>                 ciphertextBuf.put(start, ciphertextBuf, end - blockSize, blockSize);
>                 ciphertextBuf.put(end - pad, tmp);
> 
> Have you considered this?

I have no personal preference, but would suggest that if we change it to cut the pad, we keep the decryption case aligned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1626883413


From thartmann at openjdk.org  Wed Jun  5 11:21:09 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 5 Jun 2024 11:21:09 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v12]
In-Reply-To: <2HF_LGpK7B6i1UcgJ8g9JgzGF27gVAHZkGnVQk-Fo4w=.98339735-cd89-4059-a449-6a4911e9af41@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
 <2HF_LGpK7B6i1UcgJ8g9JgzGF27gVAHZkGnVQk-Fo4w=.98339735-cd89-4059-a449-6a4911e9af41@github.com>
Message-ID: <D7byoGb9coTCn4rna3tBqZwZuyDkl5cET7cpSDem99Q=.d9e03c2a-8f26-4a43-a650-d0f26c2ab125@github.com>

On Wed, 22 May 2024 14:19:36 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Volodymyr Paprotski 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 17 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ecc-montgomery
>>  - shenandoah verifier
>>  - comments from Sandhya
>>  - whitespace
>>  - add message back
>>  - whitespace
>>  - Use AffinePoint to exit Montgomery domain
>>    
>>    Style notes:
>>    Affine.equals()
>>        - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
>>    Affine.getX(boolean)|getY(boolean)
>>        - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
>>        - needed to convert Affine to Projective (need to stay in montgomery domain)
>>    ECOperations.PointMultiplier
>>       - changes could probably be restored to original (since ProjectivePoint handling no longer required)
>>       - consider these changes an improvement? (fewer nested classes)
>>       - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)
>>  - whitespace
>>  - Comments from Tony and Jatin
>>  - Comments from Jatin and Tony
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/1adfff34...b1a33004
>
> Thanks Tobi!

Unfortunately, this caused a performance regression, see [JDK-8333583](https://bugs.openjdk.org/browse/JDK-8333583). @vpaprotsk, please have a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2149576062


From fferrari at openjdk.org  Wed Jun  5 12:57:59 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 12:57:59 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <8XTkOdTnZ5niN3hvVgxbqDfNRPxEmlwgvFHbZ_EIOkg=.5f4445b8-50e6-4d98-8c32-6b58e204909b@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
 <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>
 <8XTkOdTnZ5niN3hvVgxbqDfNRPxEmlwgvFHbZ_EIOkg=.5f4445b8-50e6-4d98-8c32-6b58e204909b@github.com>
Message-ID: <pZv7Zzu2H7Gr606N2twnbN5TysXo9QIYiLRvOwAw5a4=.d331c785-e91e-46bb-968d-ad1a4f05f7b2@github.com>

On Wed, 5 Jun 2024 03:49:31 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1183:
>> 
>>> 1181:                 // Temporary buffer to the penultimate block
>>> 1182:                 ciphertextBuf.put(start, tmp);
>>> 1183:             } else {
>> 
>> Personally, I find it easier to follow if this code block follows the decrypt case (line 1184-1190), the allocated `tmp` could be smaller, e.g.
>> Suggestion:
>> 
>>                 byte[] tmp = new byte[pad];
>>                 // .... pp[pp] ffff -> .... ffff pp[pp]
>>                 ciphertextBuf.get(start, tmp);
>>                 ciphertextBuf.put(start, ciphertextBuf, end - blockSize, blockSize);
>>                 ciphertextBuf.put(end - pad, tmp);
>> 
>> Have you considered this?
>
> I have no personal preference, but would suggest that if we change it to cut the pad, we keep the decryption case aligned.

What I like about this suggestion is that it allows unifying the repeated logic: the two blocks inside `if (encrypt)` and the corresponding `else` would become almost identical, allowing an additional abstraction. How about the following?


    private void convertCTSVariant(ByteBuffer ciphertextBuf,
            byte[] ciphertextArr, int end) {
        // [...]
        // [...] omitted code
        // [...]
        if (ciphertextBuf != null) {
            pad = pad == 0 ? blockSize : pad;
            if (encrypt) {
                // .... pp[pp] ffff -> .... ffff pp[pp]
                swapLastTwoBlocks(ciphertextBuf, end, pad, blockSize);
            } else {
                // .... ffff pp[pp] -> .... pp[pp] ffff
                swapLastTwoBlocks(ciphertextBuf, end, blockSize, pad);
            }
        }
    }

    private static void swapLastTwoBlocks(ByteBuffer buffer, int end,
            int prevBlockLen, int lastBlockLen) {
        // .... prevBlock lastBlock -> .... lastBlock prevBlock
        int prevBlockStart = end - prevBlockLen - lastBlockLen;
        byte[] prevBlockBackup = new byte[prevBlockLen];
        buffer.get(prevBlockStart, prevBlockBackup);
        buffer.put(prevBlockStart, buffer, end - lastBlockLen, lastBlockLen);
        buffer.put(end - prevBlockLen, prevBlockBackup);
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1627704892


From mbalao at openjdk.org  Wed Jun  5 14:24:57 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 5 Jun 2024 14:24:57 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <pZv7Zzu2H7Gr606N2twnbN5TysXo9QIYiLRvOwAw5a4=.d331c785-e91e-46bb-968d-ad1a4f05f7b2@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
 <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>
 <8XTkOdTnZ5niN3hvVgxbqDfNRPxEmlwgvFHbZ_EIOkg=.5f4445b8-50e6-4d98-8c32-6b58e204909b@github.com>
 <pZv7Zzu2H7Gr606N2twnbN5TysXo9QIYiLRvOwAw5a4=.d331c785-e91e-46bb-968d-ad1a4f05f7b2@github.com>
Message-ID: <efGCR6BjyeCOkjEKzBNsJGdy9huith__rywRoATEUnk=.a5185031-2099-4cee-9884-3f316d59b79c@github.com>

On Wed, 5 Jun 2024 12:54:45 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> I have no personal preference, but would suggest that if we change it to cut the pad, we keep the decryption case aligned.
>
> What I like about this suggestion is that it allows unifying the repeated logic: the two blocks inside `if (encrypt)` and the corresponding `else` would become almost identical, allowing an additional abstraction. How about the following?
> 
> 
>     private void convertCTSVariant(ByteBuffer ciphertextBuf,
>             byte[] ciphertextArr, int end) {
>         // [...]
>         // [...] omitted code
>         // [...]
>         if (ciphertextBuf != null) {
>             pad = pad == 0 ? blockSize : pad;
>             if (encrypt) {
>                 // .... pp[pp] ffff -> .... ffff pp[pp]
>                 swapLastTwoBlocks(ciphertextBuf, end, pad, blockSize);
>             } else {
>                 // .... ffff pp[pp] -> .... pp[pp] ffff
>                 swapLastTwoBlocks(ciphertextBuf, end, blockSize, pad);
>             }
>         }
>     }
> 
>     private static void swapLastTwoBlocks(ByteBuffer buffer, int end,
>             int prevBlockLen, int lastBlockLen) {
>         // .... prevBlock lastBlock -> .... lastBlock prevBlock
>         int prevBlockStart = end - prevBlockLen - lastBlockLen;
>         byte[] prevBlockBackup = new byte[prevBlockLen];
>         buffer.get(prevBlockStart, prevBlockBackup);
>         buffer.put(prevBlockStart, buffer, end - lastBlockLen, lastBlockLen);
>         buffer.put(end - prevBlockLen, prevBlockBackup);
>     }

Looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1627887918


From kdriver at openjdk.org  Wed Jun  5 14:47:45 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 5 Jun 2024 14:47:45 GMT
Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API
 (Preview) [v79]
In-Reply-To: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
References: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
Message-ID: <Wt6sxg0e8gCamiGRHcAMGmZMrrdoR1AzLq7jLDsfEFU=.23ce5108-9cab-40d1-b5a2-d7b8bb963805@github.com>

> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478).

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:

 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - javadoc formatting
 - javadoc formatting
 - remove unused declared exception in impls
 - throw a ProviderException instead of "eating" an NSAE for Mac
 - fix edge-case in consolidateKeyMaterial
 - change thrown exception in engineDeriveKey in impl code
 - edge case handling in deriveXXX methods and a few javadoc fixes
 - getInstance javadoc consistency
 - ... and 89 more: https://git.openjdk.org/jdk/compare/326dbb1b...f30dad97

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

Changes: https://git.openjdk.org/jdk/pull/18924/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18924&range=78
  Stats: 2246 lines in 14 files changed: 2245 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18924/head:pull/18924

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


From ascarpino at openjdk.org  Wed Jun  5 16:20:21 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 5 Jun 2024 16:20:21 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
Message-ID: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>

Hi,

I need a review for this simple change to fix a threading problem with the test. The server thread was not completing before the check occurred on the main thread.  The failure showed up in windows and macos, but not linux.  With this fix, running 100 times, windows & macos showed no failures.

Tony

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

Commit messages:
 - fiddle with msgs
 - blank line
 - cleanup
 - Update
 - Add join() to Server.done()
 - remove problemlist entry

Changes: https://git.openjdk.org/jdk/pull/19553/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19553&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326705
  Stats: 36 lines in 3 files changed: 13 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/19553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19553/head:pull/19553

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


From valeriep at openjdk.org  Wed Jun  5 18:32:58 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 18:32:58 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <pnmdgkin-gYGdkGEDeW0Dcg_d17aq4fUKQI8Wruiu6o=.9864a1fa-87ab-4302-baaf-2563a281d64c@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
 <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>
 <pjreTvYi45gnSTCMHKk2OEYuMXpchWauE-oa9WH1NRw=.0d1954f1-4087-4e2a-864f-d988a80ab19c@github.com>
 <pnmdgkin-gYGdkGEDeW0Dcg_d17aq4fUKQI8Wruiu6o=.9864a1fa-87ab-4302-baaf-2563a281d64c@github.com>
Message-ID: <G0GOSaXCK6bvhIJPKjrANVB9ZWhOxy5E2fcwlyxLXBA=.fa08c952-ec71-4b17-a933-fac26e1df06f@github.com>

On Wed, 5 Jun 2024 03:27:51 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> I understand the meaning of `k`. It seems that the code here assumes `outOfs = 0`, but this may not always be the case when operating on user-supplied output byte array, right?
>
> The code does not assume that `outOfs = 0` but that the content of `out` (between 0 and `outOfs`) is previously generated output of a multi-part operation (not the whole output but one that is multiple of the block size). `outOfs + k` is an offset that we need to know and pass to `convertCTSVariant` for the `out` slicing. @franferrax , do you see possible to determine the penultimate block size from `k` only? (i.e. `int pad = k % blockSize;`) This would be more resilient for handling a user-supplied value.

I am not sure that we can make the assumption `the content of out (between 0 and outOfs) is previously generated output of a multi-part operation`. It's possible that the output buffer starts at a non-zero offset for storing the encrypt/decrypted data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628244076


From valeriep at openjdk.org  Wed Jun  5 18:32:58 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 18:32:58 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <efGCR6BjyeCOkjEKzBNsJGdy9huith__rywRoATEUnk=.a5185031-2099-4cee-9884-3f316d59b79c@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
 <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>
 <8XTkOdTnZ5niN3hvVgxbqDfNRPxEmlwgvFHbZ_EIOkg=.5f4445b8-50e6-4d98-8c32-6b58e204909b@github.com>
 <pZv7Zzu2H7Gr606N2twnbN5TysXo9QIYiLRvOwAw5a4=.d331c785-e91e-46bb-968d-ad1a4f05f7b2@github.com>
 <efGCR6BjyeCOkjEKzBNsJGdy9huith__rywRoATEUnk=.a5185031-2099-4cee-9884-3f316d59b79c@github.com>
Message-ID: <kXIUBnKg56Pkf2ZdNIxgXSe2UfybvdBj2NpYq616V-I=.de80985d-8aff-4ee1-b2a2-1e01c40eae91@github.com>

On Wed, 5 Jun 2024 14:21:57 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> What I like about this suggestion is that it allows unifying the repeated logic: the two blocks inside `if (encrypt)` and the corresponding `else` would become almost identical, allowing an additional abstraction. How about the following?
>> 
>> 
>>     private void convertCTSVariant(ByteBuffer ciphertextBuf,
>>             byte[] ciphertextArr, int end) {
>>         // [...]
>>         // [...] omitted code
>>         // [...]
>>         if (ciphertextBuf != null) {
>>             pad = pad == 0 ? blockSize : pad;
>>             if (encrypt) {
>>                 // .... pp[pp] ffff -> .... ffff pp[pp]
>>                 swapLastTwoBlocks(ciphertextBuf, end, pad, blockSize);
>>             } else {
>>                 // .... ffff pp[pp] -> .... pp[pp] ffff
>>                 swapLastTwoBlocks(ciphertextBuf, end, blockSize, pad);
>>             }
>>         }
>>     }
>> 
>>     private static void swapLastTwoBlocks(ByteBuffer buffer, int end,
>>             int prevBlockLen, int lastBlockLen) {
>>         // .... prevBlock lastBlock -> .... lastBlock prevBlock
>>         int prevBlockStart = end - prevBlockLen - lastBlockLen;
>>         byte[] prevBlockBackup = new byte[prevBlockLen];
>>         buffer.get(prevBlockStart, prevBlockBackup);
>>         buffer.put(prevBlockStart, buffer, end - lastBlockLen, lastBlockLen);
>>         buffer.put(end - prevBlockLen, prevBlockBackup);
>>     }
>
> Looks good to me.

Yes, I prefer this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628246471


From valeriep at openjdk.org  Wed Jun  5 18:32:57 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 18:32:57 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
Message-ID: <qhC86TU_EXJFd9MsOUlwOWVyDEZEio9ERTmhVrrFznQ=.77f7366c-51ea-404a-baba-4488847f671f@github.com>

On Tue, 4 Jun 2024 18:00:27 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code-review suggestion
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

Well, given the time frame, maybe we should re-target the CSR to jdk 24?

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2150699848


From fferrari at openjdk.org  Wed Jun  5 19:06:14 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 19:06:14 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:

 - Fix penultimate block length calculation
   
   It is not correct to calculate the penultimate block length based on
   the output array offset, since the output array can include arbitrary
   user-supplied data.
   
   Add a test case to check this fix.
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Extract swapLastTwoBlocks() unified logic
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Merge 'openjdk/master' into JDK-8330843
 - Apply code-review suggestion
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Improve handling when the token variant is unknown
   
   Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
   the token CTS variant has not been specified in the configuration. Make
   NSS an exception, as we know that it uses the CS1 variant.
   
   Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
   a cleaner entry in the main switch statement of pkcs11.Config::parse(),
   also slightly improving the error message.
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Merge 'openjdk/master' into JDK-8330843
 - Revert re-arrangement of native methods parameters
   
   This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
   the copyright which is retained as 2024.
   
   NOTE: new calls of the same methods are retained in the re-arrangement
   style, as we didn't introduce this re-arrangement, it was already
   present in most of the calls inside ::implUpdate() and ::implDoFinal().
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Merge 'openjdk/master' into JDK-8330843
 - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - ... and 3 more: https://git.openjdk.org/jdk/compare/f2bfb671...37d6eb80

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/0d82e7e9..37d6eb80

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

  Stats: 18948 lines in 507 files changed: 11911 ins; 4963 del; 2074 mod
  Patch: https://git.openjdk.org/jdk/pull/18898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18898/head:pull/18898

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


From mbalao at openjdk.org  Wed Jun  5 19:06:14 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 5 Jun 2024 19:06:14 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <G0GOSaXCK6bvhIJPKjrANVB9ZWhOxy5E2fcwlyxLXBA=.fa08c952-ec71-4b17-a933-fac26e1df06f@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
 <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>
 <pjreTvYi45gnSTCMHKk2OEYuMXpchWauE-oa9WH1NRw=.0d1954f1-4087-4e2a-864f-d988a80ab19c@github.com>
 <pnmdgkin-gYGdkGEDeW0Dcg_d17aq4fUKQI8Wruiu6o=.9864a1fa-87ab-4302-baaf-2563a281d64c@github.com>
 <G0GOSaXCK6bvhIJPKjrANVB9ZWhOxy5E2fcwlyxLXBA=.fa08c952-ec71-4b17-a933-fac26e1df06f@github.com>
Message-ID: <4wyN_0ND9f-2JzOVIOtDqL8oiGpZ-3kf_2r_DRT_-rc=.3a73f5f9-a33f-4df8-8788-e2ed2c401808@github.com>

On Wed, 5 Jun 2024 18:27:11 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> The code does not assume that `outOfs = 0` but that the content of `out` (between 0 and `outOfs`) is previously generated output of a multi-part operation (not the whole output but one that is multiple of the block size). `outOfs + k` is an offset that we need to know and pass to `convertCTSVariant` for the `out` slicing. @franferrax , do you see possible to determine the penultimate block size from `k` only? (i.e. `int pad = k % blockSize;`) This would be more resilient for handling a user-supplied value.
>
> I am not sure that we can make the assumption `the content of out (between 0 and outOfs) is previously generated output of a multi-part operation`. It's possible that the output buffer starts at a non-zero offset for storing the encrypt/decrypted data.

Yes, that's why I asked @franferrax if we could change it to something like `int pad = k % blockSize;`. We will take that approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628299169


From fferrari at openjdk.org  Wed Jun  5 19:06:15 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 19:06:15 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v4]
In-Reply-To: <kXIUBnKg56Pkf2ZdNIxgXSe2UfybvdBj2NpYq616V-I=.de80985d-8aff-4ee1-b2a2-1e01c40eae91@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <tADSCksOqZBun-8X5AD-KRvDV1cdnFW-m0e6Xb_JzjU=.8ca04e1c-8e74-42f5-84ee-f676970173ad@github.com>
 <OBWOul8DZvJ3xg6wklFSifUIjKoANWQdg4fd21oTDEU=.ef3febea-7d1f-4c64-80ae-e3b18c2c0795@github.com>
 <8XTkOdTnZ5niN3hvVgxbqDfNRPxEmlwgvFHbZ_EIOkg=.5f4445b8-50e6-4d98-8c32-6b58e204909b@github.com>
 <pZv7Zzu2H7Gr606N2twnbN5TysXo9QIYiLRvOwAw5a4=.d331c785-e91e-46bb-968d-ad1a4f05f7b2@github.com>
 <efGCR6BjyeCOkjEKzBNsJGdy9huith__rywRoATEUnk=.a5185031-2099-4cee-9884-3f316d59b79c@github.com>
 <kXIUBnKg56Pkf2ZdNIxgXSe2UfybvdBj2NpYq616V-I=.de80985d-8aff-4ee1-b2a2-1e01c40eae91@github.com>
Message-ID: <nAVl4jcJgOs_uncw7dZfyixByEtAWtZOeGUVX21ZxUg=.17145386-1fb6-41ab-a9b4-d552556a4ce3@github.com>

On Wed, 5 Jun 2024 18:28:07 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Looks good to me.
>
> Yes, I prefer this.

Done in 5fe83b20a10002c4c48e90321e69629bbd0aa9ff.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628299501


From fferrari at openjdk.org  Wed Jun  5 19:15:57 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 19:15:57 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v3]
In-Reply-To: <G0GOSaXCK6bvhIJPKjrANVB9ZWhOxy5E2fcwlyxLXBA=.fa08c952-ec71-4b17-a933-fac26e1df06f@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <CwvToLjerHoRIHcSPwSjRguU1Lau5n-rDGOKSh-Azm0=.bb8ff43e-ef04-4b51-9ab3-bc3e245b699b@github.com>
 <NhxxGw5dSRyUMMFoKJrkiGW6grSNefm3PV0eOr2eNYo=.53fcb583-f03e-4c8e-8736-46d572f10415@github.com>
 <S2lM9txCRCCqOYc_WBZFFenZzyaLORBwt2IdjnHbuC0=.339306aa-ef1a-482a-ba87-f7cc2ed1063a@github.com>
 <pjreTvYi45gnSTCMHKk2OEYuMXpchWauE-oa9WH1NRw=.0d1954f1-4087-4e2a-864f-d988a80ab19c@github.com>
 <pnmdgkin-gYGdkGEDeW0Dcg_d17aq4fUKQI8Wruiu6o=.9864a1fa-87ab-4302-baaf-2563a281d64c@github.com>
 <G0GOSaXCK6bvhIJPKjrANVB9ZWhOxy5E2fcwlyxLXBA=.fa08c952-ec71-4b17-a933-fac26e1df06f@github.com>
Message-ID: <H0IvwDM76nbFGjPgdNZJmCEmB4JO09Mm8udFZVbvmgY=.afb6cf81-b5fe-4e84-9e26-d6bb08b08c12@github.com>

On Wed, 5 Jun 2024 18:27:11 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> The code does not assume that `outOfs = 0` but that the content of `out` (between 0 and `outOfs`) is previously generated output of a multi-part operation (not the whole output but one that is multiple of the block size). `outOfs + k` is an offset that we need to know and pass to `convertCTSVariant` for the `out` slicing. @franferrax , do you see possible to determine the penultimate block size from `k` only? (i.e. `int pad = k % blockSize;`) This would be more resilient for handling a user-supplied value.
>
> I am not sure that we can make the assumption `the content of out (between 0 and outOfs) is previously generated output of a multi-part operation`. It's possible that the output buffer starts at a non-zero offset for storing the encrypt/decrypted data.

@valeriepeng you are right, that assumption was wrong, we fixed it in 37d6eb805a3ca93e331eae9fec0f6f657758bc3e, and also modified `TestCipherTextStealingMultipart.java` to exercise the issue.

Instead of `k`, we used `padBufferLen` to determine the penultimate block size. Please note that the data that can make a difference for the penultimate block size calculation is always available in `padBuffer`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628314682


From valeriep at openjdk.org  Wed Jun  5 19:23:59 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 19:23:59 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
Message-ID: <S7kWQYt4BkzEAcrFpvwbFyn1mKezXDlHo25JnEahx0I=.b83e90a8-74df-46d6-b413-1882d8b9c6d4@github.com>

On Wed, 5 Jun 2024 19:06:14 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:
> 
>  - Fix penultimate block length calculation
>    
>    It is not correct to calculate the penultimate block length based on
>    the output array offset, since the output array can include arbitrary
>    user-supplied data.
>    
>    Add a test case to check this fix.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Extract swapLastTwoBlocks() unified logic
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Apply code-review suggestion
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    C...

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 647:

> 645:             return Enum.valueOf(enumClass, value);
> 646:         } catch (IllegalArgumentException ignored) {
> 647:             throw excToken(keyword + " must be one of " +

nit: since we are using the `value` for enum conversion, maybe using it instead of `keyword` for the error message? This has the benefit of showing what the parsed value is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628325604


From valeriep at openjdk.org  Wed Jun  5 19:38:03 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 19:38:03 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
Message-ID: <O2I75lB3NZFKFC6JC8U5UMUrCTyNwOyoMpzCSeEGVVY=.b00ed173-e7a8-4833-b45e-ccc10681ba13@github.com>

On Wed, 5 Jun 2024 19:06:14 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:
> 
>  - Fix penultimate block length calculation
>    
>    It is not correct to calculate the penultimate block length based on
>    the output array offset, since the output array can include arbitrary
>    user-supplied data.
>    
>    Add a test case to check this fix.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Extract swapLastTwoBlocks() unified logic
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Apply code-review suggestion
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    C...

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java line 70:

> 68: 
> 69:     @SuppressWarnings("serial") // Type of field is not Serializable
> 70:     final CTSVariant ctsVariant;

For new non-serializable fields, you should just mark it with "transient" keyword and no need for the `@SuppressWarnings("serial")`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628342501


From fferrari at openjdk.org  Wed Jun  5 19:42:01 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 19:42:01 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <S7kWQYt4BkzEAcrFpvwbFyn1mKezXDlHo25JnEahx0I=.b83e90a8-74df-46d6-b413-1882d8b9c6d4@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
 <S7kWQYt4BkzEAcrFpvwbFyn1mKezXDlHo25JnEahx0I=.b83e90a8-74df-46d6-b413-1882d8b9c6d4@github.com>
Message-ID: <wzEei4M3rrKoh0uKsuMNzrOGcoelvJcHva_7QfNFuQg=.43f0c1af-1740-4542-b781-94fbbd3b6ff2@github.com>

On Wed, 5 Jun 2024 19:21:02 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:
>> 
>>  - Fix penultimate block length calculation
>>    
>>    It is not correct to calculate the penultimate block length based on
>>    the output array offset, since the output array can include arbitrary
>>    user-supplied data.
>>    
>>    Add a test case to check this fix.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Extract swapLastTwoBlocks() unified logic
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Apply code-review suggestion
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Improve handling when the token variant is unknown
>>    
>>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>>    the token CTS variant has not been specified in the configuration. Make
>>    NSS an exception, as we know that it uses the CS1 variant.
>>    
>>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>>    also slightly improving the error message.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Revert re-arrangement of native methods parameters
>>    
>>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>>    the copyright which is retained as 2024.
>>    
>>    NOTE: new calls of the same methods are retained in the re-arrangement
>>    style, as we didn't introduce this re-arrangement, it was already
>>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8330842: Support AES CBC with Ciph...
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 647:
> 
>> 645:             return Enum.valueOf(enumClass, value);
>> 646:         } catch (IllegalArgumentException ignored) {
>> 647:             throw excToken(keyword + " must be one of " +
> 
> nit: since we are using the `value` for enum conversion, maybe using it instead of `keyword` for the error message? This has the benefit of showing what the parsed value is.

The `value` is completed form the current token by `excToken()`.

As mentioned in https://github.com/openjdk/jdk/pull/18898#issuecomment-2138360201, if we pass `CS4` (an invalid value), we get the following error:

cipherTextStealingVariant must be one of [CS1, CS2, CS3], read: Token[CS4], line 33


Other attributes are parsed in the same way, with similar error messages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628345529


From valeriep at openjdk.org  Wed Jun  5 19:53:00 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 19:53:00 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
Message-ID: <i2WZrCgA2NQ1g3Vbl1hQNtpunChqpN3CS2Ab4t7_YT4=.54cfe508-1053-4b8f-88e1-b52e82adac1a@github.com>

On Wed, 5 Jun 2024 19:06:14 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:
> 
>  - Fix penultimate block length calculation
>    
>    It is not correct to calculate the penultimate block length based on
>    the output array offset, since the output array can include arbitrary
>    user-supplied data.
>    
>    Add a test case to check this fix.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Extract swapLastTwoBlocks() unified logic
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Apply code-review suggestion
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Improve handling when the token variant is unknown
>    
>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>    the token CTS variant has not been specified in the configuration. Make
>    NSS an exception, as we know that it uses the CS1 variant.
>    
>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>    also slightly improving the error message.
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - Revert re-arrangement of native methods parameters
>    
>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>    the copyright which is retained as 2024.
>    
>    NOTE: new calls of the same methods are retained in the re-arrangement
>    style, as we didn't introduce this re-arrangement, it was already
>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Merge 'openjdk/master' into JDK-8330843
>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    C...

test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java line 84:

> 82: 
> 83:         new CI("AES/CTR/NoPadding", "AES", 3200),
> 84:         new CI("AES/CTS/NoPadding", "AES", 3200),

Add more data sizes, e.g. not multiples of block sizes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628356692


From fferrari at openjdk.org  Wed Jun  5 20:02:00 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 20:02:00 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <i2WZrCgA2NQ1g3Vbl1hQNtpunChqpN3CS2Ab4t7_YT4=.54cfe508-1053-4b8f-88e1-b52e82adac1a@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
 <i2WZrCgA2NQ1g3Vbl1hQNtpunChqpN3CS2Ab4t7_YT4=.54cfe508-1053-4b8f-88e1-b52e82adac1a@github.com>
Message-ID: <IIoNSxZkTmZ_LhudnVdYnaF3wZGcdY0fO33CxgacEb8=.2ffc4e38-9a5b-4295-b609-2283b7df8bcd@github.com>

On Wed, 5 Jun 2024 19:50:15 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:
>> 
>>  - Fix penultimate block length calculation
>>    
>>    It is not correct to calculate the penultimate block length based on
>>    the output array offset, since the output array can include arbitrary
>>    user-supplied data.
>>    
>>    Add a test case to check this fix.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Extract swapLastTwoBlocks() unified logic
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Apply code-review suggestion
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Improve handling when the token variant is unknown
>>    
>>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>>    the token CTS variant has not been specified in the configuration. Make
>>    NSS an exception, as we know that it uses the CS1 variant.
>>    
>>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>>    also slightly improving the error message.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Revert re-arrangement of native methods parameters
>>    
>>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>>    the copyright which is retained as 2024.
>>    
>>    NOTE: new calls of the same methods are retained in the re-arrangement
>>    style, as we didn't introduce this re-arrangement, it was already
>>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8330842: Support AES CBC with Ciph...
>
> test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java line 84:
> 
>> 82: 
>> 83:         new CI("AES/CTR/NoPadding", "AES", 3200),
>> 84:         new CI("AES/CTS/NoPadding", "AES", 3200),
> 
> Add more data sizes, e.g. not multiples of block sizes?

These edge cases are covered by the new `TestCipherTextStealingMultipart`, here we only wanted to add some cases in line with the CTR addition (4ce804890912ce7a0002c9e631c4dc699ac33c39).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628366469


From fferrari at openjdk.org  Wed Jun  5 20:19:25 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 20:19:25 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Apply code-review suggestion
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/37d6eb80..476cbc97

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

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

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


From fferrari at openjdk.org  Wed Jun  5 20:19:27 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 5 Jun 2024 20:19:27 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <O2I75lB3NZFKFC6JC8U5UMUrCTyNwOyoMpzCSeEGVVY=.b00ed173-e7a8-4833-b45e-ccc10681ba13@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
 <O2I75lB3NZFKFC6JC8U5UMUrCTyNwOyoMpzCSeEGVVY=.b00ed173-e7a8-4833-b45e-ccc10681ba13@github.com>
Message-ID: <Etl5UJoAj3WAF1eojJf2QbcC3QLk_28v6davICkPWMA=.dec56923-203b-4725-b2ad-4467b35aafdc@github.com>

On Wed, 5 Jun 2024 19:35:45 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet 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 13 additional commits since the last revision:
>> 
>>  - Fix penultimate block length calculation
>>    
>>    It is not correct to calculate the penultimate block length based on
>>    the output array offset, since the output array can include arbitrary
>>    user-supplied data.
>>    
>>    Add a test case to check this fix.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Extract swapLastTwoBlocks() unified logic
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Apply code-review suggestion
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Improve handling when the token variant is unknown
>>    
>>    Avoid registering CTS algorithms (those depending on CKM_AES_CTS) when
>>    the token CTS variant has not been specified in the configuration. Make
>>    NSS an exception, as we know that it uses the CS1 variant.
>>    
>>    Take advantage to extract a pkcs11.Config::parseEnumEntry() method for
>>    a cleaner entry in the main switch statement of pkcs11.Config::parse(),
>>    also slightly improving the error message.
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - Revert re-arrangement of native methods parameters
>>    
>>    This reverts commit 0a777e94229723376e1264e87cbf0ba805dc736f, except for
>>    the copyright which is retained as 2024.
>>    
>>    NOTE: new calls of the same methods are retained in the re-arrangement
>>    style, as we didn't introduce this re-arrangement, it was already
>>    present in most of the calls inside ::implUpdate() and ::implDoFinal().
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - Merge 'openjdk/master' into JDK-8330843
>>  - 8330842: Add AES CBC with Ciphertext Stealing (CTS) SunPKCS11 tests
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8330842: Support AES CBC with Ciph...
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java line 70:
> 
>> 68: 
>> 69:     @SuppressWarnings("serial") // Type of field is not Serializable
>> 70:     final CTSVariant ctsVariant;
> 
> For new non-serializable fields, you should just mark it with "transient" keyword and no need for the `@SuppressWarnings("serial")`

Ok, done in 476cbc97f109ae2507706f1b74b71581207fdc99.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628382596


From mpowers at openjdk.org  Wed Jun  5 20:28:58 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 5 Jun 2024 20:28:58 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
Message-ID: <eSLIDCwSEVo3buJukWGH3Xnjkc_cGx3JyHtF1ar2Q58=.9e6417fd-bf71-44fe-a7cf-039f98f7d509@github.com>

On Wed, 5 Jun 2024 02:57:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for this simple change to fix a threading problem with the test. The server thread was not completing before the check occurred on the main thread.  The failure showed up in windows and macos, but not linux.  With this fix, running 100 times, windows & macos showed no failures.
> 
> Tony

test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java line 62:

> 60:         }
> 61: 
> 62:         throw new Exception("Failed to find expected alert: " + args[0]);

Should it be "expected exception" rather than "expected alert"?

test/jdk/javax/net/ssl/templates/TLSBase.java line 101:

> 99:         if (!empty) {
> 100:             fis = new FileInputStream(System.getProperty("test.src", "./") +
> 101:                 "/" + pathToStores + "/" + keyStoreFile);

My Java style guide says to break before the operator.

test/jdk/javax/net/ssl/templates/TLSBase.java line 246:

> 244:         void done() {
> 245:             try {
> 246:                 t.join(5000);

I had to increase the join value of a test recently that failed with virtual threads.
Try adding `--test-make-args JTREG_TEST_THREAD_FACTORY=Virtual` to your mach5 command line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1628363765
PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1628378909
PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1628383058


From valeriep at openjdk.org  Wed Jun  5 23:11:45 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 23:11:45 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
Message-ID: <vVnHhNeL4N2vpP1PsHRfa1sZH8z9ciEXXFG3v1jCSq8=.7c746be0-79a7-450f-911b-32624d315bf3@github.com>

On Wed, 5 Jun 2024 20:19:25 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code-review suggestion
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

> > Done in [997777e](https://github.com/openjdk/jdk/commit/997777e86c6fa03f070dcf0f219813c11cb480ce), I will adjust the CSR tomorrow.
> 
> [JDK-8330843](https://bugs.openjdk.org/browse/JDK-8330843) CSR updated accordingly.

The CSR is quite lengthy and some wordings may be more suitable for another section, so I made some adjustments. In addition, I made some minor wording changes to the specification section to be more align with the existing guide. Could you please take a second look? I will add myself as the reviewer once we settle on the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2151104880


From valeriep at openjdk.org  Wed Jun  5 23:37:48 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Jun 2024 23:37:48 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v5]
In-Reply-To: <wzEei4M3rrKoh0uKsuMNzrOGcoelvJcHva_7QfNFuQg=.43f0c1af-1740-4542-b781-94fbbd3b6ff2@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <Kmc2kFKSFCNYJf07r1SJw7DJIv9etUfpZq9N2tmx0jY=.234a705d-f638-4182-b3b3-0e098bd16508@github.com>
 <S7kWQYt4BkzEAcrFpvwbFyn1mKezXDlHo25JnEahx0I=.b83e90a8-74df-46d6-b413-1882d8b9c6d4@github.com>
 <wzEei4M3rrKoh0uKsuMNzrOGcoelvJcHva_7QfNFuQg=.43f0c1af-1740-4542-b781-94fbbd3b6ff2@github.com>
Message-ID: <OcqzrMhwNY2kcKbyABvIIEozHBbGMOTaR54cHEsc_ng=.436b05ca-cd9c-4ff6-be57-ebbddfcaea10@github.com>

On Wed, 5 Jun 2024 19:39:06 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 647:
>> 
>>> 645:             return Enum.valueOf(enumClass, value);
>>> 646:         } catch (IllegalArgumentException ignored) {
>>> 647:             throw excToken(keyword + " must be one of " +
>> 
>> nit: since we are using the `value` for enum conversion, maybe using it instead of `keyword` for the error message? This has the benefit of showing what the parsed value is.
>
> The `value` is completed form the current token by `excToken()`.
> 
> As mentioned in https://github.com/openjdk/jdk/pull/18898#issuecomment-2138360201, if we pass `CS4` (an invalid value), we get the following error:
> 
> cipherTextStealingVariant must be one of [CS1, CS2, CS3], read: Token[CS4], line 33
> 
> 
> Other attributes are parsed in the same way, with similar error messages.

Ok, sounds good.

>> test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java line 84:
>> 
>>> 82: 
>>> 83:         new CI("AES/CTR/NoPadding", "AES", 3200),
>>> 84:         new CI("AES/CTS/NoPadding", "AES", 3200),
>> 
>> Add more data sizes, e.g. not multiples of block sizes?
>
> These edge cases are covered by the new `TestCipherTextStealingMultipart`, here we only wanted to add some cases in line with the CTR addition (4ce804890912ce7a0002c9e631c4dc699ac33c39).

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628561079
PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1628560195


From ascarpino at openjdk.org  Wed Jun  5 23:51:43 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 5 Jun 2024 23:51:43 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <eSLIDCwSEVo3buJukWGH3Xnjkc_cGx3JyHtF1ar2Q58=.9e6417fd-bf71-44fe-a7cf-039f98f7d509@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
 <eSLIDCwSEVo3buJukWGH3Xnjkc_cGx3JyHtF1ar2Q58=.9e6417fd-bf71-44fe-a7cf-039f98f7d509@github.com>
Message-ID: <znKiG3AORqvVW-iDV3z38CJgjOTCW-52PkfU_YpBiVs=.fb7806e9-7615-4078-ab98-d6ca1e05170c@github.com>

On Wed, 5 Jun 2024 19:57:34 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for this simple change to fix a threading problem with the test. The server thread was not completing before the check occurred on the main thread.  The failure showed up in windows and macos, but not linux.  With this fix, running 100 times, windows & macos showed no failures.
>> 
>> Tony
>
> test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java line 62:
> 
>> 60:         }
>> 61: 
>> 62:         throw new Exception("Failed to find expected alert: " + args[0]);
> 
> Should it be "expected exception" rather than "expected alert"?

It's the TLS alert it's trying to find, the exception is the messenger

> test/jdk/javax/net/ssl/templates/TLSBase.java line 101:
> 
>> 99:         if (!empty) {
>> 100:             fis = new FileInputStream(System.getProperty("test.src", "./") +
>> 101:                 "/" + pathToStores + "/" + keyStoreFile);
> 
> My Java style guide says to break before the operator.

I have never heard that.  I have always ended with a plus and I believe everyone else does too if I'm not mistaken.

> test/jdk/javax/net/ssl/templates/TLSBase.java line 246:
> 
>> 244:         void done() {
>> 245:             try {
>> 246:                 t.join(5000);
> 
> I had to increase the join value of a test recently that failed with virtual threads.
> Try adding `--test-make-args JTREG_TEST_THREAD_FACTORY=Virtual` to your mach5 command line.

I'll check it out.. thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1628567291
PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1628567917
PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1628567988


From mdonovan at openjdk.org  Thu Jun  6 11:34:47 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 6 Jun 2024 11:34:47 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v2]
In-Reply-To: <fU1Kn_9HJAU7tS_XEp9eTO9nShOjMrA-wb-BIuaB6rI=.218ce299-519a-4cfd-9e66-651c427e764d@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
 <fU1Kn_9HJAU7tS_XEp9eTO9nShOjMrA-wb-BIuaB6rI=.218ce299-519a-4cfd-9e66-651c427e764d@github.com>
Message-ID: <biU5oD1_AjzwPKH5EYOzFbLzbM4RA73OJGInlmfcR0U=.deaafcb0-4b5b-4d12-a023-53b285f55ac0@github.com>

On Mon, 3 Jun 2024 09:54:16 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
>> 
>> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
>> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
>> 3. Adding othervm flag to run in isolation.
>> 
>> Test runs in tier2
>
> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8028127
>  - Merge branch 'openjdk:master' into JDK-8028127
>  - Regtest java/security/Security/SynchronizedAccess.java is  incorrect.

test/jdk/java/security/Security/SynchronizedAccess.java line 70:

> 68:             Provider[] provs = new Provider[10];
> 69:             for (int i = 0; i < provs.length; i++)
> 70:                 provs[i] = new MyProvider("name" + i, "1", "test");

use { } around for-loop

test/jdk/java/security/Security/SynchronizedAccess.java line 79:

> 77:                     }
> 78:                     Signature.getInstance("sigalg");
> 79:                     // skipping first provider so there is always 1 available for getInstance

Why are you leaving one provider when the next thing to do is to add them all back again?

test/jdk/java/security/Security/SynchronizedAccess.java line 84:

> 82:                     }
> 83:                 } catch (NoSuchAlgorithmException nsae) {
> 84:                     throw new RuntimeException("Should not reach here " + nsae);

The message could be a little clearer. Something like, "Expected provider for sigalg not found."

I would include `nsae` as a second, 'cause' parameter to the RuntimeException. That way the full stack is shown in the logs. It isn't strictly necessary here since it's pretty obvious where it's coming from, but it's a good habit to be in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19480#discussion_r1629329314
PR Review Comment: https://git.openjdk.org/jdk/pull/19480#discussion_r1629337067
PR Review Comment: https://git.openjdk.org/jdk/pull/19480#discussion_r1629343776


From fguallini at openjdk.org  Thu Jun  6 13:13:00 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 6 Jun 2024 13:13:00 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v3]
In-Reply-To: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
Message-ID: <Yu9qXoDaij0bSwQk__fNH_7Xez7jLl7ZHQqaEvj627I=.f21da5bd-114c-47a0-859c-af1fdad25d58@github.com>

> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
> 
> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
> 3. Adding othervm flag to run in isolation.
> 
> Test runs in tier2

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

  added brackets, and refactor a comment and an exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19480/files
  - new: https://git.openjdk.org/jdk/pull/19480/files/1549cc59..3502c27a

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

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

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


From fguallini at openjdk.org  Thu Jun  6 13:13:02 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 6 Jun 2024 13:13:02 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v2]
In-Reply-To: <biU5oD1_AjzwPKH5EYOzFbLzbM4RA73OJGInlmfcR0U=.deaafcb0-4b5b-4d12-a023-53b285f55ac0@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
 <fU1Kn_9HJAU7tS_XEp9eTO9nShOjMrA-wb-BIuaB6rI=.218ce299-519a-4cfd-9e66-651c427e764d@github.com>
 <biU5oD1_AjzwPKH5EYOzFbLzbM4RA73OJGInlmfcR0U=.deaafcb0-4b5b-4d12-a023-53b285f55ac0@github.com>
Message-ID: <A_bCRkXXaTwE78y9Z2O060VsY4K-pQTKJAhOwwe1Ycw=.c9e14c30-3934-4706-9c44-330102528cc3@github.com>

On Thu, 6 Jun 2024 11:25:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8028127
>>  - Merge branch 'openjdk:master' into JDK-8028127
>>  - Regtest java/security/Security/SynchronizedAccess.java is  incorrect.
>
> test/jdk/java/security/Security/SynchronizedAccess.java line 79:
> 
>> 77:                     }
>> 78:                     Signature.getInstance("sigalg");
>> 79:                     // skipping first provider so there is always 1 available for getInstance
> 
> Why are you leaving one provider when the next thing to do is to add them all back again?

Since it runs multiple threads in parallel, it could happen this line is evaluated after another thread removes all providers, leading to a race condition. Leaving at least one provider assures this test won't fail intermittently. I added a new line in the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19480#discussion_r1629507364


From mdonovan at openjdk.org  Thu Jun  6 13:34:45 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 6 Jun 2024 13:34:45 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v3]
In-Reply-To: <Yu9qXoDaij0bSwQk__fNH_7Xez7jLl7ZHQqaEvj627I=.f21da5bd-114c-47a0-859c-af1fdad25d58@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
 <Yu9qXoDaij0bSwQk__fNH_7Xez7jLl7ZHQqaEvj627I=.f21da5bd-114c-47a0-859c-af1fdad25d58@github.com>
Message-ID: <GsJyQ2C4lSlB9uLBa17Z_L2OZm7GWANzrRRAysQvdW4=.c55b6431-b79a-4fe7-a841-8d833591d770@github.com>

On Thu, 6 Jun 2024 13:13:00 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
>> 
>> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
>> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
>> 3. Adding othervm flag to run in isolation.
>> 
>> Test runs in tier2
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added brackets, and refactor a comment and an exception message

LGTM

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

Marked as reviewed by mdonovan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19480#pullrequestreview-2101968941


From mpowers at openjdk.org  Thu Jun  6 14:30:49 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 6 Jun 2024 14:30:49 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <znKiG3AORqvVW-iDV3z38CJgjOTCW-52PkfU_YpBiVs=.fb7806e9-7615-4078-ab98-d6ca1e05170c@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
 <eSLIDCwSEVo3buJukWGH3Xnjkc_cGx3JyHtF1ar2Q58=.9e6417fd-bf71-44fe-a7cf-039f98f7d509@github.com>
 <znKiG3AORqvVW-iDV3z38CJgjOTCW-52PkfU_YpBiVs=.fb7806e9-7615-4078-ab98-d6ca1e05170c@github.com>
Message-ID: <IYiP5vgKLTDWh6IXdLWzUFzLk7jXHUG10qcjnp3Db5U=.8e92bff9-f8da-4c48-94fe-c1141c9356bf@github.com>

On Wed, 5 Jun 2024 23:48:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/templates/TLSBase.java line 101:
>> 
>>> 99:         if (!empty) {
>>> 100:             fis = new FileInputStream(System.getProperty("test.src", "./") +
>>> 101:                 "/" + pathToStores + "/" + keyStoreFile);
>> 
>> My Java style guide says to break before the operator.
>
> I have never heard that.  I have always ended with a plus and I believe everyone else does too if I'm not mistaken.

https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-constants

Probably showed up in a code review comment from someone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1629664247


From fguallini at openjdk.org  Thu Jun  6 15:45:54 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 6 Jun 2024 15:45:54 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v4]
In-Reply-To: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
Message-ID: <3soIcVwBexljOfnkrTIQJkzjp69RqcVvlViK3z90EDU=.7282f312-d10d-4a8e-a3a7-262a40a6c6d3@github.com>

> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
> 
> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
> 3. Adding othervm flag to run in isolation.
> 
> Test runs in tier2

Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - added brackets, and refactor a comment and an exception message
 - Regtest java/security/Security/SynchronizedAccess.java is  incorrect.

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

Changes: https://git.openjdk.org/jdk/pull/19480/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19480&range=03
  Stats: 92 lines in 1 file changed: 55 ins; 4 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/19480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19480/head:pull/19480

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


From liach at openjdk.org  Thu Jun  6 17:51:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 17:51:44 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Changes requested by liach (Author).

test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:

> 1: #

This file change is dubious:
1. It does not have any trailing whitespace that can fail the skara checks.
2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles)

Recommended actions: Either
1. Revert changes in this file;
2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line.

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2102735910
PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1629981196


From fferrari at openjdk.org  Thu Jun  6 19:26:45 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 6 Jun 2024 19:26:45 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <vVnHhNeL4N2vpP1PsHRfa1sZH8z9ciEXXFG3v1jCSq8=.7c746be0-79a7-450f-911b-32624d315bf3@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
 <vVnHhNeL4N2vpP1PsHRfa1sZH8z9ciEXXFG3v1jCSq8=.7c746be0-79a7-450f-911b-32624d315bf3@github.com>
Message-ID: <qaF3qTQlfKZ0Us8E4Kij38rFg8KVIGetF2JKvAyMwwg=.0a43b038-f5db-4073-a842-f6d8c5b7365c@github.com>

On Wed, 5 Jun 2024 23:08:57 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> The CSR is quite lengthy and some wordings may be more suitable for another section, so I made some adjustments. In addition, I made some minor wording changes to the specification section to be more align with the existing guide. Could you please take a second look? I will add myself as the reviewer once we settle on the changes.

I gave it a look and made some minor updates.

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2153253067


From valeriep at openjdk.org  Thu Jun  6 20:13:47 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Jun 2024 20:13:47 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <HWn7vIVWpZUTBx83VtNhTiBuoGXSBHwuXsXRK-tiyrU=.270fe026-64e9-44a2-a7e1-89cb0f1437a7@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 121:

> 119:     @Override
> 120:     int encrypt(byte[] pt, int ptOfs, int ptLen, byte[] ct, int ctOfs) {
> 121:         throw new UnsupportedOperationException("multi-part not supported");

Change the error message as well?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 127:

> 125:     @Override
> 126:     int decrypt(byte[] ct, int ctOfs, int ctLen, byte[] pt, int ptOfs) {
> 127:         throw new UnsupportedOperationException("multi-part not supported");

Change the error message as well?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 159:

> 157:     @Override
> 158:     int encrypt(byte[] pt, int ptOfs, int ptLen, byte[] ct, int ctOfs) {
> 159:         throw new UnsupportedOperationException("multi-part not supported");

Change the error message as well?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 165:

> 163:     @Override
> 164:     int decrypt(byte[] ct, int ctOfs, int ctLen, byte[] pt, int ptOfs) {
> 165:         throw new UnsupportedOperationException("multi-part not supported");

Change the error message as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1630167579
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1630167862
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1630169037
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1630169187


From valeriep at openjdk.org  Thu Jun  6 21:20:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Jun 2024 21:20:13 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
Message-ID: <Bny39l4StlMA35DGcZdpxf9EztfFFb7HhzGJGsmtj4Y=.6f606ed0-aade-40ab-9624-6da549bca395@github.com>

On Wed, 5 Jun 2024 20:19:25 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code-review suggestion
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1169:

> 1167:         }
> 1168:         if (ciphertextArr != null) {
> 1169:             ciphertextBuf = ByteBuffer.wrap(ciphertextArr);

Can we add a comment here to caution that position may be incorrect (since the offset is not passed to this call) and thus need to always supply an index for reading/writing values to the `ciphertextBuf`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630265213


From mbalao at openjdk.org  Thu Jun  6 22:25:13 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 6 Jun 2024 22:25:13 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <Bny39l4StlMA35DGcZdpxf9EztfFFb7HhzGJGsmtj4Y=.6f606ed0-aade-40ab-9624-6da549bca395@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
 <Bny39l4StlMA35DGcZdpxf9EztfFFb7HhzGJGsmtj4Y=.6f606ed0-aade-40ab-9624-6da549bca395@github.com>
Message-ID: <MZR4oeEV_LFQ_pWWRiX1kKdQBcIMlcW_fhGI7gFv43w=.709dd296-8d6c-4fa9-a569-785c99c6458a@github.com>

On Thu, 6 Jun 2024 21:18:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply code-review suggestion
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1169:
> 
>> 1167:         }
>> 1168:         if (ciphertextArr != null) {
>> 1169:             ciphertextBuf = ByteBuffer.wrap(ciphertextArr);
> 
> Can we add a comment here to caution that position may be incorrect (since the offset is not passed to this call) and thus need to always supply an index for reading/writing values to the `ciphertextBuf`?

It's not so much about position being incorrect ?`convertCTSVariant` makes no assumptions about it, but could have reset position to the beginning of the last 2 blocks? but that `ciphertextBuf` bytes should not be modified except for the last 2 blocks. I'm okay with adding a comment but  I don't see any extension of the `convertCTSVariant` function that could be at risk of having to access anything other than the last 2 blocks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630335033


From valeriep at openjdk.org  Thu Jun  6 22:25:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Jun 2024 22:25:13 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
Message-ID: <vD6QQl9x5N8UDnTz46qVMA6NVT4ZNVf4f5m1Chc03fw=.e740d367-9b07-48d1-a3d0-d02273f625a4@github.com>

On Wed, 5 Jun 2024 20:19:25 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code-review suggestion
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1076:

> 1074:                         outOfs += k;
> 1075:                         outLen -= k;
> 1076:                     }

Why not put this block into the else block starting at line 1098 below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630335186


From jonathan.gibbons at oracle.com  Thu Jun  6 23:11:56 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 6 Jun 2024 16:11:56 -0700
Subject: [External] : Re: Missing element-list for
 https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec
In-Reply-To: <PAVPR10MB7035701A19D9F217B471B27C8AF92@PAVPR10MB7035.EURPRD10.PROD.OUTLOOK.COM>
References: <5947f22d-0c8d-4063-b721-42b7dd44ba4c@siemens.com>
 <47A81E8E-1DFB-4CE1-A465-7FDE83F183DA@oracle.com>
 <d93a2dfe-50b8-4fe3-a680-cdad8aef4b81@oracle.com>
 <PAVPR10MB7035701A19D9F217B471B27C8AF92@PAVPR10MB7035.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <94c6cf1c-21f3-4fb6-9c5a-4bd6cada8e4b@oracle.com>


On 6/5/24 2:51 AM, Osipov, Michael wrote:
> On 2024-05-31 21:38, Jonathan Gibbons wrote:
>> Michael,
>>
>> There is no `element-list` file for any version of JDK before JDK 9.
>> Before JDK 9, the appropriate information was in the `package-list`
>> file. In JDK 9, with the introduction of modules, the format of the file
>> was updated to include modules, and because this was an incompatible
>> change, the file was renamed as well, to `element-list`.
>>
>> It is an annoying misconfiguration of `docs.oracle.com` that you are
>> seeing `302 Moved Temporarily` instead of `404 Not Found` which would be
>> a more semantically accurate response.
>>
>> That leaves the question of why whatever you were doing was looking for
>> `element-list` in JDK 8. To answer that, we need more info, to determine
>> whether it is just a command-line error on your part, or any error in
>> the `javadoc` tool itself. What version of JDK and javadoc are you
>> using; what external libraries were you referencing in `-link` or `-
>> linkoffline` options; and what source level were you using, with either
>> the `-source` or `--release` options?
> John,
>
> thanks for the elaboration. Let me better clarify what happens.
>
> The code is question with a modification for you is available at:
> https://urldefense.com/v3/__https://github.com/michael-o/tomcatspnegoad/tree/javadoc-issue__;!!ACWV5N9M2RV99hQ!L6MibNz6g0M99jnVOo2O_Zs2vP8-4CM-NS4WNUmHmL5dB30i0qaSfDJBHW4S_bxjOhImERJfBWGpStJ6WrwE0WAva10xtV86PQ$  
>
> Class net.sf.michaelo.tomcat.pac.asn1.AdIfRelevantAsn1Parser uses
> com.sun.security.jgss.AuthorizationDataEntry and others use private Sun
> classes which does not allow me to use -release for now, only -source.
> The source is Java 8. When I run javadoc:javadoc with Zulu 8 all links
> are generated successfully. Running Zulu 11 with extracted Javadoc call
> (&"C:\Program Files\Zulu\zulu-11\bin\javadoc.exe" -verbose "@options"
> "@packages") gives me no warning, even in verbose mode. It simply does
> not link.
> When trying Temurin 22.0.1 (&"C:\Temp\jdk-22.0.1+8\bin\javadoc.exe"
> -verbose "@options" "@packages") it gives me:
>> Warnung: URLhttps://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec/element-list  wurde umgeleitet anhttps://docs.oracle.com/en/java/javase/22/  - Aktualisieren Sie die Befehlszeilenoptionen, um diese Warnung zu unterdr?cken.
> That is the redirect. Either I am misunderstanding or I have hit an edge
> case for public classes outside of the standard JDK (Java namespaces).
> Here is the input to Javadoc (@options, @packages) if you cannot try
> yourself:https://urldefense.com/v3/__https://gist.github.com/michael-o/212c6797b000914b9142f1f077b1d9df__;!!ACWV5N9M2RV99hQ!L6MibNz6g0M99jnVOo2O_Zs2vP8-4CM-NS4WNUmHmL5dB30i0qaSfDJBHW4S_bxjOhImERJfBWGpStJ6WrwE0WAva12c46QzhA$  
>
> I have tried:
>> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
>> Java version: 11.0.18, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-11
>> Default locale: de_DE, platform encoding: UTF-8
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
>> Java version: 1.8.0_362, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-8\jre
>> Default locale: de_DE, platform encoding: Cp1252
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
>> Java version: 22.0.1, vendor: Eclipse Adoptium, runtime: C:\Temp\jdk-22.0.1+8
>> Default locale: de_DE, platform encoding: UTF-8
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Note: I have routed the Javadoc traffic through Fiddler and it clearly
> following the misconfigured docs.oracle.com location:
>> #	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom	
>> 10	302	HTTPS	docs.oracle.com	/javase/8/docs/jre/api/security/jgss/spec/element-list	1			javadoc:24660			
>> #	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom	
>> 12	200	HTTPS	docs.oracle.com	/en/java/javase/22/	33 431	max-age=19052	text/html	javadoc:24660			
>
> Regards,
>
> Michael
>
>

Michael,

I investigated a bit further, and I may have a solution for you.

The redirect is annoying, and sad to say, there is nothing I can do to 
get it fixed in a timely manner.? But, I think you may be able to work 
around it.? The answer is based on the content of the files in the gist 
that you referenced in your message.

Look at these lines:

-link
'https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec'
-linkoffline
'https://docs.oracle.com/javase/8/docs/api' 
'C:/Entwicklung/workspace-2023-06/tomcatspnegoad/tomcat90/target/javadoc-bundle-options' 


I'm not sure what is in your `javadoc-bundle-options` file, but it 
*ought* to be a local copy of the `package-list` found here:
https://docs.oracle.com/javase/8/docs/api/package-list

For the first option, the `-link` one, try changing it to:

-linkoffline
'https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec' 
/path/to/file

where `/path/to/file` is a local copy of the file found here:
https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec/package-list

which in reality is just:

com.sun.security.jgss

In other words, both options should be instances of the `-linkoffline` 
option, which should be of the form:

-linkofflinehttps:/url/to/api   /path/to/file

where `/path/to/file` is a local copy of the file downloaded from 
`https:/url/to/api/package-list`

Note I am using `.../package-list` in this message because you are using 
`-source 8`.? If you use a newer version of these APIs, you may need to 
change `package-list` to `element-list`. (I believe the change happened 
in JDK 11.)

For more details on the `-linkoffline` option, see
https://docs.oracle.com/en/java/javase/22/docs/specs/man/javadoc.html#option-linkoffline


-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240606/d397e3b5/attachment.htm>

From mbalao at openjdk.org  Thu Jun  6 23:20:13 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 6 Jun 2024 23:20:13 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <vD6QQl9x5N8UDnTz46qVMA6NVT4ZNVf4f5m1Chc03fw=.e740d367-9b07-48d1-a3d0-d02273f625a4@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
 <vD6QQl9x5N8UDnTz46qVMA6NVT4ZNVf4f5m1Chc03fw=.e740d367-9b07-48d1-a3d0-d02273f625a4@github.com>
Message-ID: <9KiXNKdWmYaZGvfuYNp4vG6_sKBeS8jXrGAdTR8zG1A=.dff919ac-53cd-4255-ac00-000dd5e2cab5@github.com>

On Thu, 6 Jun 2024 22:22:06 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply code-review suggestion
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1076:
> 
>> 1074:                         outOfs += k;
>> 1075:                         outLen -= k;
>> 1076:                     }
> 
> Why not put this block into the else block starting at line 1098 below?

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630383900


From fferrari at openjdk.org  Thu Jun  6 23:33:47 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 6 Jun 2024 23:33:47 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v7]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <NCOTlBQs0tskPdcQkKFfEN57F_u-1_ISQwGR240_BxY=.2ded8b1e-a47b-4625-be4c-349c966708c1@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  More code-review changes.
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/476cbc97..a3151ef5

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

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

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


From valeriep at openjdk.org  Fri Jun  7 00:42:15 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Jun 2024 00:42:15 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
Message-ID: <ahQeSoT4racpBnfATdHtQXzecRkYrDvDozsuLvW_HSg=.b18e5bb9-3beb-4362-abf8-6ce26d0996ab@github.com>

On Wed, 5 Jun 2024 20:19:25 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply code-review suggestion
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

test/jdk/sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java line 139:

> 137:         byte [] outArray = new byte[cipher.getOutputSize(0) + outOfs];
> 138:         cipher.doFinal(outArray, outOfs);
> 139:         actualCiphertextBuf.put(outArray, outOfs, outArray.length - outOfs);

Add this offset testing to the decryption part as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630453957


From fferrari at openjdk.org  Fri Jun  7 01:14:39 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 7 Jun 2024 01:14:39 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v8]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <PCmNlP_sEyKCEo8BmM-u7-5CUKInS-R4Gs9WVIFMyC0=.f7b802bc-59ec-4302-b974-658ec5df43c8@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  More code-review changes.
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/a3151ef5..d6e96987

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=06-07

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

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


From mbalao at openjdk.org  Fri Jun  7 01:14:39 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 7 Jun 2024 01:14:39 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <ahQeSoT4racpBnfATdHtQXzecRkYrDvDozsuLvW_HSg=.b18e5bb9-3beb-4362-abf8-6ce26d0996ab@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
 <ahQeSoT4racpBnfATdHtQXzecRkYrDvDozsuLvW_HSg=.b18e5bb9-3beb-4362-abf8-6ce26d0996ab@github.com>
Message-ID: <5jeQpacu-1qgQQqOTRPHpJHCokVmp1xtHpiSqNpp-pc=.47a50794-dd3b-4be8-b8e8-de93199f03e6@github.com>

On Fri, 7 Jun 2024 00:39:50 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply code-review suggestion
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> test/jdk/sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java line 139:
> 
>> 137:         byte [] outArray = new byte[cipher.getOutputSize(0) + outOfs];
>> 138:         cipher.doFinal(outArray, outOfs);
>> 139:         actualCiphertextBuf.put(outArray, outOfs, outArray.length - outOfs);
> 
> Add this offset testing to the decryption part as well?

Ok, I'll add it but it's not the same for decryption because it's the cipher text what has (potentially) to be reordered and output buffer will be for plain text. In fact, the reordering is over `padBuffer` (that has the last bytes of cipher text) for decryption.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630487007


From rhalade at openjdk.org  Fri Jun  7 01:43:12 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 7 Jun 2024 01:43:12 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v4]
In-Reply-To: <3soIcVwBexljOfnkrTIQJkzjp69RqcVvlViK3z90EDU=.7282f312-d10d-4a8e-a3a7-262a40a6c6d3@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
 <3soIcVwBexljOfnkrTIQJkzjp69RqcVvlViK3z90EDU=.7282f312-d10d-4a8e-a3a7-262a40a6c6d3@github.com>
Message-ID: <0gigoucfVP7vPbdTi755LNlADVjbJmbkY_5-6VCSQEI=.64970444-8c54-48b2-bcaa-f07094f5f472@github.com>

On Thu, 6 Jun 2024 15:45:54 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
>> 
>> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
>> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
>> 3. Adding othervm flag to run in isolation.
>> 
>> Test runs in tier2
>
> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - added brackets, and refactor a comment and an exception message
>  - Regtest java/security/Security/SynchronizedAccess.java is  incorrect.

LGTM. @bradfordwetmore Can you please also review the patch?

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

Marked as reviewed by rhalade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19480#pullrequestreview-2103479111


From valeriep at openjdk.org  Fri Jun  7 01:55:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Jun 2024 01:55:24 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <5jeQpacu-1qgQQqOTRPHpJHCokVmp1xtHpiSqNpp-pc=.47a50794-dd3b-4be8-b8e8-de93199f03e6@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
 <ahQeSoT4racpBnfATdHtQXzecRkYrDvDozsuLvW_HSg=.b18e5bb9-3beb-4362-abf8-6ce26d0996ab@github.com>
 <5jeQpacu-1qgQQqOTRPHpJHCokVmp1xtHpiSqNpp-pc=.47a50794-dd3b-4be8-b8e8-de93199f03e6@github.com>
Message-ID: <0t7S0-BlBEMpQztmKFgpFh4_dyzC6UB4xl-1CasSirg=.f7c324e4-b781-420a-b2a6-bc430b2a6f9b@github.com>

On Fri, 7 Jun 2024 01:08:40 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java line 139:
>> 
>>> 137:         byte [] outArray = new byte[cipher.getOutputSize(0) + outOfs];
>>> 138:         cipher.doFinal(outArray, outOfs);
>>> 139:         actualCiphertextBuf.put(outArray, outOfs, outArray.length - outOfs);
>> 
>> Add this offset testing to the decryption part as well?
>
> Ok, I'll add it but it's not the same for decryption because it's the cipher text what has (potentially) to be reordered and output buffer will be for plain text. In fact, the reordering is over `padBuffer` (that has the last bytes of cipher text) for decryption.

Thanks, yes, it's not about testing the byte-swapping part, but rather just to make sure the specified offset is correctly handled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630521236


From valeriep at openjdk.org  Fri Jun  7 02:05:16 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Jun 2024 02:05:16 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v6]
In-Reply-To: <MZR4oeEV_LFQ_pWWRiX1kKdQBcIMlcW_fhGI7gFv43w=.709dd296-8d6c-4fa9-a569-785c99c6458a@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <BXumYo1KzGHX8FV-mDBsEiJEewaMgmwKfLC_Xz8kX3w=.9bb7ba0f-d986-4841-9753-7677eaa41366@github.com>
 <Bny39l4StlMA35DGcZdpxf9EztfFFb7HhzGJGsmtj4Y=.6f606ed0-aade-40ab-9624-6da549bca395@github.com>
 <MZR4oeEV_LFQ_pWWRiX1kKdQBcIMlcW_fhGI7gFv43w=.709dd296-8d6c-4fa9-a569-785c99c6458a@github.com>
Message-ID: <_JTx-SUSBlLCqMpq0pbffxRHe_LYRuDfOZNyj1N5L34=.c61946df-8395-410d-a2bb-eef24d7e0d44@github.com>

On Thu, 6 Jun 2024 22:21:57 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1169:
>> 
>>> 1167:         }
>>> 1168:         if (ciphertextArr != null) {
>>> 1169:             ciphertextBuf = ByteBuffer.wrap(ciphertextArr);
>> 
>> Can we add a comment here to caution that position may be incorrect (since the offset is not passed to this call) and thus need to always supply an index for reading/writing values to the `ciphertextBuf`?
>
> It's not so much about position being incorrect ?`convertCTSVariant` makes no assumptions about it, but could have reset position to the beginning of the last 2 blocks? but that `ciphertextBuf` bytes should not be modified except for the last 2 blocks. I'm okay with adding a comment but  I don't see any extension of the `convertCTSVariant` function that could be at risk of having to access anything other than the last 2 blocks.

True, the proposed change does not use the position of the `ciphertextBuf`. 
I'd just like some comment covering this since I find it strange that you call `ByteBuffer.wrap(cipherTextArr)` without the offset when the javadoc states that the position is set to 0. Maybe others may also wonder why. That's all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18898#discussion_r1630528647


From valeriep at openjdk.org  Fri Jun  7 02:05:15 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Jun 2024 02:05:15 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v8]
In-Reply-To: <PCmNlP_sEyKCEo8BmM-u7-5CUKInS-R4Gs9WVIFMyC0=.f7b802bc-59ec-4302-b974-658ec5df43c8@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <PCmNlP_sEyKCEo8BmM-u7-5CUKInS-R4Gs9WVIFMyC0=.f7b802bc-59ec-4302-b974-658ec5df43c8@github.com>
Message-ID: <-xXaEcaITe_0iLraSghobA_l5tPKQjl2sOHXPCcOq2k=.28a93364-79bb-4010-9929-54606cd5ae70@github.com>

On Fri, 7 Jun 2024 01:14:39 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More code-review changes.
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

I created the release-note and doc sub-task for this RFE. Please take a look.
As for the code change, the rest looks fine to me.
Thanks,
Valerie

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2153721328


From syan at openjdk.org  Fri Jun  7 07:29:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 07:29:39 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

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

  delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19537/files
  - new: https://git.openjdk.org/jdk/pull/19537/files/0d2be363..e80b98da

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

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

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


From syan at openjdk.org  Fri Jun  7 07:29:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 07:29:39 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>
Message-ID: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com>

On Thu, 6 Jun 2024 17:49:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
> 
>> 1: #
> 
> This file change is dubious:
> 1. It does not have any trailing whitespace that can fail the skara checks.
> 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles)
> 
> Recommended actions: Either
> 1. Revert changes in this file;
> 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line.

Thanks for the suggestion, the trailing blank line of `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1630767547


From liach at openjdk.org  Fri Jun  7 10:58:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 10:58:13 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <k5_jdRCvW-tujrtWjh0pDwEyw-WvLHgWWjbAFMUD9eg=.a7147486-6f7c-4b41-a497-f7c9dbbff9d1@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Thank you for the fix.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104241367


From syan at openjdk.org  Fri Jun  7 12:31:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 12:31:13 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <oEh0z9DjI4IHMferIILJAekOzpvwEXgYdmSDj5OpXKE=.02ff3130-9015-461d-a667-11d09cf281bb@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2154735598


From jwaters at openjdk.org  Fri Jun  7 12:40:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Jun 2024 12:40:13 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Marked as reviewed by jwaters (Committer).

test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:

> 48: clean:
> 49: 	rm -f *.class .classes
> 50: 

Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104439647
PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631140418


From jwaters at openjdk.org  Fri Jun  7 12:40:14 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Jun 2024 12:40:14 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>
 <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com>
Message-ID: <Q9QgDVZGYXfSPaFlXOiuD6Z4x8dO840HcLH35TsCp1w=.331c4558-f7e6-4f1e-826d-d97cba13ca9c@github.com>

On Fri, 7 Jun 2024 07:26:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
>> 
>>> 1: #
>> 
>> This file change is dubious:
>> 1. It does not have any trailing whitespace that can fail the skara checks.
>> 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles)
>> 
>> Recommended actions: Either
>> 1. Revert changes in this file;
>> 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line.
>
> Thanks for the suggestion, the trailing blank line of `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` has been removed.

Hmm, I'm inclined to keep the newlines at the EOF for both, what do the rest of you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631140457


From erikj at openjdk.org  Fri Jun  7 12:51:16 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Jun 2024 12:51:16 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <_nZVUUX4_1rgtwNp8seD0YoqxnZLtORfjVz9m0VFNrQ=.315a1692-b84c-4eed-95db-3843f438431a@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104463763


From erikj at openjdk.org  Fri Jun  7 12:51:17 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Jun 2024 12:51:17 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
Message-ID: <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>

On Fri, 7 Jun 2024 12:37:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:
> 
>> 48: clean:
>> 49: 	rm -f *.class .classes
>> 50: 
> 
> Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet

No, it's an extra newline. A file should end with a newline but one is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631152127


From liach at openjdk.org  Fri Jun  7 12:56:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 12:56:19 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
Message-ID: <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>

On Fri, 7 Jun 2024 12:47:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:
>> 
>>> 48: clean:
>>> 49: 	rm -f *.class .classes
>>> 50: 
>> 
>> Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet
>
> No, it's an extra newline. A file should end with a newline but one is enough.

As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631159094


From fferrari at openjdk.org  Fri Jun  7 13:03:27 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 7 Jun 2024 13:03:27 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v9]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <-G_NiGI4RxXbZz60VUKJuynAZs7622ICGr3c6YxCSSo=.45afffa6-1215-4660-a435-b445bb945072@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Uniformize paddingObj and Mode.CTS code order
  
  When encrypting, the code dealing with paddingObj is placed before the
  code dealing with Mode.CTS. When decrypting, we the code is in the
  inverse order. This commit uniformizes the "paddingObj then CTS" order.
  
  Also do a minor comment edition.
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/d6e96987..2c6a3c0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=07-08

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

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


From syan at openjdk.org  Fri Jun  7 13:04:18 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 13:04:18 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
Message-ID: <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>

On Fri, 7 Jun 2024 12:53:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> No, it's an extra newline. A file should end with a newline but one is enough.
>
> As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin.

I find the extra trailing newlines through below shell command:

for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done


There are only two files has been found:

./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
./test/jdk/java/rmi/reliability/benchmark/bench/Makefile

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631168243


From fferrari at openjdk.org  Fri Jun  7 13:36:13 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 7 Jun 2024 13:36:13 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v8]
In-Reply-To: <-xXaEcaITe_0iLraSghobA_l5tPKQjl2sOHXPCcOq2k=.28a93364-79bb-4010-9929-54606cd5ae70@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <PCmNlP_sEyKCEo8BmM-u7-5CUKInS-R4Gs9WVIFMyC0=.f7b802bc-59ec-4302-b974-658ec5df43c8@github.com>
 <-xXaEcaITe_0iLraSghobA_l5tPKQjl2sOHXPCcOq2k=.28a93364-79bb-4010-9929-54606cd5ae70@github.com>
Message-ID: <TiW0TnWm48PylHwPO6qmbS8_1vkFARt4n7HoX1epNvk=.bbcd6894-e970-4a20-af66-924b6eea3ddd@github.com>

On Fri, 7 Jun 2024 02:02:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> I created the release-note and doc sub-task for this RFE. Please take a look.

They look good to me, I just removed two extra white spaces around the closing parenthesis in [JDK-8333760](https://bugs.openjdk.org/browse/JDK-8333760).

> As for the code change, the rest looks fine to me.

I did one more minor change: 2c6a3c0f79809db77b28c21244ced6621903039f.

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2154851905


From jwaters at openjdk.org  Fri Jun  7 13:39:19 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Jun 2024 13:39:19 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
 <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
Message-ID: <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>

On Fri, 7 Jun 2024 13:01:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin.
>
> I find the extra trailing newlines through below shell command:
> 
> for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done
> 
> 
> There are only two files has been found:
> 
> ./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
> ./test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631213656


From syan at openjdk.org  Fri Jun  7 13:39:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 13:39:20 GMT
Subject: Integrated: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <oBMcuOe20h03DkwKknWriimnsZdPja6FQ6Ez2PKqS24=.2dcbde79-a11f-42b9-9255-5b1fe7e0c542@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

This pull request has now been integrated.

Changeset: d130d2f4
Author:    SendaoYan <syan at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d130d2f4f46d37a2b924343de19d012c129b0a55
Stats:     11 lines in 5 files changed: 0 ins; 2 del; 9 mod

8333477: Delete extra empty spaces in Makefiles

Reviewed-by: erikj, chagedorn, liach, jwaters

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

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


From syan at openjdk.org  Fri Jun  7 14:17:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 14:17:19 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <5PwXrAonDGIth_VkfWPZMDl-XFCPTLAIRunMUPsp_4g=.45fa1560-bcfb-4ac0-9bd7-03734547b09d@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Thanks all for the review and sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2154937099


From mullan at openjdk.org  Fri Jun  7 15:00:13 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Jun 2024 15:00:13 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v9]
In-Reply-To: <-G_NiGI4RxXbZz60VUKJuynAZs7622ICGr3c6YxCSSo=.45afffa6-1215-4660-a435-b445bb945072@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <-G_NiGI4RxXbZz60VUKJuynAZs7622ICGr3c6YxCSSo=.45afffa6-1215-4660-a435-b445bb945072@github.com>
Message-ID: <RROxFGHTCdtg1DOJo1191PB1DNoQ1Q5eG-h9a4bHYGc=.e06bf101-7172-4bdc-9fca-b9dd0f40772f@github.com>

On Fri, 7 Jun 2024 13:03:27 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Uniformize paddingObj and Mode.CTS code order
>   
>   When encrypting, the code dealing with paddingObj is placed before the
>   code dealing with Mode.CTS. When decrypting, we the code is in the
>   inverse order. This commit uniformizes the "paddingObj then CTS" order.
>   
>   Also do a minor comment edition.
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

In the release note, it says "To ensure interoperability with SunJCE and Kerberos which uses the CS3 variant (see https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a-add.pdf, a new SunPKCS11 provider configuration attribute named "cipherTextStealingVariant" is introduced and must be set with any of the following values: CS1, CS2 or CS3 to indicate the CTS variant of the underlying PKCS11 library except for NSS as it's known to be CS1."

I didn't understand the interoperability part. If SunJCE and Kerberos use CS3, then how can PKCS11 ensure interoperability if someone sets the variable to CS1 or CS2?

Also, if the property is set to CS2 or CS3, and you are using NSS, is an exception or error thrown?

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2155015698


From mbalao at openjdk.org  Fri Jun  7 16:13:24 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 7 Jun 2024 16:13:24 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v8]
In-Reply-To: <TiW0TnWm48PylHwPO6qmbS8_1vkFARt4n7HoX1epNvk=.bbcd6894-e970-4a20-af66-924b6eea3ddd@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <PCmNlP_sEyKCEo8BmM-u7-5CUKInS-R4Gs9WVIFMyC0=.f7b802bc-59ec-4302-b974-658ec5df43c8@github.com>
 <-xXaEcaITe_0iLraSghobA_l5tPKQjl2sOHXPCcOq2k=.28a93364-79bb-4010-9929-54606cd5ae70@github.com>
 <TiW0TnWm48PylHwPO6qmbS8_1vkFARt4n7HoX1epNvk=.bbcd6894-e970-4a20-af66-924b6eea3ddd@github.com>
Message-ID: <Co0bBEwDTCm6esFisGRz74sOxeTdqgPCkw5FIBI8uhE=.1b8afc0a-00e6-44bf-81f2-3aed6b06c331@github.com>

On Fri, 7 Jun 2024 13:33:55 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> I created the release-note and doc sub-task for this RFE. Please take a look.
>> As for the code change, the rest looks fine to me.
>> Thanks,
>> Valerie
>
>> I created the release-note and doc sub-task for this RFE. Please take a look.
> 
> They look good to me, I just removed two extra white spaces around the closing parenthesis in [JDK-8333760](https://bugs.openjdk.org/browse/JDK-8333760).
> 
>> As for the code change, the rest looks fine to me.
> 
> I did one more minor change: 2c6a3c0f79809db77b28c21244ced6621903039f.

@franferrax Can you please quote the relevant fragment from the original CSR text? I think it was more clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2155137065


From fferrari at openjdk.org  Fri Jun  7 16:45:22 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 7 Jun 2024 16:45:22 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v8]
In-Reply-To: <Co0bBEwDTCm6esFisGRz74sOxeTdqgPCkw5FIBI8uhE=.1b8afc0a-00e6-44bf-81f2-3aed6b06c331@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <PCmNlP_sEyKCEo8BmM-u7-5CUKInS-R4Gs9WVIFMyC0=.f7b802bc-59ec-4302-b974-658ec5df43c8@github.com>
 <-xXaEcaITe_0iLraSghobA_l5tPKQjl2sOHXPCcOq2k=.28a93364-79bb-4010-9929-54606cd5ae70@github.com>
 <TiW0TnWm48PylHwPO6qmbS8_1vkFARt4n7HoX1epNvk=.bbcd6894-e970-4a20-af66-924b6eea3ddd@github.com>
 <Co0bBEwDTCm6esFisGRz74sOxeTdqgPCkw5FIBI8uhE=.1b8afc0a-00e6-44bf-81f2-3aed6b06c331@github.com>
Message-ID: <EbKpuXaoMlKeMxZ7u1PmYCaRTjmDJge8Gjt_zrRK2ck=.36b0c7a8-0704-45b0-b0b0-8f34f0335a4b@github.com>

On Fri, 7 Jun 2024 16:10:09 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>>> I created the release-note and doc sub-task for this RFE. Please take a look.
>> 
>> They look good to me, I just removed two extra white spaces around the closing parenthesis in [JDK-8333760](https://bugs.openjdk.org/browse/JDK-8333760).
>> 
>>> As for the code change, the rest looks fine to me.
>> 
>> I did one more minor change: 2c6a3c0f79809db77b28c21244ced6621903039f.
>
> @franferrax Can you please quote the relevant fragment from the original CSR text? I think it was more clear.

@martinuy

> @franferrax Can you please quote the relevant fragment from the original CSR text? I think it was more clear.

This was the original CSR text that corresponds with the part of the CSR copied in the release note:

> Introduce a new _SunPKCS11_ provider configuration attribute named `cipherTextStealingVariant` that must be set with any of the following values: `CS1`, `CS2` or `CS3`. This attribute can be used to specify the token's CTS variant and is required to enable `CKM_AES_CTS`. The AES CBC-CTS transformations are not registered by _SunPKCS11_ if the `cipherTextStealingVariant` attribute is not present, with an exception for the NSS Software Token where `CS1` is assumed by default. After encryption, the ciphertext will be converted from the token's variant to _CS3_. Before decryption, the ciphertext will be converted from _CS3_ to the token's variant.

@seanjmullan

> I didn't understand the interoperability part. If SunJCE and Kerberos use CS3, then how can PKCS11 ensure interoperability if someone sets the variable to CS1 or CS2?

The interoperability is ensured by internally converting between _CS3_ and the PKCS #?11 library variant, so that ciphertexts are always arranged in the _CS3_ variant, from a public APIs user's perspective.

> Also, if the property is set to CS2 or CS3, and you are using NSS, is an exception or error thrown?

No, an exception is not thrown and the chosen _CS2_ or _CS3_ variant is applied even for NSS. NOTE: this misconfiguration will lead to invalid outputs. This behaviour is the same for any PKCS #?11 library. What we provide for NSS is an overridable default.

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2155183033


From fferrari at openjdk.org  Fri Jun  7 19:25:45 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 7 Jun 2024 19:25:45 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v10]
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <YJO7mBJ883oHw8zDbWKbJZodOVf0-LThwd96TClwzlA=.1f080bc0-bfd1-4770-9c54-f1a1aa093d02@github.com>

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Improve test clarity and avoid code duplication
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18898/files
  - new: https://git.openjdk.org/jdk/pull/18898/files/2c6a3c0f..33a64b2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18898&range=08-09

  Stats: 137 lines in 1 file changed: 56 ins; 69 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18898/head:pull/18898

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


From valeriep at openjdk.org  Fri Jun  7 22:36:14 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Jun 2024 22:36:14 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v10]
In-Reply-To: <YJO7mBJ883oHw8zDbWKbJZodOVf0-LThwd96TClwzlA=.1f080bc0-bfd1-4770-9c54-f1a1aa093d02@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <YJO7mBJ883oHw8zDbWKbJZodOVf0-LThwd96TClwzlA=.1f080bc0-bfd1-4770-9c54-f1a1aa093d02@github.com>
Message-ID: <YuFu11bnHoZdBhnAmiUIMxVQOLHpy_IpE_mR5O-3zm0=.1d743566-e842-49dd-aec4-816a6446f851@github.com>

On Fri, 7 Jun 2024 19:25:45 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test clarity and avoid code duplication
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

Looks good to me, thanks for the update.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18898#pullrequestreview-2105466824


From dholmes at openjdk.org  Mon Jun 10 02:38:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 02:38:25 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>

Sets the version to 24/24-ea and the copyright year to 2025.

Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.

This initial generation also picks up the unpublished changes from: 

- JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
- JDK-8284500: Typo in Supported Named Extensions - BasicContraints
- JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class

Thanks

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

Commit messages:
 - 8330205: Initial troff manpage generation for JDK 24

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330205
  Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

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


From alanb at openjdk.org  Mon Jun 10 07:18:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 07:18:11 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118


From dholmes at openjdk.org  Mon Jun 10 08:04:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 08:04:12 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
Message-ID: <G-MYWkkw506r9DLMCcme6orMWiD3hu1Wn6nRJuSIG_c=.94373b8a-b647-4e59-9a3e-053c012032aa@github.com>

On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sets the version to 24/24-ea and the copyright year to 2025.
>> 
>> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>> 
>> This initial generation also picks up the unpublished changes from: 
>> 
>> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
>> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
>> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>> 
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095


From mdonovan at openjdk.org  Mon Jun 10 14:22:19 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 10 Jun 2024 14:22:19 GMT
Subject: RFR: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
Message-ID: <vvmz8E0St8ijPBh4LwIyit3XYCg3FbprMLcZXpVtV2I=.a74b7ca0-9511-4283-b9b1-19fa2795d37b@github.com>

In this PR, I updated the ProblemList entry for ClientJSSEServerJSSE.java for all architectures. 

JDK-8333317 documents an intermittent failure which may be resolved by a fix in NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1893404

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

Commit messages:
 - 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

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

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


From duke at openjdk.org  Mon Jun 10 15:06:20 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 10 Jun 2024 15:06:20 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
Message-ID: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>

This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

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

Commit messages:
 - 8333867: SHA3 performance can be improved

Changes: https://git.openjdk.org/jdk/pull/19632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333867
  Stats: 63 lines in 3 files changed: 8 ins; 32 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/19632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19632/head:pull/19632

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


From mullan at openjdk.org  Mon Jun 10 15:39:11 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Jun 2024 15:39:11 GMT
Subject: RFR: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
In-Reply-To: <vvmz8E0St8ijPBh4LwIyit3XYCg3FbprMLcZXpVtV2I=.a74b7ca0-9511-4283-b9b1-19fa2795d37b@github.com>
References: <vvmz8E0St8ijPBh4LwIyit3XYCg3FbprMLcZXpVtV2I=.a74b7ca0-9511-4283-b9b1-19fa2795d37b@github.com>
Message-ID: <rTTD8ltbCJ1VL5Ok696ERsTQVbDpIAtBs6Xy-uGXhsE=.f5476eca-f74a-4e69-8647-a1e957fa3873@github.com>

On Mon, 10 Jun 2024 13:56:07 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated the ProblemList entry for ClientJSSEServerJSSE.java for all architectures. 
> 
> JDK-8333317 documents an intermittent failure which may be resolved by a fix in NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1893404

Can you link 8316183 and 8333317 together in JBS? Otherwise looks good.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19631#pullrequestreview-2108144799


From mdonovan at openjdk.org  Mon Jun 10 15:44:15 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 10 Jun 2024 15:44:15 GMT
Subject: Integrated: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
In-Reply-To: <vvmz8E0St8ijPBh4LwIyit3XYCg3FbprMLcZXpVtV2I=.a74b7ca0-9511-4283-b9b1-19fa2795d37b@github.com>
References: <vvmz8E0St8ijPBh4LwIyit3XYCg3FbprMLcZXpVtV2I=.a74b7ca0-9511-4283-b9b1-19fa2795d37b@github.com>
Message-ID: <9UqLOscIholxydTHxrDVr_eOdu2hNqD1IOQBACXofig=.818576bd-0890-4d98-8771-04c41748d48c@github.com>

On Mon, 10 Jun 2024 13:56:07 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated the ProblemList entry for ClientJSSEServerJSSE.java for all architectures. 
> 
> JDK-8333317 documents an intermittent failure which may be resolved by a fix in NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1893404

This pull request has now been integrated.

Changeset: b2547620
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b25476200ab8bea4f25a671d5b9351662d11c5b4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

Reviewed-by: mullan

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

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


From kvn at openjdk.org  Mon Jun 10 17:28:14 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Jun 2024 17:28:14 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <o4fGP7CoJTQtj2U5OuWhI3sI25F2UyNPfE8Uq9nRg-Q=.65637465-c9ba-482e-95f4-c35930d927ae@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

src/java.base/share/classes/sun/security/provider/SHA3.java line 98:

> 96:     @IntrinsicCandidate
> 97:     private void implCompress0(byte[] b, int ofs) {
> 98:         b2lLittle(b, ofs, longBuf, 0, blockSize);

What about BigEndian machines?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1633597451


From iris at openjdk.org  Mon Jun 10 17:30:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Jun 2024 17:30:15 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696


From duke at openjdk.org  Mon Jun 10 17:33:11 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 10 Jun 2024 17:33:11 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <o4fGP7CoJTQtj2U5OuWhI3sI25F2UyNPfE8Uq9nRg-Q=.65637465-c9ba-482e-95f4-c35930d927ae@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <o4fGP7CoJTQtj2U5OuWhI3sI25F2UyNPfE8Uq9nRg-Q=.65637465-c9ba-482e-95f4-c35930d927ae@github.com>
Message-ID: <Jt1duta7eFPtXqB6zH0t0ZnQVVHsq2Hz0ClN5XfkXlA=.1c30516f-421c-4e19-836f-a6d0d90ba34f@github.com>

On Mon, 10 Jun 2024 17:25:21 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 98:
> 
>> 96:     @IntrinsicCandidate
>> 97:     private void implCompress0(byte[] b, int ofs) {
>> 98:         b2lLittle(b, ofs, longBuf, 0, blockSize);
> 
> What about BigEndian machines?

According to the SHA3 algorithm specification, this byte array should be interpreted as a little endian long array. b2lLittle() does just that on both little and big endian machines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1633606439


From kvn at openjdk.org  Mon Jun 10 17:51:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Jun 2024 17:51:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <Jt1duta7eFPtXqB6zH0t0ZnQVVHsq2Hz0ClN5XfkXlA=.1c30516f-421c-4e19-836f-a6d0d90ba34f@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <o4fGP7CoJTQtj2U5OuWhI3sI25F2UyNPfE8Uq9nRg-Q=.65637465-c9ba-482e-95f4-c35930d927ae@github.com>
 <Jt1duta7eFPtXqB6zH0t0ZnQVVHsq2Hz0ClN5XfkXlA=.1c30516f-421c-4e19-836f-a6d0d90ba34f@github.com>
Message-ID: <KGoqOXnohy0Gv0PYJMV6s0VcyYZWo_HxlznLSHWy_Bg=.aef84ace-9c34-4ba0-8793-88cee7c90899@github.com>

On Mon, 10 Jun 2024 17:29:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SHA3.java line 98:
>> 
>>> 96:     @IntrinsicCandidate
>>> 97:     private void implCompress0(byte[] b, int ofs) {
>>> 98:         b2lLittle(b, ofs, longBuf, 0, blockSize);
>> 
>> What about BigEndian machines?
>
> According to the SHA3 algorithm specification, this byte array should be interpreted as a little endian long array. b2lLittle() does just that on both little and big endian machines.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1633627850


From kvn at openjdk.org  Mon Jun 10 18:46:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Jun 2024 18:46:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

src/java.base/share/classes/sun/security/provider/SHA3.java line 100:

> 98:         b2lLittle(b, ofs, longBuf, 0, blockSize);
> 99:         for (int i = 0; i < blockSize / 8; i++) {
> 100:             state[i] ^= longBuf[i];

Clever. So the intrinsic (C2 code) still generates code corresponding original loop with `byte b[]` array. This will be confusing. It will also slowdown execution in Interpreter so - additional array copy.

New code also assumes that `buffer.length == blockSize` and `(buffer.length % 8) == 0`. I hope there is some assertions/checks in java code to verify that.

Some one from core-libs have to review this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1633688295


From weijun at openjdk.org  Mon Jun 10 20:35:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Jun 2024 20:35:40 GMT
Subject: RFR: 8333772: Incorrect Kerberos behavior when udp_preference_limit =
 0
Message-ID: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>

Allow `udp_preference_limit = 0` to force TCP.

The reason for this bug is that it was read in a similar way as `kdc_timeout` and `max_retries`, both must be positive to have effect.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/19638/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19638&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333772
  Stats: 220 lines in 4 files changed: 188 ins; 9 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/19638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19638/head:pull/19638

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


From weijun at openjdk.org  Mon Jun 10 20:35:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Jun 2024 20:35:40 GMT
Subject: RFR: 8333772: Incorrect Kerberos behavior when
 udp_preference_limit = 0
In-Reply-To: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
References: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
Message-ID: <BrVudubBeXfmqsrjXT2SA2drY-ZRQQit9dY9BXD0UwE=.604be500-672a-4efe-b2ab-5ebd31619c26@github.com>

On Mon, 10 Jun 2024 20:29:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Allow `udp_preference_limit = 0` to force TCP.
> 
> The reason for this bug is that it was read in a similar way as `kdc_timeout` and `max_retries`, both must be positive to have effect.

This code change introduce a behavior change that makes `udp_preference_limit = 0` meaningful. A release note will be added. Please advise if a CSR is required. The compatibility risk should be minimal. It's very unlikely that someone would use this setting which was ignored by Java. The old `udp_preference_limit = 1` setting still works now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19638#issuecomment-2159231339


From duke at openjdk.org  Mon Jun 10 21:12:13 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 10 Jun 2024 21:12:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
Message-ID: <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>

On Mon, 10 Jun 2024 18:43:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 100:
> 
>> 98:         b2lLittle(b, ofs, longBuf, 0, blockSize);
>> 99:         for (int i = 0; i < blockSize / 8; i++) {
>> 100:             state[i] ^= longBuf[i];
> 
> Clever. So the intrinsic (C2 code) still generates code corresponding original loop with `byte b[]` array. This will be confusing. It will also slowdown execution in Interpreter so - additional array copy.
> 
> New code also assumes that `buffer.length == blockSize` and `(buffer.length % 8) == 0`. I hope there is some assertions/checks in java code to verify that.
> 
> Some one from core-libs have to review this.

Well, the intrinsic function treats the input and state as long arrays anyways, and so it only works on little endian architectures, where the conversion is a no-op. There is no additional array copy, this b2lLittle() call used to be in the keccak() method (along with the conversion back to byte array), the point of this whole change is that only one of these conversions should be done with every keccak() call (an additional benefit is that the xor and the corresponding loads+store is done on longs, not on bytes).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1633830998


From valeriep at openjdk.org  Mon Jun 10 23:39:12 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 10 Jun 2024 23:39:12 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <8hv0M-ZAGZdmzH2AOHgCO8bJvyVdOwhlYAJxFDqXYtY=.8890bf64-dcf8-4781-9799-f2e5ee016b0d@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 678:

> 676:     protected int engineUpdate(byte[] in, int inOfs, int inLen,
> 677:             byte[] out, int outOfs) throws ShortBufferException {
> 678:         int bytesUpdated;

Not relevant to this line, but rather down below in the javadoc of engineUpdate(ByteBuffer, ByteBuffer), the javadoc has {@code out} but the variable name is `output`, probably a copy-n-paste error from this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1633978042


From dholmes at openjdk.org  Tue Jun 11 00:50:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 00:50:28 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v2]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <aepA-ImIyckFwPaf4cS2pizlON3SYyrfc5BK9Y1SJwU=.50de780d-25c0-4da3-9066-52b1a472b8de@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - 8330205: Initial troff manpage generation for JDK 24

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

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01
  Stats: 53 lines in 28 files changed: 12 ins; 3 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

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


From dholmes at openjdk.org  Tue Jun 11 01:02:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:02:39 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <fxPYBQ2lvXomy6ZaWwe2l7ucWeyV5Yd9dl7b7lZl5ho=.e8c4eae1-cf24-42e2-a86a-f5e3e0f6163c@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

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

  Regenerated after merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19617/files
  - new: https://git.openjdk.org/jdk/pull/19617/files/8472c47d..e7563087

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

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

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


From valeriep at openjdk.org  Tue Jun 11 01:08:17 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Jun 2024 01:08:17 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <_dXE-auACkX24gDvbHFZTCGFzxruQ6SDctQkYba-Mhc=.6c27b86f-7ff2-415e-9211-8bc067bb32b2@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 764:

> 762:     @Override
> 763:     protected int engineDoFinal(byte[] in, int inOfs, int inLen, byte[] out,
> 764:             int outOfs) throws ShortBufferException, AEADBadTagException {

Not relevant to this line, but down below in the javadoc of `engineDoFinal(ByteBuffer, ByteBuffer)`, the method throws `ShortBufferException`, but the javadoc doesn't have it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1634023709


From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
Message-ID: <7aiYPjUq_qkJuy1jRAFfZTpNoCwaw9scrgKJkkbp6UA=.dcdfae3e-05c5-45af-81b4-8a434b2774ba@github.com>

On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark <iris at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerated after merge
>
> Marked as reviewed by iris (Reviewer).

Thanks for the review @irisclark .

I've merged in the latest updates that also brought in part of the missing changes. If anything goes wrong I have another PR in preparation that also updates java.1

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2159577044


From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: Integrated: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <rZfMnH59MoMxA4EjbTMjwJ6Wv7_aU6tAALkPzROcOSM=.d0ee9e97-4348-4441-9c5c-5ab4d834e2bc@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - ~~JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC~~ (covered by merge)
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

This pull request has now been integrated.

Changeset: 3a01b47a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a01b47ac97714608356ce3faf797c37dc63e9af
Stats:     43 lines in 28 files changed: 2 ins; 3 del; 38 mod

8330205: Initial troff manpage generation for JDK 24

Reviewed-by: alanb, iris

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

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


From ssahoo at openjdk.org  Tue Jun 11 06:27:16 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Tue, 11 Jun 2024 06:27:16 GMT
Subject: RFR: 8333772: Incorrect Kerberos behavior when
 udp_preference_limit = 0
In-Reply-To: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
References: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
Message-ID: <F1I6UaBF8mihtmt2zUiS3_gADTC_-NklXY3PNgCBKDc=.5a21a368-4d8a-4079-871b-363ec658b36f@github.com>

On Mon, 10 Jun 2024 20:29:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Allow `udp_preference_limit = 0` to force TCP.
> 
> The reason for this bug is that it was read in a similar way as `kdc_timeout` and `max_retries`, both must be positive to have effect.

Marked as reviewed by ssahoo (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19638#pullrequestreview-2109444065


From duke at openjdk.org  Tue Jun 11 08:06:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Jun 2024 08:06:14 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
Message-ID: <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>

On Mon, 10 Jun 2024 21:09:16 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SHA3.java line 100:
>> 
>>> 98:         b2lLittle(b, ofs, longBuf, 0, blockSize);
>>> 99:         for (int i = 0; i < blockSize / 8; i++) {
>>> 100:             state[i] ^= longBuf[i];
>> 
>> Clever. So the intrinsic (C2 code) still generates code corresponding original loop with `byte b[]` array. This will be confusing. It will also slowdown execution in Interpreter so - additional array copy.
>> 
>> New code also assumes that `buffer.length == blockSize` and `(buffer.length % 8) == 0`. I hope there is some assertions/checks in java code to verify that.
>> 
>> Some one from core-libs have to review this.
>
> Well, the intrinsic function treats the input and state as long arrays anyways, and so it only works on little endian architectures, where the conversion is a no-op. There is no additional array copy, this b2lLittle() call used to be in the keccak() method (along with the conversion back to byte array), the point of this whole change is that only one of these conversions should be done with every keccak() call (an additional benefit is that the xor and the corresponding loads+store is done on longs, not on bytes).

Oh, and about the length: buffer is allocated in the constructor of the parent class (DigestBase) like this:
  buffer = new byte[blockSize];
Here blockSize is one of { 72, 104, 136, 144, 168 }, so divisible by 8.
buffer.length was used before probably because blockSize was declared private in DigestBase. I made it protected, because in my opinion it is easier to read the code this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1634390741


From duke at openjdk.org  Tue Jun 11 09:58:13 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Jun 2024 09:58:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <9k5Cf1pnyqps-ajlB7hVNb7w_XYmTNP7uTDKd7pePVE=.34f3b680-fe4f-4069-b8b2-a2f20cfb235e@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

Some microbenchmark data (the percentages are improvements in ops/sec):
Benchmark                                                                                                                                                                       Linux aarch64  Linux x64  MacOSX aarch64  MacOSX x64
openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_256-length:16384-provider:DEFAULT         27.67%     20.60%          -0.00%      24.75%
openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_256-length:64-provider:DEFAULT            11.95%      6.27%          -3.97%      12.72%
openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_512-length:16384-provider:DEFAULT         18.00%     14.99%           0.01%      15.35%
openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_512-length:64-provider:DEFAULT            11.91%      5.87%          -3.39%      10.04%

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

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2160317942


From mdonovan at openjdk.org  Tue Jun 11 11:09:23 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 11 Jun 2024 11:09:23 GMT
Subject: [jdk23] RFR: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
Message-ID: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>

8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

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

Commit messages:
 - Backport b25476200ab8bea4f25a671d5b9351662d11c5b4

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

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


From kcr at openjdk.org  Tue Jun 11 11:09:24 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Jun 2024 11:09:24 GMT
Subject: [jdk23] RFR: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
In-Reply-To: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>
References: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>
Message-ID: <mGUAg_UbppRGsvcUOrbIF03wrFgfvl50IV5-dIvkgWc=.52415ca3-f183-4cbe-8686-d2a8bd95a62d@github.com>

On Mon, 10 Jun 2024 18:54:38 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

@mpdonova Backports to jdk23 stabilization branch do not need maintainer approval, but they do need a review from a Reviewer. You might want to add a label, as you did for the mainline PR, or else ask the Reviewer of the original PR directly to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19636#issuecomment-2159459032


From mullan at openjdk.org  Tue Jun 11 12:42:13 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 12:42:13 GMT
Subject: [jdk23] RFR: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
In-Reply-To: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>
References: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>
Message-ID: <Eijbzx6K2QagdtpvOYZLPhv-XZ76ANJl8yCh8fnjeUU=.c16bbdb6-6528-4a19-a96f-be81787ce22e@github.com>

On Mon, 10 Jun 2024 18:54:38 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

8333317 should have a `problemlist` label. And 8333829 should have a label too, probably `noreg-self`? Otherwise looks fine.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19636#pullrequestreview-2110339648


From mdonovan at openjdk.org  Tue Jun 11 12:46:16 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 11 Jun 2024 12:46:16 GMT
Subject: [jdk23] Integrated: 8333829: ProblemList
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
In-Reply-To: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>
References: <6KfSei_IN9ll_RDXJ9XveiQPFiusDQPJvk4IWzhxahg=.dbbdd325-13c0-4b9b-8b7c-8c104726192c@github.com>
Message-ID: <4nOxpBXQEuLCuBkTBcfvq9wI9eyECknmFgy-wge9z1g=.685c150e-d17f-4f8a-9dee-a63ef5c6d40f@github.com>

On Mon, 10 Jun 2024 18:54:38 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

This pull request has now been integrated.

Changeset: 9e22b6de
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e22b6dec3a1dc5d2abdc37749774ec2da04ba2b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317

Reviewed-by: mullan
Backport-of: b25476200ab8bea4f25a671d5b9351662d11c5b4

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

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


From kvn at openjdk.org  Tue Jun 11 15:57:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Jun 2024 15:57:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
Message-ID: <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>

On Tue, 11 Jun 2024 08:03:48 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Well, the intrinsic function treats the input and state as long arrays anyways, and so it only works on little endian architectures, where the conversion is a no-op. There is no additional array copy, this b2lLittle() call used to be in the keccak() method (along with the conversion back to byte array), the point of this whole change is that only one of these conversions should be done with every keccak() call (an additional benefit is that the xor and the corresponding loads+store is done on longs, not on bytes).
>
> Oh, and about the length: buffer is allocated in the constructor of the parent class (DigestBase) like this:
>   buffer = new byte[blockSize];
> Here blockSize is one of { 72, 104, 136, 144, 168 }, so divisible by 8.
> buffer.length was used before probably because blockSize was declared private in DigestBase. I made it protected, because in my opinion it is easier to read the code this way.

Thank you for explanation.

An other question. Is any other use of `longBuf` array after `implCompress0()` call which load values from it? Because Intrinsic code will not update it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635128980


From duke at openjdk.org  Tue Jun 11 17:33:12 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Jun 2024 17:33:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
Message-ID: <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>

On Tue, 11 Jun 2024 15:53:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Oh, and about the length: buffer is allocated in the constructor of the parent class (DigestBase) like this:
>>   buffer = new byte[blockSize];
>> Here blockSize is one of { 72, 104, 136, 144, 168 }, so divisible by 8.
>> buffer.length was used before probably because blockSize was declared private in DigestBase. I made it protected, because in my opinion it is easier to read the code this way.
>
> Thank you for explanation.
> 
> An other question. Is any other use of `longBuf` array after `implCompress0()` call which load values from it? Because Intrinsic code will not update it.

There is no other use.. That array is there for the sole purpose of  holding the input as a long array before it gets xor-ed into the state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635252483


From kvn at openjdk.org  Tue Jun 11 17:42:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Jun 2024 17:42:11 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
 <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
Message-ID: <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>

On Tue, 11 Jun 2024 17:30:37 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Thank you for explanation.
>> 
>> An other question. Is any other use of `longBuf` array after `implCompress0()` call which load values from it? Because Intrinsic code will not update it.
>
> There is no other use.. That array is there for the sole purpose of  holding the input as a long array before it gets xor-ed into the state.

okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635262207


From kvn at openjdk.org  Tue Jun 11 18:04:07 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Jun 2024 18:04:07 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <9k5Cf1pnyqps-ajlB7hVNb7w_XYmTNP7uTDKd7pePVE=.34f3b680-fe4f-4069-b8b2-a2f20cfb235e@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <9k5Cf1pnyqps-ajlB7hVNb7w_XYmTNP7uTDKd7pePVE=.34f3b680-fe4f-4069-b8b2-a2f20cfb235e@github.com>
Message-ID: <D59KR_dooXeD-mM3au_cpnCHGtP4R-HB9iT2eBE3WLU=.ec3fb5f6-6fde-4547-b976-8add81bc6596@github.com>

On Tue, 11 Jun 2024 09:55:11 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Some microbenchmark data (the percentages are improvements in ops/sec):
> Benchmark                                                                                                                                                                       Linux aarch64  Linux x64  MacOSX aarch64  MacOSX x64
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_256-length:16384-provider:DEFAULT         27.67%     20.60%          -0.00%      24.75%
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_256-length:64-provider:DEFAULT            11.95%      6.27%          -3.97%      12.72%
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_512-length:16384-provider:DEFAULT         18.00%     14.99%           0.01%      15.35%
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_512-length:64-provider:DEFAULT            11.91%      5.87%          -3.39%      10.04%

@ferakocz what testing in Mach5 you ran? You need at least to run first 3 tiers.

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

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2161300019


From djelinski at openjdk.org  Tue Jun 11 18:25:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Jun 2024 18:25:15 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <O2rVUuax-qNUTH7KvYSn6MpNr_LnwE-agX5UsUMOzf0=.3ee66929-d073-4166-966a-9f6ee64b3d0a@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

src/java.base/share/classes/sun/security/provider/SHA3.java line 70:

> 68:     private long[] state = new long[DM*DM];
> 69: 
> 70:     // The following two arrays are allocated to size WIDTH bytes, but we only

Only one of the following arrays is of WIDTH length... outdated comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635306158


From djelinski at openjdk.org  Tue Jun 11 18:25:16 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Jun 2024 18:25:16 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
 <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
 <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>
Message-ID: <BvlydzBw83D3-PSWvNXu_9Ds0LyC8AzzW9xzSi-uSwU=.f14416dc-d81b-42a0-823b-4d185fac382e@github.com>

On Tue, 11 Jun 2024 17:39:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> There is no other use.. That array is there for the sole purpose of  holding the input as a long array before it gets xor-ed into the state.
>
> okay

Could you try using MethodHandles instead of b2lLittle? Similar to what's used in ChaCha20:
https://github.com/openjdk/jdk/blob/b77bd5fd6a6f7ddbed90300fba790da4fb683275/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java#L132-L134

with MethodHandles you could drop longBuf, removing unnecessary allocation on the only platform where the intrinsic is implemented (MacOSX-aarch64)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635309517


From valeriep at openjdk.org  Tue Jun 11 19:36:14 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Jun 2024 19:36:14 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <N77dMY6hOdZEIkzxa_DokdqTDKYllDzMb3nSp40ordA=.dc74f073-8994-406e-8ced-34e2550123d8@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 109:

> 107:         SecretKey serverMacKey = null;
> 108:         SecretKey clientCipherKey;
> 109:         SecretKey serverCipherKey;

nit: move them down to line 200, e.g. where these two variables are assigned?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635386407


From valeriep at openjdk.org  Tue Jun 11 20:06:14 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Jun 2024 20:06:14 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <5ZQHCMbDNzb1Son_9m1s6WaHsaAdeV5eCuxYkqZC6rw=.5aec5476-8d44-443d-93ea-c8a0b4702d97@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java line 276:

> 274:         outputSize = n;
> 275:         bufOfs = 0;
> 276:         if (Objects.equals(paddingType, PAD_NONE)) {

Not sure if this is necessary, with the current impl, `paddingType` is always assigned with one of internal PAD_XXX constants. Did I miss something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635418496


From duke at openjdk.org  Tue Jun 11 20:08:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Jun 2024 20:08:14 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <O2rVUuax-qNUTH7KvYSn6MpNr_LnwE-agX5UsUMOzf0=.3ee66929-d073-4166-966a-9f6ee64b3d0a@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <O2rVUuax-qNUTH7KvYSn6MpNr_LnwE-agX5UsUMOzf0=.3ee66929-d073-4166-966a-9f6ee64b3d0a@github.com>
Message-ID: <UjmefpKpAuthz3oyUoBkqzU5c8DcP4ZzkYXz43NOqJA=.7fde9576-06a8-4dc6-9554-13caef151a4b@github.com>

On Tue, 11 Jun 2024 18:18:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 70:
> 
>> 68:     private long[] state = new long[DM*DM];
>> 69: 
>> 70:     // The following two arrays are allocated to size WIDTH bytes, but we only
> 
> Only one of the following arrays is of WIDTH length... outdated comment?

Well, DM*DM*8 is WIDTH (DM=5 and WIDTH=200), so both arrays have 200 bytes, But I will update the comment to make it clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635419497


From valeriep at openjdk.org  Tue Jun 11 20:28:12 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Jun 2024 20:28:12 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <hgCrjdbW4ndJTTuCRMjBTrnC95UP0J2L00Qy3km4VPU=.a16d57d0-a6d5-4afe-86ba-a89e9168e86e@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/RC2Parameters.java line 224:

> 222: 
> 223:         if (version != 0) {
> 224:             sb.append(LINE_SEP).append("version:").append(LINE_SEP).append(version).append(LINE_SEP);

Well, the original code is easier to read. Probably no difference performance-wise given it's just  a few known strings. Why bother especially when the StringBuilder constructor also uses `+`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635444027


From valeriep at openjdk.org  Tue Jun 11 20:40:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Jun 2024 20:40:13 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <ciVot3NqLBexeRgSgkBCdGPO15V5sh_EzGSWcRAzjik=.b97a9373-8aa9-4aab-bdac-10ce61fd7ee6@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 214:

> 212:     {
> 213:         String kdfAlgo;
> 214:         String cipherAlgo;

nit: merge these with where they are assigned?

src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 243:

> 241: 
> 242:         this.pbes2AlgorithmName = "PBEWith" +
> 243:                 kdfAlgo + "And" + cipherAlgo;

nit: move to one line if less than 80 chars.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635455564
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635453641


From valeriep at openjdk.org  Wed Jun 12 00:02:12 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 12 Jun 2024 00:02:12 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <4kQi1_NF0BVB0RBFteosdf4oEi-kjvt-BF2TgBXzFhg=.863accf2-39d1-472d-a824-d15befbcafa7@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 408:

> 406:             if (keysize >= BlowfishConstants.BLOWFISH_MAX_KEYSIZE)
> 407:                 keysize = BlowfishConstants.BLOWFISH_MAX_KEYSIZE;
> 408:             return new SecretKeySpec(secret, 0, keysize,

nit: merge the following line, i.e. "Blowfish", with this line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635614443


From valeriep at openjdk.org  Wed Jun 12 03:36:16 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 12 Jun 2024 03:36:16 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <mazoQSnzLnesgcN0-xVbM9rl3Z7Hswm4K5VH2EvXTsY=.d1b5c6df-e296-4ea8-b7a5-f0ba53c70e96@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 874:

> 872:         int len = Math.addExact(buffered, inputLen);
> 873:         // calculate padding length
> 874:         int totalLen = len;

Well, personally, I'd prefer to replace `len` with `totalLen`, less changes overall and better naming matching the comment on line 871.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635768389


From valeriep at openjdk.org  Wed Jun 12 04:18:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 12 Jun 2024 04:18:13 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <V9OTT5AISuXXz1X5FcdhhGghVjPvI45Ep2x7ClicH-I=.4e4d95b0-81a9-48f3-b8ba-8fcc58c052fa@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 969:

> 967:     private int finalNoPadding(byte[] in, int inOfs, byte[] out, int outOfs,
> 968:                                int len)
> 969:         throws IllegalBlockSizeException {

Hmm, is ShortBufferException still needed for `prepareInputBuffer(...)` and `fillOutputBuffer(...)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1635789428


From valeriep at openjdk.org  Wed Jun 12 04:32:11 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 12 Jun 2024 04:32:11 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <31YXEREwJ1rMCBR4jbrgLtcB7r9GtqXMul-zINsVyIY=.959774cb-da5e-4cac-a786-922c646c7f9f@github.com>

On Tue, 4 Jun 2024 02:32:31 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

BTW, need to add noreg-xxx label to the bug record.

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

PR Comment: https://git.openjdk.org/jdk/pull/19535#issuecomment-2162083354


From duke at openjdk.org  Wed Jun 12 14:08:43 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Jun 2024 14:08:43 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

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

  Fix clone(), accept review suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19632/files
  - new: https://git.openjdk.org/jdk/pull/19632/files/873164ad..0a9f9624

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

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

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


From duke at openjdk.org  Wed Jun 12 16:22:34 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 12 Jun 2024 16:22:34 GMT
Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec
Message-ID: <e-vL-5NC8ZKnehipG0u51WH06gAAPsrdCSf9_I_hmJY=.e8ca3473-ccca-4fe3-ab7b-2cdfd8a03f6c@github.com>

The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." 

The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs.

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

Commit messages:
 - removed wording about RSA Security LLC

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

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


From mullan at openjdk.org  Wed Jun 12 18:17:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Jun 2024 18:17:12 GMT
Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec
In-Reply-To: <e-vL-5NC8ZKnehipG0u51WH06gAAPsrdCSf9_I_hmJY=.e8ca3473-ccca-4fe3-ab7b-2cdfd8a03f6c@github.com>
References: <e-vL-5NC8ZKnehipG0u51WH06gAAPsrdCSf9_I_hmJY=.e8ca3473-ccca-4fe3-ab7b-2cdfd8a03f6c@github.com>
Message-ID: <IaTvyqwTbipLFjopJv1CnfO1s9bz-Of8q3tmLiHIQ5M=.15c7534f-aa79-404c-86bf-7a6aac742d6b@github.com>

On Wed, 12 Jun 2024 16:18:08 GMT, Ben Perez <duke at openjdk.org> wrote:

> The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." 
> 
> The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19680#pullrequestreview-2113778929


From duke at openjdk.org  Wed Jun 12 19:02:18 2024
From: duke at openjdk.org (Ben Perez)
Date: Wed, 12 Jun 2024 19:02:18 GMT
Subject: Integrated: 8209092: Remove outdated wording from RC5ParameterSpec
In-Reply-To: <e-vL-5NC8ZKnehipG0u51WH06gAAPsrdCSf9_I_hmJY=.e8ca3473-ccca-4fe3-ab7b-2cdfd8a03f6c@github.com>
References: <e-vL-5NC8ZKnehipG0u51WH06gAAPsrdCSf9_I_hmJY=.e8ca3473-ccca-4fe3-ab7b-2cdfd8a03f6c@github.com>
Message-ID: <wcmoJyKR8kSIGnsSQcfHvsvM3D_H_j0B9B5f0eceCd4=.d5b6c68f-1e92-497c-8398-49f9d9e0b29e@github.com>

On Wed, 12 Jun 2024 16:18:08 GMT, Ben Perez <duke at openjdk.org> wrote:

> The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." 
> 
> The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs.

This pull request has now been integrated.

Changeset: 74468bc1
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74468bc1f3aff7f53b91e342711dc095d97fdfed
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8209092: Remove outdated wording from RC5ParameterSpec

Reviewed-by: mullan

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

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


From duke at openjdk.org  Wed Jun 12 20:01:17 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Jun 2024 20:01:17 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <BvlydzBw83D3-PSWvNXu_9Ds0LyC8AzzW9xzSi-uSwU=.f14416dc-d81b-42a0-823b-4d185fac382e@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
 <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
 <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>
 <BvlydzBw83D3-PSWvNXu_9Ds0LyC8AzzW9xzSi-uSwU=.f14416dc-d81b-42a0-823b-4d185fac382e@github.com>
Message-ID: <v1htLuA8OZ7qUFfjMLO7mYeVe8C5xQnjVgN5SDrLIaY=.731b1f56-77c3-4bca-8dcb-f91ae0b24985@github.com>

On Tue, 11 Jun 2024 18:21:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> okay
>
> Could you try using MethodHandles instead of b2lLittle? Similar to what's used in ChaCha20:
> https://github.com/openjdk/jdk/blob/b77bd5fd6a6f7ddbed90300fba790da4fb683275/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java#L132-L134
> 
> with MethodHandles you could drop longBuf, removing unnecessary allocation on the only platform where the intrinsic is implemented (MacOSX-aarch64)

b2lLittle() and l2bLittle() are using those MethodHandle stuff, but yes, it adds some more performance if I use them directly in this class, so I changed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1637007344


From duke at openjdk.org  Wed Jun 12 20:07:13 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Jun 2024 20:07:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <IybE-l30-JTlE3lDXX3yKF3DcuSwEr_zhkeyAKe-wRM=.449faa51-2bfb-4b2a-88aa-c3fe88b41e83@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

tier1,2,3 mach5 tests all passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2163807516


From kvn at openjdk.org  Wed Jun 12 20:44:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Jun 2024 20:44:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <2A2bX3DvWER_CMpvud6qM5u7Y0Dd7uWzPg4rE74snsg=.b12cd3c5-e61d-45a7-a3bf-a2a48c92d257@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

I approve changes in c2.  You need second approval from core libs expert.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19632#pullrequestreview-2114179732


From kvn at openjdk.org  Wed Jun 12 20:44:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Jun 2024 20:44:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <IybE-l30-JTlE3lDXX3yKF3DcuSwEr_zhkeyAKe-wRM=.449faa51-2bfb-4b2a-88aa-c3fe88b41e83@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <IybE-l30-JTlE3lDXX3yKF3DcuSwEr_zhkeyAKe-wRM=.449faa51-2bfb-4b2a-88aa-c3fe88b41e83@github.com>
Message-ID: <vyDHER9T9gVTUfPZKMWvEGK622SjXkcB2RY7fBHpgUA=.6d4ec7d3-9567-4001-bfac-2fffa22207f6@github.com>

On Wed, 12 Jun 2024 20:04:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> tier1,2,3 mach5 tests all passed.

Thank you for testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2163863932


From ascarpino at openjdk.org  Thu Jun 13 01:31:20 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Jun 2024 01:31:20 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <znKiG3AORqvVW-iDV3z38CJgjOTCW-52PkfU_YpBiVs=.fb7806e9-7615-4078-ab98-d6ca1e05170c@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
 <eSLIDCwSEVo3buJukWGH3Xnjkc_cGx3JyHtF1ar2Q58=.9e6417fd-bf71-44fe-a7cf-039f98f7d509@github.com>
 <znKiG3AORqvVW-iDV3z38CJgjOTCW-52PkfU_YpBiVs=.fb7806e9-7615-4078-ab98-d6ca1e05170c@github.com>
Message-ID: <4oFFWi8Ifsp9GN3vB5TTcix3eZfGRCzfD2qQzyjY9DI=.ba4b0d2c-20e1-4dc0-912f-80cfb4e4d314@github.com>

On Wed, 5 Jun 2024 23:49:02 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/templates/TLSBase.java line 246:
>> 
>>> 244:         void done() {
>>> 245:             try {
>>> 246:                 t.join(5000);
>> 
>> I had to increase the join value of a test recently that failed with virtual threads.
>> Try adding `--test-make-args JTREG_TEST_THREAD_FACTORY=Virtual` to your mach5 command line.
>
> I'll check it out.. thanks

Test passed with virtual threads on linux, windows, & mac aarch64

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1637352788


From ascarpino at openjdk.org  Thu Jun 13 01:35:15 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Jun 2024 01:35:15 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <IYiP5vgKLTDWh6IXdLWzUFzLk7jXHUG10qcjnp3Db5U=.8e92bff9-f8da-4c48-94fe-c1141c9356bf@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
 <eSLIDCwSEVo3buJukWGH3Xnjkc_cGx3JyHtF1ar2Q58=.9e6417fd-bf71-44fe-a7cf-039f98f7d509@github.com>
 <znKiG3AORqvVW-iDV3z38CJgjOTCW-52PkfU_YpBiVs=.fb7806e9-7615-4078-ab98-d6ca1e05170c@github.com>
 <IYiP5vgKLTDWh6IXdLWzUFzLk7jXHUG10qcjnp3Db5U=.8e92bff9-f8da-4c48-94fe-c1141c9356bf@github.com>
Message-ID: <_JUUtrQoXfbPGo7GyKyTlKEiG6n1vt8jvbL1Qaj4_Sg=.45e3c600-4709-4c12-abdc-08245b8defd7@github.com>

On Thu, 6 Jun 2024 14:28:25 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I have never heard that.  I have always ended with a plus and I believe everyone else does too if I'm not mistaken.
>
> https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-constants
> 
> Probably showed up in a code review comment from someone.

There are a lot of places where that style is violated.  Looking at just a few random files I didn't see any following the correct style (no scientific study).  I'm going to leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19553#discussion_r1637355972


From syan at openjdk.org  Thu Jun 13 01:50:24 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Jun 2024 01:50:24 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105
Message-ID: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>

Hi all, 
  Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.

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

Commit messages:
 - Merge branch 'openjdk:master' into jbs8334106
 - 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to JDK-8334105

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

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


From clanger at openjdk.org  Thu Jun 13 09:16:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 09:16:12 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105
In-Reply-To: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
Message-ID: <hoPr8puq5ACYgKntnhT_yMnsxRRdBAGugB3Caasnmuo=.91d7b1c4-648d-44b2-8fe2-700135b600e4@github.com>

On Thu, 13 Jun 2024 01:20:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all, 
>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.

We see the same at SAP. I welcome this exclusion.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19685#pullrequestreview-2115234819


From clanger at openjdk.org  Thu Jun 13 09:17:22 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 09:17:22 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
Message-ID: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>

The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

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

Commit messages:
 - JDK-8334201

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

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


From syan at openjdk.org  Thu Jun 13 09:20:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Jun 2024 09:20:12 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105
In-Reply-To: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
Message-ID: <ib45viUkOcre-qJFPPxFsz5RygLX8sAdhkh0v8t931E=.22819b70-1aed-45db-9953-ecb26f7dcf9f@github.com>

On Thu, 13 Jun 2024 01:20:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all, 
>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.

Thanks for the review and approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2165092755


From clanger at openjdk.org  Thu Jun 13 09:24:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 09:24:12 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105
In-Reply-To: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
Message-ID: <wEO987k38oS2sdAOa9_cMcYw8Y_bYHJnwQrwZvUrb3o=.9736043c-7e49-4534-8802-f4431264f294@github.com>

On Thu, 13 Jun 2024 01:20:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all, 
>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.

let's wait a bit with integration before the security folks had a chance to look at this...

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2165102804


From clanger at openjdk.org  Thu Jun 13 09:33:38 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 09:33:38 GMT
Subject: RFR: 8334202: Exclude CAInterop.java#sslrooteccca,sslrootevrsaca
Message-ID: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>

Let's exclude these CAInterop tests until the problem is fixed.

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

Commit messages:
 - JDK-8334202

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

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


From syan at openjdk.org  Thu Jun 13 09:35:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Jun 2024 09:35:14 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105
In-Reply-To: <wEO987k38oS2sdAOa9_cMcYw8Y_bYHJnwQrwZvUrb3o=.9736043c-7e49-4534-8802-f4431264f294@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <wEO987k38oS2sdAOa9_cMcYw8Y_bYHJnwQrwZvUrb3o=.9736043c-7e49-4534-8802-f4431264f294@github.com>
Message-ID: <talBAsowhOp29UZ2NpPBXLpiOIoKZWkDI226Bpc4bB4=.9500d732-982d-4b8b-8400-8e58726be290@github.com>

On Thu, 13 Jun 2024 09:21:41 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> let's wait a bit with integration before the security folks had a chance to look at this...

Okey.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2165126505


From stuefe at openjdk.org  Thu Jun 13 11:18:13 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Jun 2024 11:18:13 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <068aQQ_shmp9ww4D5CoQflHHNr0u6vx2juKvh8tNB20=.daa55b62-fe77-421d-8d07-e65efec7b33e@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

+1

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19689#pullrequestreview-2115496178


From mullan at openjdk.org  Thu Jun 13 11:58:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Jun 2024 11:58:12 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <lyvATemA0pGRJGqNVP79RybSqQTH-0jPOJ3X6t51uE0=.7ce0d70c-83d4-47d8-925f-fda4b4856f57@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

Please wait for @rhalade to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2165443977


From mullan at openjdk.org  Thu Jun 13 12:04:13 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Jun 2024 12:04:13 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105
In-Reply-To: <talBAsowhOp29UZ2NpPBXLpiOIoKZWkDI226Bpc4bB4=.9500d732-982d-4b8b-8400-8e58726be290@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <wEO987k38oS2sdAOa9_cMcYw8Y_bYHJnwQrwZvUrb3o=.9736043c-7e49-4534-8802-f4431264f294@github.com>
 <talBAsowhOp29UZ2NpPBXLpiOIoKZWkDI226Bpc4bB4=.9500d732-982d-4b8b-8400-8e58726be290@github.com>
Message-ID: <gg-hzChXoffO3LVUbxjBBrOuB2zmdaeszcktPFaARdk=.b832ddde-822d-4c2f-9adc-3ec0064bb2ae@github.com>

On Thu, 13 Jun 2024 09:32:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> let's wait a bit with integration before the security folks had a chance to look at this...

Thanks. Please wait for @rhalade to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2165456827


From clanger at openjdk.org  Thu Jun 13 12:04:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 12:04:15 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <lyvATemA0pGRJGqNVP79RybSqQTH-0jPOJ3X6t51uE0=.7ce0d70c-83d4-47d8-925f-fda4b4856f57@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
 <lyvATemA0pGRJGqNVP79RybSqQTH-0jPOJ3X6t51uE0=.7ce0d70c-83d4-47d8-925f-fda4b4856f57@github.com>
Message-ID: <d6KE7gmY_NQuN9JWPGuTuN7DnRFcWdTfW37PdloPQ-s=.b44505ce-5e44-40de-960c-5955b0418cb8@github.com>

On Thu, 13 Jun 2024 11:55:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please wait for @rhalade to review.

Will do. There's also #19685 and #19690. These are somewhat annoying and I'd prefer if we could exclude them for the time being.

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2165457194


From syan at openjdk.org  Thu Jun 13 12:21:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Jun 2024 12:21:23 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
Message-ID: <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>

> Hi all, 
>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.

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

 - Merge branch 'jbs8334106' of github.com:sendaoYan/jdk-ysd into jbs8334106
 - add whitespaces for alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19685/files
  - new: https://git.openjdk.org/jdk/pull/19685/files/0ae0d31f..a60819e2

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

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

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


From syan at openjdk.org  Thu Jun 13 12:43:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Jun 2024 12:43:37 GMT
Subject: RFR: 8333938: Exclude CAInterop.java#digicerttlsrsarootg5
Message-ID: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>

Hi all,
Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlsrsarootg5` report failure as failed to validate, before the validate issue has been fixed, should we problem list the testcase.

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

Commit messages:
 - 8333938: Exclude CAInterop.java#digicerttlsrsarootg5

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

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


From clanger at openjdk.org  Thu Jun 13 13:16:38 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:16:38 GMT
Subject: [jdk23] RFR: 8333724: Problem list
 security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1
Message-ID: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>

Hi all,

This pull request contains a backport of [JDK-8333724](https://bugs.openjdk.org/browse/JDK-8333724), commit [8ffc35d1](https://github.com/openjdk/jdk/commit/8ffc35d117846a7a2aa08afed662273d2f887770) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Matthias Baesken on 7 Jun 2024 and was reviewed by Lutz Schmidt and Sergey Bylokhov.

Since this is a test update, it can be pushed under RDP1 ruling.

Thanks!
Christoph

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

Commit messages:
 - Backport 8ffc35d117846a7a2aa08afed662273d2f887770

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

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


From mbaesken at openjdk.org  Thu Jun 13 13:20:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Jun 2024 13:20:15 GMT
Subject: [jdk23] RFR: 8333724: Problem list
 security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1
In-Reply-To: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
References: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
Message-ID: <nr8iQCsofLE_D8GOBXFv3EyZgGuWRosuckg6yzq5RYU=.f9c9a106-252a-412d-b681-8398590a3fd1@github.com>

On Thu, 13 Jun 2024 13:07:23 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8333724](https://bugs.openjdk.org/browse/JDK-8333724), commit [8ffc35d1](https://github.com/openjdk/jdk/commit/8ffc35d117846a7a2aa08afed662273d2f887770) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Matthias Baesken on 7 Jun 2024 and was reviewed by Lutz Schmidt and Sergey Bylokhov.
> 
> Since this is a test update, it can be pushed under RDP1 ruling.
> 
> Thanks!
> Christoph

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19697#pullrequestreview-2115772662


From mpowers at openjdk.org  Thu Jun 13 13:21:18 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 13 Jun 2024 13:21:18 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider
In-Reply-To: <HWn7vIVWpZUTBx83VtNhTiBuoGXSBHwuXsXRK-tiyrU=.270fe026-64e9-44a2-a7e1-89cb0f1437a7@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <HWn7vIVWpZUTBx83VtNhTiBuoGXSBHwuXsXRK-tiyrU=.270fe026-64e9-44a2-a7e1-89cb0f1437a7@github.com>
Message-ID: <tnU6jrnnzwUarWNRhApxyYhH5nzUKOzb-eFZFKdePY8=.07748e2a-e50b-454c-959c-eb5941aba42c@github.com>

On Thu, 6 Jun 2024 20:10:10 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8333364
>
> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 121:
> 
>> 119:     @Override
>> 120:     int encrypt(byte[] pt, int ptOfs, int ptLen, byte[] ct, int ctOfs) {
>> 121:         throw new UnsupportedOperationException("multi-part not supported");
> 
> Change the error message as well?

Yes. None of our tests check for this error message.

> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 127:
> 
>> 125:     @Override
>> 126:     int decrypt(byte[] ct, int ctOfs, int ctLen, byte[] pt, int ptOfs) {
>> 127:         throw new UnsupportedOperationException("multi-part not supported");
> 
> Change the error message as well?

Yes.

> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 159:
> 
>> 157:     @Override
>> 158:     int encrypt(byte[] pt, int ptOfs, int ptLen, byte[] ct, int ctOfs) {
>> 159:         throw new UnsupportedOperationException("multi-part not supported");
> 
> Change the error message as well?

Yes.

> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 165:
> 
>> 163:     @Override
>> 164:     int decrypt(byte[] ct, int ctOfs, int ctLen, byte[] pt, int ptOfs) {
>> 165:         throw new UnsupportedOperationException("multi-part not supported");
> 
> Change the error message as well?

Yes.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 678:
> 
>> 676:     protected int engineUpdate(byte[] in, int inOfs, int inLen,
>> 677:             byte[] out, int outOfs) throws ShortBufferException {
>> 678:         int bytesUpdated;
> 
> Not relevant to this line, but rather down below in the javadoc of `engineUpdate(ByteBuffer, ByteBuffer)`, the javadoc has {@code out} but the variable name is `output`, probably a copy-n-paste error from this method.

Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 764:
> 
>> 762:     @Override
>> 763:     protected int engineDoFinal(byte[] in, int inOfs, int inLen, byte[] out,
>> 764:             int outOfs) throws ShortBufferException, AEADBadTagException {
> 
> Not relevant to this line, but down below in the javadoc of `engineDoFinal(ByteBuffer, ByteBuffer)`, the method throws `ShortBufferException`, but the javadoc doesn't have it.

Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 874:
> 
>> 872:         int len = Math.addExact(buffered, inputLen);
>> 873:         // calculate padding length
>> 874:         int totalLen = len;
> 
> Well, personally, I'd prefer to replace `len` with `totalLen`, less changes overall and better naming matching the comment on line 871.

Okay.

> src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 408:
> 
>> 406:             if (keysize >= BlowfishConstants.BLOWFISH_MAX_KEYSIZE)
>> 407:                 keysize = BlowfishConstants.BLOWFISH_MAX_KEYSIZE;
>> 408:             return new SecretKeySpec(secret, 0, keysize,
> 
> nit: merge the following line, i.e. "Blowfish", with this line?

Done.

> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 214:
> 
>> 212:     {
>> 213:         String kdfAlgo;
>> 214:         String cipherAlgo;
> 
> nit: merge these with where they are assigned?

Done.

> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 243:
> 
>> 241: 
>> 242:         this.pbes2AlgorithmName = "PBEWith" +
>> 243:                 kdfAlgo + "And" + cipherAlgo;
> 
> nit: move to one line if less than 80 chars.

75 chars. It's now one line.

> src/java.base/share/classes/com/sun/crypto/provider/RC2Parameters.java line 224:
> 
>> 222: 
>> 223:         if (version != 0) {
>> 224:             sb.append(LINE_SEP).append("version:").append(LINE_SEP).append(version).append(LINE_SEP);
> 
> Well, the original code is easier to read. Probably no difference performance-wise given it's just  a few known strings. Why bother especially when the StringBuilder constructor also uses `+`?

The original code really is easier to read. I'll revert the change.

> src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java line 276:
> 
>> 274:         outputSize = n;
>> 275:         bufOfs = 0;
>> 276:         if (Objects.equals(paddingType, PAD_NONE)) {
> 
> Not sure if this is necessary, with the current impl, `paddingType` is always assigned with one of internal PAD_XXX constants. Did I miss something?

You are correct. IJ ignored details of the implementation . `==` will work fine. I'll revert the change.

> src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 109:
> 
>> 107:         SecretKey serverMacKey = null;
>> 108:         SecretKey clientCipherKey;
>> 109:         SecretKey serverCipherKey;
> 
> nit: move them down to line 200, e.g. where these two variables are assigned?

No. The two variables wouldn't be in scope for the `finally` block on line 276.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638199883
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638200163
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638200674
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638201294
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638201606
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638201931
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638203464
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638203212
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638203036
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638202768
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638202592
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638202361
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638202186


From clanger at openjdk.org  Thu Jun 13 13:28:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:28:14 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
Message-ID: <rSiZl_r0yFV2FNacxBQueScoeNzf-rF26n_HDJIAqn8=.a5cc72d1-3fc9-4992-8fe3-fea55cd068c0@github.com>

On Thu, 13 Jun 2024 12:21:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all, 
>>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'jbs8334106' of github.com:sendaoYan/jdk-ysd into jbs8334106
>  - add whitespaces for alignment

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19685#pullrequestreview-2115800931


From clanger at openjdk.org  Thu Jun 13 13:28:17 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:28:17 GMT
Subject: [jdk23] RFR: 8333724: Problem list
 security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1
In-Reply-To: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
References: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
Message-ID: <L7t-nHdGVbXFlu1s_mFIhS1BvKaG9_IsxdcNzYyOr_A=.e21836a9-c265-4c40-8a15-ba9811c19922@github.com>

On Thu, 13 Jun 2024 13:07:23 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8333724](https://bugs.openjdk.org/browse/JDK-8333724), commit [8ffc35d1](https://github.com/openjdk/jdk/commit/8ffc35d117846a7a2aa08afed662273d2f887770) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Matthias Baesken on 7 Jun 2024 and was reviewed by Lutz Schmidt and Sergey Bylokhov.
> 
> Since this is a test update, it can be pushed under RDP1 ruling.
> 
> Thanks!
> Christoph

trivial backport, so

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

PR Comment: https://git.openjdk.org/jdk/pull/19697#issuecomment-2165667394


From clanger at openjdk.org  Thu Jun 13 13:28:17 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:28:17 GMT
Subject: [jdk23] Integrated: 8333724: Problem list
 security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1
In-Reply-To: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
References: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
Message-ID: <WXlFYc7DA_E5dQtthVfhfAQSz4YN1wK_pzV_fY_CUmw=.58c321e1-2bd9-49b6-ab9a-6265e869289e@github.com>

On Thu, 13 Jun 2024 13:07:23 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8333724](https://bugs.openjdk.org/browse/JDK-8333724), commit [8ffc35d1](https://github.com/openjdk/jdk/commit/8ffc35d117846a7a2aa08afed662273d2f887770) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Matthias Baesken on 7 Jun 2024 and was reviewed by Lutz Schmidt and Sergey Bylokhov.
> 
> Since this is a test update, it can be pushed under RDP1 ruling.
> 
> Thanks!
> Christoph

This pull request has now been integrated.

Changeset: 378cd12f
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/378cd12f6bcb8f2bdcd7ceb307755ef7d3aa082a
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8333724: Problem list security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1

Reviewed-by: mbaesken
Backport-of: 8ffc35d117846a7a2aa08afed662273d2f887770

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

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


From mpowers at openjdk.org  Thu Jun 13 13:31:26 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 13 Jun 2024 13:31:26 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v2]
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <p_NuNXeeEalFrHi4tRrEf28l10iGuVXTWuhuSleQQJk=.c2e104f6-0677-4554-bf49-bd77cd077de8@github.com>

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

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

  comments from Valerie

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19535/files
  - new: https://git.openjdk.org/jdk/pull/19535/files/3472c998..a8b7e2bd

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

  Stats: 29 lines in 8 files changed: 5 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/19535.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19535/head:pull/19535

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


From weijun at openjdk.org  Thu Jun 13 14:06:26 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Jun 2024 14:06:26 GMT
Subject: RFR: 8330217: Spurious warning from jarsigner -verify when keystore
 with intermediate CA is used
Message-ID: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com>

There is an error in `jarsigner` on the "This JAR contains signed entries that aren't signed by alias in this keystore" warning. The exit code is determined by [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L344) but the warning message is controlled by [`allAliasesFound`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L1183).

Also, inside the `inKeyStoreForOneSigner()` method, all certificates in a cert chain are used to determine whether the signer is in a keystore and if any is inside the JAR file is treated as being signed by an alias in this keystore. In fact, only the end-entity certificate (the first one in the chain) should be checked.

After the fix, the `allAliasesFound` field and the `SOME_ALIASES_NOT_FOUND` constant are useless and can be removed.

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

Commit messages:
 - the fix

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

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


From syan at openjdk.org  Thu Jun 13 14:41:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Jun 2024 14:41:13 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
Message-ID: <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>

On Thu, 13 Jun 2024 12:21:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all, 
>>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'jbs8334106' of github.com:sendaoYan/jdk-ysd into jbs8334106
>  - add whitespaces for alignment

Thanks for the approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2165868555


From ascarpino at openjdk.org  Thu Jun 13 15:45:15 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Jun 2024 15:45:15 GMT
Subject: RFR: 8330217: Spurious warning from jarsigner -verify when
 keystore with intermediate CA is used
In-Reply-To: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com>
References: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com>
Message-ID: <v8cshYs97A8uIlBtvckhxpGjKdfHYITKWayJqxZf2Fs=.9ed29a48-3724-44a3-bcb6-d6ad50c0a5b5@github.com>

On Thu, 13 Jun 2024 14:01:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There is an error in `jarsigner` on the "This JAR contains signed entries that aren't signed by alias in this keystore" warning. The exit code is determined by [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L344) but the warning message is controlled by [`allAliasesFound`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L1183).
> 
> Also, inside the `inKeyStoreForOneSigner()` method, all certificates in a cert chain are used to determine whether the signer is in a keystore and if any is inside the JAR file is treated as being signed by an alias in this keystore. In fact, only the end-entity certificate (the first one in the chain) should be checked.
> 
> After the fix, the `allAliasesFound` field and the `SOME_ALIASES_NOT_FOUND` constant are useless and can be removed.

Main.java needs the copyright updated

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

PR Review: https://git.openjdk.org/jdk/pull/19701#pullrequestreview-2116170502


From ascarpino at openjdk.org  Thu Jun 13 15:48:13 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Jun 2024 15:48:13 GMT
Subject: RFR: 8330217: Spurious warning from jarsigner -verify when
 keystore with intermediate CA is used
In-Reply-To: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com>
References: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com>
Message-ID: <HGxY0AyV3XOJpmM_XU3p-eunGavhnK6BKlIMLtL0EmQ=.63779a90-20b4-4078-b548-a2ea30e4ec2b@github.com>

On Thu, 13 Jun 2024 14:01:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There is an error in `jarsigner` on the "This JAR contains signed entries that aren't signed by alias in this keystore" warning. The exit code is determined by [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L344) but the warning message is controlled by [`allAliasesFound`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L1183).
> 
> Also, inside the `inKeyStoreForOneSigner()` method, all certificates in a cert chain are used to determine whether the signer is in a keystore and if any is inside the JAR file is treated as being signed by an alias in this keystore. In fact, only the end-entity certificate (the first one in the chain) should be checked.
> 
> After the fix, the `allAliasesFound` field and the `SOME_ALIASES_NOT_FOUND` constant are useless and can be removed.

Since this is changing exit codes, does it deserve a release note?  Otherwise the change looks fine.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19701#pullrequestreview-2116179077


From weijun at openjdk.org  Thu Jun 13 16:53:15 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Jun 2024 16:53:15 GMT
Subject: RFR: 8330217: Spurious warning from jarsigner -verify when
 keystore with intermediate CA is used
In-Reply-To: <HGxY0AyV3XOJpmM_XU3p-eunGavhnK6BKlIMLtL0EmQ=.63779a90-20b4-4078-b548-a2ea30e4ec2b@github.com>
References: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com>
 <HGxY0AyV3XOJpmM_XU3p-eunGavhnK6BKlIMLtL0EmQ=.63779a90-20b4-4078-b548-a2ea30e4ec2b@github.com>
Message-ID: <mh_mgjDKKMa_SxZUqoVkboimc2-fk3rcDHfefNr8AUE=.1d454ce0-59f9-4cee-8f2a-73ef6a6cbf00@github.com>

On Thu, 13 Jun 2024 15:45:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> There is an error in `jarsigner` on the "This JAR contains signed entries that aren't signed by alias in this keystore" warning. The exit code is determined by [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L344) but the warning message is controlled by [`allAliasesFound`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L1183).
>> 
>> Also, inside the `inKeyStoreForOneSigner()` method, all certificates in a cert chain are used to determine whether the signer is in a keystore and if any is inside the JAR file is treated as being signed by an alias in this keystore. In fact, only the end-entity certificate (the first one in the chain) should be checked.
>> 
>> After the fix, the `allAliasesFound` field and the `SOME_ALIASES_NOT_FOUND` constant are useless and can be removed.
>
> Since this is changing exit codes, does it deserve a release note?  Otherwise the change looks fine.

@ascarpino Thanks for the review. I'll write a release note. I can even write a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19701#issuecomment-2166230304


From sgehwolf at openjdk.org  Thu Jun 13 16:55:13 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 13 Jun 2024 16:55:13 GMT
Subject: RFR: 8334202: Exclude CAInterop.java#sslrooteccca,sslrootevrsaca
In-Reply-To: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
References: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
Message-ID: <o9mk_Zr0dI6gxcgZnEXPOeHlADisvYH4JiFMIKesjZ8=.8bef4cb0-1eac-46d9-8395-4c2a68c067f4@github.com>

On Thu, 13 Jun 2024 09:25:11 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Let's exclude these CAInterop tests until the problem is fixed.

Seems fine to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19690#pullrequestreview-2116347370


From mullan at openjdk.org  Thu Jun 13 18:09:13 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Jun 2024 18:09:13 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
 <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
Message-ID: <AcGM3PgUdrk0KyjigwpQgZCnmY8nbMWkcaZl7mIg3WA=.8731dc72-c4a9-4b30-bafb-ea96460cc51d@github.com>

On Thu, 13 Jun 2024 14:38:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'jbs8334106' of github.com:sendaoYan/jdk-ysd into jbs8334106
>>  - add whitespaces for alignment
>
> Thanks for the approved.

@sendaoYan  As a best practice, it would be useful to first understand why the test is not working before putting it on the ProblemList. Depending on the severity of the problem that is not always possible, but it should be the first step in an evaluation in my opinion. Minimally, the referenced issue should have an Assignee so that it is assured someone will look into it. Once an issue is on the ProblemList, it unfortunately doesn't address the underlying issue, and may not get the same attention if some evaluation had been done beforehand. Another suggestion is to ask about it on the OpenJDK security-dev alias, where there are Security Group members who have more experience with these tests and can decide what the best course of action is.

The infra tests are not part of any of our CI tiers, so generally there is more time to investigate and figure out what the issue is in tests like this before putting it on the Problem List. Often the certificate tests fail because of an issue on the CA side, which sometimes can be fixed quickly after contacting the CA.

In summary, please hold off on adding this test to the ProblemList until we have some time to evaluate the test failure. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2166469533


From mullan at openjdk.org  Thu Jun 13 18:38:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Jun 2024 18:38:20 GMT
Subject: RFR: 8333938: Exclude CAInterop.java#digicerttlsrsarootg5
In-Reply-To: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
References: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
Message-ID: <OWbFlyhvBbQVvrlIi8eBs2C07sLhuoZ3DqZQvBTzhSE=.d24f6199-f518-4f12-b2da-a1f2214b0d5b@github.com>

On Thu, 13 Jun 2024 12:32:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlsrsarootg5` report failure as failed to validate, before the validate issue has been fixed, should we problem list the testcase.

@sendaoYan See my other comment: https://github.com/openjdk/jdk/pull/19685#issuecomment-2166469533. I think it is premature to add this to the ProblemList until some initial evaluation has been done to try to determine the cause of the test failure.

Also, I see you have closed https://bugs.openjdk.org/browse/JDK-8333937 (which is on the ProblemList entry you are proposing to add), and you think it might be the same as [JDK-8334105](https://bugs.openjdk.org/browse/JDK-8334105). Closed issues should never be put on the PL. Clearly, this indicates to me there needs to be some additional work/eval before proposing to put this on the PL.

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

PR Comment: https://git.openjdk.org/jdk/pull/19694#issuecomment-2166523983


From ascarpino at openjdk.org  Thu Jun 13 20:23:36 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Jun 2024 20:23:36 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
Message-ID: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>

Hi

This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.

The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.

A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

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

Commit messages:
 - Merge branch 'master' into nst-multi
 - copyright & cleanup
 - oops BAOS
 - Fix Windows networking problem
 - Updates for debug
 - more cleanup, more comments
 - Cleanup, synchronizing, and docs
 - merge back into Cache.java
 - remove commented out code
 - udpates
 - ... and 4 more: https://git.openjdk.org/jdk/compare/301bd708...fc7c5419

Changes: https://git.openjdk.org/jdk/pull/19465/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19465&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328608
  Stats: 642 lines in 8 files changed: 507 ins; 54 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/19465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19465/head:pull/19465

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


From jnimeh at openjdk.org  Thu Jun 13 20:23:36 2024
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Jun 2024 20:23:36 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <eBrc1lr_voa0Ho189jHE2QtafSo-hU0QcriiQqZDJEI=.9670324c-c6ba-43fe-8528-4880d91956d7@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 202:

> 200:         if (nstServerCount == null || nstServerCount < 1 ||
> 201:             nstServerCount > 10) {
> 202:             serverNewSessionTicketCount = 3;

I'm always on the fence about this, but do you think it is worthwhile to put a debug log message here so folks can tell why their value is getting altered to a default 3?  If we don't do it for other props then it's probably not worth it, but I thought I'd ask.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 503:

> 501:                 this.preSharedKey = new SecretKeySpec(b, alg);
> 502:                 // Get identity len
> 503:                 i = buf.get();

Given that this is just a small change to a large function it may not be important to change, but a lot of these X-byte lengths followed by arrays might be simplified with Record.getBytes8 or the other similar routines that handle longer length fields.  But you wouldn't end up with a null byte[] when the length is zero, so that's a change, not necessarily a down-side.

src/java.base/share/classes/sun/security/util/Cache.java line 683:

> 681: 
> 682:         // Limit the number of queue entries.
> 683:         private static final int MAXQUEUESIZE = 10;

What do you think about making this tunable through the constructor, perhaps with a default value of 10?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1626171765
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1626184113
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1628114149


From ascarpino at openjdk.org  Thu Jun 13 20:23:36 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Jun 2024 20:23:36 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <eBrc1lr_voa0Ho189jHE2QtafSo-hU0QcriiQqZDJEI=.9670324c-c6ba-43fe-8528-4880d91956d7@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <eBrc1lr_voa0Ho189jHE2QtafSo-hU0QcriiQqZDJEI=.9670324c-c6ba-43fe-8528-4880d91956d7@github.com>
Message-ID: <fU5bsFzAyK0Df2k1Zr6Uxs8iK_a3SRb8N5lVHoYeI4w=.81a69385-da8f-4221-ae7a-b3ff5f4e3552@github.com>

On Tue, 4 Jun 2024 15:04:56 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 503:
> 
>> 501:                 this.preSharedKey = new SecretKeySpec(b, alg);
>> 502:                 // Get identity len
>> 503:                 i = buf.get();
> 
> Given that this is just a small change to a large function it may not be important to change, but a lot of these X-byte lengths followed by arrays might be simplified with Record.getBytes8 or the other similar routines that handle longer length fields.  But you wouldn't end up with a null byte[] when the length is zero, so that's a change, not necessarily a down-side.

I think that's something to consider as a new RFE as it would have a scope outside of this change

> src/java.base/share/classes/sun/security/util/Cache.java line 683:
> 
>> 681: 
>> 682:         // Limit the number of queue entries.
>> 683:         private static final int MAXQUEUESIZE = 10;
> 
> What do you think about making this tunable through the constructor, perhaps with a default value of 10?

I thought about this, but found no reason as this is an internal API.   `QueueCacheEntry<>` is only for TLS client NewSessionTicket situation and the API would have to set that at the time the whole cache is built.  Even with that, it would still be a hard coded number, just somewhere else.  Unless we have yet another system property.  I don?t see a need for individual tuning at this time and we can always up the hardcoded limit if more are needed. If it is necessary in the future we can revisit this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1638775456
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1628164520


From valeriep at openjdk.org  Thu Jun 13 20:28:16 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 13 Jun 2024 20:28:16 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

src/java.base/share/classes/sun/security/provider/SHA3.java line 73:

> 71:     // The following array is allocated to size WIDTH bytes, but we only
> 72:     // ever use the first blockSize bytes it (for bytes <-> long conversions)
> 73:     private byte[] byteState = new byte[WIDTH];

Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?

src/java.base/share/classes/sun/security/provider/SHA3.java line 121:

> 119:         }
> 120:         implCompress(buffer, 0);
> 121:         int availableBytes = buffer.length;

change to `blockSize` as in `implCompress0(...)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1638832540
PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1637350489


From mpowers at openjdk.org  Thu Jun 13 20:56:52 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 13 Jun 2024 20:56:52 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v3]
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <wmuao_uODmZe0MEfa-Rs28Ng7sdBbCYZzpSiT5LD_wA=.419c8786-a3a6-4ddb-ac62-1d86e5c4915a@github.com>

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

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

  join two lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19535/files
  - new: https://git.openjdk.org/jdk/pull/19535/files/a8b7e2bd..3bf59f72

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

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

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


From mpowers at openjdk.org  Thu Jun 13 20:56:52 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 13 Jun 2024 20:56:52 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v3]
In-Reply-To: <V9OTT5AISuXXz1X5FcdhhGghVjPvI45Ep2x7ClicH-I=.4e4d95b0-81a9-48f3-b8ba-8fcc58c052fa@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <V9OTT5AISuXXz1X5FcdhhGghVjPvI45Ep2x7ClicH-I=.4e4d95b0-81a9-48f3-b8ba-8fcc58c052fa@github.com>
Message-ID: <qjYCTldib6A-9oymzAiYpiaMWneRAjIoP7VP656EZ8s=.d48c36bc-7387-4f09-84af-0c5f35de8352@github.com>

On Wed, 12 Jun 2024 04:15:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   join two lines
>
> src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 969:
> 
>> 967:     private int finalNoPadding(byte[] in, int inOfs, byte[] out, int outOfs,
>> 968:                                int len)
>> 969:         throws IllegalBlockSizeException {
> 
> Hmm, is ShortBufferException still needed for `prepareInputBuffer(...)` and `fillOutputBuffer(...)`?

Not needed by `fillOutputBuffer(..)` but needed by `prepareInputBuffer(...)`.
IJ was right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638921875


From valeriep at openjdk.org  Thu Jun 13 21:26:17 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 13 Jun 2024 21:26:17 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v3]
In-Reply-To: <tnU6jrnnzwUarWNRhApxyYhH5nzUKOzb-eFZFKdePY8=.07748e2a-e50b-454c-959c-eb5941aba42c@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <HWn7vIVWpZUTBx83VtNhTiBuoGXSBHwuXsXRK-tiyrU=.270fe026-64e9-44a2-a7e1-89cb0f1437a7@github.com>
 <tnU6jrnnzwUarWNRhApxyYhH5nzUKOzb-eFZFKdePY8=.07748e2a-e50b-454c-959c-eb5941aba42c@github.com>
Message-ID: <BojFH_3MSfWY3jNh4qcKZxHmX5PeyKT-gLuEuxObt1Q=.6261c05f-fc78-4c48-9d4a-8b82c1a610c2@github.com>

On Thu, 13 Jun 2024 13:18:10 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 109:
>> 
>>> 107:         SecretKey serverMacKey = null;
>>> 108:         SecretKey clientCipherKey;
>>> 109:         SecretKey serverCipherKey;
>> 
>> nit: move them down to line 200, e.g. where these two variables are assigned?
>
> No. The two variables wouldn't be in scope for the `finally` block on line 276.

How about right above the block where they are assigned? The reason that I suggested this is that it's easier to see why no default value needed when they are placed nearer to where they are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638966495


From mpowers at openjdk.org  Thu Jun 13 21:35:13 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 13 Jun 2024 21:35:13 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v3]
In-Reply-To: <BojFH_3MSfWY3jNh4qcKZxHmX5PeyKT-gLuEuxObt1Q=.6261c05f-fc78-4c48-9d4a-8b82c1a610c2@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <HWn7vIVWpZUTBx83VtNhTiBuoGXSBHwuXsXRK-tiyrU=.270fe026-64e9-44a2-a7e1-89cb0f1437a7@github.com>
 <tnU6jrnnzwUarWNRhApxyYhH5nzUKOzb-eFZFKdePY8=.07748e2a-e50b-454c-959c-eb5941aba42c@github.com>
 <BojFH_3MSfWY3jNh4qcKZxHmX5PeyKT-gLuEuxObt1Q=.6261c05f-fc78-4c48-9d4a-8b82c1a610c2@github.com>
Message-ID: <PuNuzrZZeXCt9txpfM2II3MoPfCbe7zSMN2T_zVWye8=.a3a461da-ffab-447a-8a83-33ac40b207b6@github.com>

On Thu, 13 Jun 2024 21:23:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> No. The two variables wouldn't be in scope for the `finally` block on line 276.
>
> How about right above the block where they are assigned? The reason that I suggested this is that it's easier to see why no default value needed when they are placed nearer to where they are used.

Right above the `try` block? That would work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1638973897


From valeriep at openjdk.org  Fri Jun 14 00:16:14 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 00:16:14 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v3]
In-Reply-To: <wmuao_uODmZe0MEfa-Rs28Ng7sdBbCYZzpSiT5LD_wA=.419c8786-a3a6-4ddb-ac62-1d86e5c4915a@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <wmuao_uODmZe0MEfa-Rs28Ng7sdBbCYZzpSiT5LD_wA=.419c8786-a3a6-4ddb-ac62-1d86e5c4915a@github.com>
Message-ID: <axERHn2TjafnjsEuGWZ-48unRzG8NBEykc2PXBW2daE=.e0b157a7-ea4d-4db9-bafb-c6bfc0cc80d5@github.com>

On Thu, 13 Jun 2024 20:56:52 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

Updates look good.

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

PR Review: https://git.openjdk.org/jdk/pull/19535#pullrequestreview-2117209216


From syan at openjdk.org  Fri Jun 14 01:01:17 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Jun 2024 01:01:17 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
 <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
Message-ID: <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>

On Thu, 13 Jun 2024 14:38:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'jbs8334106' of github.com:sendaoYan/jdk-ysd into jbs8334106
>>  - add whitespaces for alignment
>
> Thanks for the approved.

> @sendaoYan As a best practice, it would be useful to first understand why the test is not working before putting it on the ProblemList. Depending on the severity of the problem that is not always possible, but it should be the first step in an evaluation in my opinion. Minimally, the referenced issue should have an Assignee so that it is assured someone will look into it. Once an issue is on the ProblemList, it unfortunately doesn't address the underlying issue, and may not get the same attention if some evaluation had been done beforehand. Another suggestion is to ask about it on the OpenJDK security-dev alias, where there are Security Group members who have more experience with these tests and can decide what the best course of action is.
> 
> The infra tests are not part of any of our CI tiers, so generally there is more time to investigate and figure out what the issue is in tests like this before putting it on the Problem List. Often the certificate tests fail because of an issue on the CA side, which sometimes can be fixed quickly after contacting the CA.
> 
> In summary, please hold off on adding this test to the ProblemList until we have some time to evaluate the test failure. Thank you.

Got it. Thank you for your detailed explanation.
If this issue fails cause by CA side or some other reason, and the the failure can fixed quickly, I think we should close these related PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2167025419


From syan at openjdk.org  Fri Jun 14 01:09:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Jun 2024 01:09:12 GMT
Subject: RFR: 8333938: Exclude CAInterop.java#digicerttlsrsarootg5
In-Reply-To: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
References: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
Message-ID: <z18IsC6h1Co713o-An-RvXCTL4e4BPm4Te9_SRDYEhQ=.e64c53a3-93b0-41bf-b7c8-8e0925bab0b4@github.com>

On Thu, 13 Jun 2024 12:32:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlsrsarootg5` report failure as failed to validate, before the validate issue has been fixed, should we problem list the testcase.

> @sendaoYan See my other comment: [#19685 (comment)](https://github.com/openjdk/jdk/pull/19685#issuecomment-2166469533). I think it is premature to add this to the ProblemList until some initial evaluation has been done to try to determine the cause of the test failure.
> 
> Also, I see you have closed https://bugs.openjdk.org/browse/JDK-8333937 (which is on the ProblemList entry you are proposing to add), and you think it might be the same as [JDK-8334105](https://bugs.openjdk.org/browse/JDK-8334105). Closed issues should never be put on the PL. Clearly, this indicates to me there needs to be some additional work/eval before proposing to put this on the PL.

Sorry, I think I closed the issue due to misoperation. I have reopened the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/19694#issuecomment-2167031417


From jnimeh at openjdk.org  Fri Jun 14 01:17:14 2024
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 14 Jun 2024 01:17:14 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <PSao292oeYC3Lit4E4EcZMAQXci-IVluJKDFKl-vA9o=.7267844c-8d7d-4084-af39-01689da33fb0@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 127:

> 125:     static final int serverNewSessionTicketCount;
> 126:     // Default for NST
> 127:     static final int SERVER_NST_DEFAULT = 3;

I suggest you make the default 1 or 2 rather than 3.  NSTs can get pretty large and we may want to preserve bandwidth a bit, especially for servers at scale.  I think for many applications the default we're currently doing of 1 NST per connection might be enough, and the property allows folks to ratchet up the number of NSTs to fit their needs.  But defaulting to 2 is probably fine also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639095203


From aturbanov at openjdk.org  Fri Jun 14 05:58:12 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 14 Jun 2024 05:58:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <aj_JZwbKHtrr6yjsmjNU1nAoJBGmAKgC5mJMR6BVfx4=.6b322db3-5c6c-461a-b586-2c7560433b27@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

src/java.base/share/classes/sun/security/provider/SHA3.java line 152:

> 150:      */
> 151:     void implReset() {
> 152:         Arrays.fill(state,0L);

Suggestion:

        Arrays.fill(state, 0L);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639301465


From ssahoo at openjdk.org  Fri Jun 14 06:27:29 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 14 Jun 2024 06:27:29 GMT
Subject: RFR: 8333754: Add a Test against ECDSA and ECDH NIST Test vector
Message-ID: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>

Tests added against ECDSA and ECDH NIST Test vector.

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

Commit messages:
 - 8333754: Add a Test against ECDSA and ECDH NIST Test vector
 - 8333754: Add ECDSAPrimitive.java to open repo

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

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


From ssahoo at openjdk.org  Fri Jun 14 06:38:14 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 14 Jun 2024 06:38:14 GMT
Subject: RFR: 8333754: Add a Test against ECDSA and ECDH NIST Test vector
In-Reply-To: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
References: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
Message-ID: <cYIY2lTXryNOYFCbtI85vVOo7gwtPDz313_k4CMUF-Y=.c73270f9-9cf1-40e5-a5af-619281a234a3@github.com>

On Fri, 14 Jun 2024 06:23:32 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Tests added against ECDSA and ECDH NIST Test vector.

test/jdk/sun/security/ec/ECDHPrimitive.java line 33:

> 31: import javax.crypto.*;
> 32: 
> 33: import jdk.test.lib.Asserts;

Usage of Asserts and removed corresponding local code

test/jdk/sun/security/ec/ECDHPrimitive.java line 40:

> 38:  * @summary Test ECDH primitive operations
> 39:  * @library /test/lib
> 40:  * @run main ECDHPrimitive

disableNative removed from @run tag

test/jdk/sun/security/ec/ECDHPrimitive.java line 52:

> 50: 
> 51:     public static void main(String[] args) throws Exception {
> 52:         Path testFile = Path.of(System.getProperty("test.src"), "KAS_ECC_CDH_PrimitiveTest.txt");

Referring Test vector from SRC path

test/jdk/sun/security/ec/ECDSAPrimitive.java line 35:

> 33: import sun.security.util.ArrayUtil;
> 34: import sun.security.util.math.*;
> 35: import jdk.test.lib.Asserts;

Use of Asserts and removed corresponding local code.

test/jdk/sun/security/ec/ECDSAPrimitive.java line 44:

> 42:  * @modules java.base/sun.security.ec java.base/sun.security.ec.point
> 43:  *          java.base/sun.security.util java.base/sun.security.util.math
> 44:  * @run main ECDSAPrimitive

disableNative removed from @run tag

test/jdk/sun/security/ec/ECDSAPrimitive.java line 61:

> 59: 
> 60:     public static void main(String[] args) throws Exception {
> 61:         Path siggenFile = Path.of(System.getProperty("test.src"), "SigGen-1.txt");

Referring Test vector from SRC path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639334746
PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639334250
PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639335093
PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639335860
PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639335470
PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639336133


From ssahoo at openjdk.org  Fri Jun 14 06:57:12 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 14 Jun 2024 06:57:12 GMT
Subject: RFR: 8333754: Add a Test against ECDSA and ECDH NIST Test vector
In-Reply-To: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
References: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
Message-ID: <QSzgA2lq9dpzCfedPmQL6a0XQqEwcdOPP9gto0uNCtY=.c4182991-dc81-4dd7-a536-beb0fce01d9a@github.com>

On Fri, 14 Jun 2024 06:23:32 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Tests added against ECDSA and ECDH NIST Test vector.

test/jdk/sun/security/ec/ECDSAPrimitive.java line 255:

> 253:         MutablePoint R = ecOps.multiply(publicKeyPoint, u2Bytes);
> 254:         AffinePoint a1 = ops.basePointMultiply(u1Bytes);
> 255:         MutablePoint p2 = new ProjectivePoint.Mutable(

Compile time issue fixed here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19715#discussion_r1639355844


From djelinski at openjdk.org  Fri Jun 14 07:49:12 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 14 Jun 2024 07:49:12 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <4Ud5vy-9GMiyUMhornL9OeyrjRP58BOiAcDB_48H1dQ=.cf71298d-a509-4854-a717-6a83e183b15c@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 202:

> 200:         Integer nstServerCount = GetIntegerAction.privilegedGetProperty(
> 201:             "jdk.tls.server.newSessionTicketCount");
> 202:         if (nstServerCount == null || nstServerCount < 1 ||

Please permit zero here. It is useful for preventing the connection reset on connections where the client is only writing and never reading from the socket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639413864


From djelinski at openjdk.org  Fri Jun 14 09:49:14 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 14 Jun 2024 09:49:14 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

Changes requested by djelinski (Reviewer).

src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 388:

> 386:             /*
> 387:              * This thread addresses a Windows only networking issue found with
> 388:              * SSLSocketBruteForceClose. A client that quickly closes after

Thanks for bringing it up. Using a thread to delay sending the messages only hides the problem; if the client closes the connection without reading the NST messages, the connection will be reset. Should we work on a proper fix instead?

src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 397:

> 395:              * and server are on different machines.
> 396:              */
> 397:             Thread nstThread = Thread.ofVirtual().name("NST").start(() -> {

Please don't use threads during handshake.

src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 415:

> 413:                 } catch (IOException e) {
> 414:                     // Low exception likelihood this is data requires not
> 415:                     // reply an IO errors will be handled by other messages.

Could you rephrase this?

src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 510:

> 508:     }
> 509: 
> 510:         /**

unintended

src/java.base/share/classes/sun/security/util/Cache.java line 300:

> 298:         }
> 299: 
> 300:         cacheMap = new ConcurrentHashMap<>();

With LinkedHashMap we were removing least recently used entries on overflow (see the implementation of `put`); with ConcurrentHashMap we will remove entries in random order. Is that intentional? If it is, you might want to review the class's JavaDoc.

src/java.base/share/classes/sun/security/util/Cache.java line 395:

> 393:                 entry.invalidate();
> 394:             }
> 395:             while (queue.poll() != null);

Can we keep the original code? IntelliJ complains about both versions, but the comment makes it more clear that the empty loop is intentional.

src/java.base/share/classes/sun/security/util/Cache.java line 701:

> 699:         }
> 700: 
> 701:         public V getValue() {

This method should call SoftReference.get() somewhere to let the GC know that this cache entry is still used

src/java.base/share/classes/sun/security/util/Cache.java line 741:

> 739:             // is a one for one entry swap, locking isn't necessary and plus or
> 740:             // minus a few entries is not critical.
> 741:             if (queue.size() > MAXQUEUESIZE) {

Suggestion:

            if (queue.size() >= MAXQUEUESIZE) {

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

PR Review: https://git.openjdk.org/jdk/pull/19465#pullrequestreview-2117840823
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639488568
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639523446
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639489471
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639522755
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639529424
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639539288
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639541832
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639543646


From duke at openjdk.org  Fri Jun 14 09:50:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 14 Jun 2024 09:50:14 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>
Message-ID: <wcJ6GKdi7u7cnPWXmmVM0csgsMqCAVKnvv3rh_JbbHQ=.a09faac2-4840-48b0-b7ad-d8bcffbacc4a@github.com>

On Thu, 13 Jun 2024 20:25:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix clone(), accept review suggestions.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 73:
> 
>> 71:     // The following array is allocated to size WIDTH bytes, but we only
>> 72:     // ever use the first blockSize bytes it (for bytes <-> long conversions)
>> 73:     private byte[] byteState = new byte[WIDTH];
> 
> Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?

This is interesting: if I use WIDTH (or in blockSize) long arrays in the local level, the performance drops a few per cents. Even more when I only declare the local array in the block in which it is used. However, since we really only need 8 bytes, if I allocate that at the beginning of the function, I don't see that performance drop. So I rewrote the output loop in the function and got rid of the class level declaration.

> src/java.base/share/classes/sun/security/provider/SHA3.java line 121:
> 
>> 119:         }
>> 120:         implCompress(buffer, 0);
>> 121:         int availableBytes = buffer.length;
> 
> change to `blockSize` as in `implCompress0(...)`?

Yes, thanks, I wanted to, just forgot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572500
PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572413


From duke at openjdk.org  Fri Jun 14 09:50:15 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 14 Jun 2024 09:50:15 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <aj_JZwbKHtrr6yjsmjNU1nAoJBGmAKgC5mJMR6BVfx4=.6b322db3-5c6c-461a-b586-2c7560433b27@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <aj_JZwbKHtrr6yjsmjNU1nAoJBGmAKgC5mJMR6BVfx4=.6b322db3-5c6c-461a-b586-2c7560433b27@github.com>
Message-ID: <MZB9Hp3-gnZnC-Q-Cq1guLAec_FRQwMj39VR8mZ8EL0=.b91ffc05-dd3d-49db-8919-af15375fcd1d@github.com>

On Fri, 14 Jun 2024 05:56:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix clone(), accept review suggestions.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 152:
> 
>> 150:      */
>> 151:     void implReset() {
>> 152:         Arrays.fill(state,0L);
> 
> Suggestion:
> 
>         Arrays.fill(state, 0L);

Thanks! Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572679


From duke at openjdk.org  Fri Jun 14 10:39:45 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 14 Jun 2024 10:39:45 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v3]
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

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

  Accept more review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19632/files
  - new: https://git.openjdk.org/jdk/pull/19632/files/0a9f9624..4fcdd09f

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

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

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


From ihse at openjdk.org  Fri Jun 14 10:55:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Jun 2024 10:55:22 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
 <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
 <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>
Message-ID: <XrI8ouN-1BPdfxStwisnI4NAY11mpHXcEtuvnuO3MXY=.5b0a33d6-ebcf-4213-9f1e-0f7b217688ca@github.com>

On Fri, 7 Jun 2024 13:34:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I find the extra trailing newlines through below shell command:
>> 
>> for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done
>> 
>> 
>> There are only two files has been found:
>> 
>> ./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
>> ./test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go

GitHub's UI assumes the final line has an line break. If it is missing, it displays a red ? at the end of the last line. If there is an empty line showing up in the UI, then it is an additional empty line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1639649265


From liach at openjdk.org  Fri Jun 14 12:56:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Jun 2024 12:56:23 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <XrI8ouN-1BPdfxStwisnI4NAY11mpHXcEtuvnuO3MXY=.5b0a33d6-ebcf-4213-9f1e-0f7b217688ca@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
 <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
 <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>
 <XrI8ouN-1BPdfxStwisnI4NAY11mpHXcEtuvnuO3MXY=.5b0a33d6-ebcf-4213-9f1e-0f7b217688ca@github.com>
Message-ID: <Qn8Aq3YacG6k1osKLwjfakXahNky2MoXOCkcjKq8wy8=.f72a9420-4d53-4505-9e10-22bd97773668@github.com>

On Fri, 14 Jun 2024 10:52:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go
>
> GitHub's UI assumes the final line has an line break. If it is missing, it displays a red ? at the end of the last line. If there is an empty line showing up in the UI, then it is an additional empty line.

In this case, GitHub is actually not showing up extra empty lines, that they appear the same as the single line break in the end of the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1639783594


From mpowers at openjdk.org  Fri Jun 14 13:11:06 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 14 Jun 2024 13:11:06 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v4]
In-Reply-To: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
Message-ID: <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>

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

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

  move variables to above try block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19535/files
  - new: https://git.openjdk.org/jdk/pull/19535/files/3bf59f72..78a8522c

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

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

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


From mullan at openjdk.org  Fri Jun 14 15:36:53 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Jun 2024 15:36:53 GMT
Subject: RFR: 8248981: Specify list of standard message digest and mgf
 algorithms for RSASSA-PSS signature
Message-ID: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>

Added links from the `PSSParameterSpec` API to new section in Standard Algorithm Names specification for PSSParameterSpec (changes for that are in closed repo). Also made a couple of links to the Standard Algorithm Names specification in `ECGenParameterSpec` and `NamedParameterSpec` more specific.

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

Commit messages:
 - Initial revision.

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

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


From ascarpino at openjdk.org  Fri Jun 14 16:21:19 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jun 2024 16:21:19 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
Message-ID: <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>

On Fri, 14 Jun 2024 08:42:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 388:
> 
>> 386:             /*
>> 387:              * This thread addresses a Windows only networking issue found with
>> 388:              * SSLSocketBruteForceClose. A client that quickly closes after
> 
> Thanks for bringing it up. Using a thread to delay sending the messages only hides the problem; if the client closes the connection without reading the NST messages, the connection will be reset. Should we work on a proper fix instead?

And your suggestion would be?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640049667


From mullan at openjdk.org  Fri Jun 14 16:36:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Jun 2024 16:36:25 GMT
Subject: [jdk23] RFR: 8333724: Problem list
 security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1
In-Reply-To: <L7t-nHdGVbXFlu1s_mFIhS1BvKaG9_IsxdcNzYyOr_A=.e21836a9-c265-4c40-8a15-ba9811c19922@github.com>
References: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
 <L7t-nHdGVbXFlu1s_mFIhS1BvKaG9_IsxdcNzYyOr_A=.e21836a9-c265-4c40-8a15-ba9811c19922@github.com>
Message-ID: <TIu4ebLwaTTjZIMBWpAVEyipzKYdY9AhNZQyWN_7a8g=.01842739-d8c9-4f81-bb5e-be6aa8812c4e@github.com>

On Thu, 13 Jun 2024 13:24:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of [JDK-8333724](https://bugs.openjdk.org/browse/JDK-8333724), commit [8ffc35d1](https://github.com/openjdk/jdk/commit/8ffc35d117846a7a2aa08afed662273d2f887770) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Matthias Baesken on 7 Jun 2024 and was reviewed by Lutz Schmidt and Sergey Bylokhov.
>> 
>> Since this is a test update, it can be pushed under RDP1 ruling.
>> 
>> Thanks!
>> Christoph
>
> trivial backport, so

@RealCLanger @MBaesken For ProblemList entries, the referenced JBS issue causing the problem should have a `problemlist` label. See https://openjdk.org/guide/#problemlisting-jtreg-tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/19697#issuecomment-2168376180


From ascarpino at openjdk.org  Fri Jun 14 16:47:17 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jun 2024 16:47:17 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
 <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>
Message-ID: <WZhX0BFqwWd_8aRS1_BGotSQen8-x_v9nKnfh0pziFg=.6a6c87fb-302c-4efe-b1cf-f0c19632072d@github.com>

On Fri, 14 Jun 2024 16:18:07 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 388:
>> 
>>> 386:             /*
>>> 387:              * This thread addresses a Windows only networking issue found with
>>> 388:              * SSLSocketBruteForceClose. A client that quickly closes after
>> 
>> Thanks for bringing it up. Using a thread to delay sending the messages only hides the problem; if the client closes the connection without reading the NST messages, the connection will be reset. Should we work on a proper fix instead?
>
> And your suggestion would be?

This is a low level networking error beyond my control.  All this code can do is accept that the operating system has sent it a fatal error that has blocked the servers ability to read data from the socket on data that was by the client already.   This data is no lost, which is not a good situation to be in.  Catching the exception doesn't resolved the lost data.  A similar situation has occurred before with [JDK-8235973](https://bugs.openjdk.org/browse/JDK-8235973).  Their solution does not fit here as this is during a normal read operation, but shows working around the issue was necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640105232


From ascarpino at openjdk.org  Fri Jun 14 17:12:12 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jun 2024 17:12:12 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
Message-ID: <kR2tl_Z2czCtlGhDb7LxjJ46_ABoYitwVWcA9Yl43eM=.d45f8adc-ffb6-4b57-9d29-b44d176b6cd2@github.com>

On Fri, 14 Jun 2024 09:09:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 397:
> 
>> 395:              * and server are on different machines.
>> 396:              */
>> 397:             Thread nstThread = Thread.ofVirtual().name("NST").start(() -> {
> 
> Please don't use threads during handshake.

There is no alternative that I have found for this synchronization/timing situation.  We certainly don't want a `sleep()` call and NSTs are not send/ack situation.  If the client ignores the NST, that is fine.  Hung thread paranoia is the only reason I put the `join()` in the code below as when this finish isn't critical.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640129880


From clanger at openjdk.org  Fri Jun 14 17:28:17 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 14 Jun 2024 17:28:17 GMT
Subject: [jdk23] RFR: 8333724: Problem list
 security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1
In-Reply-To: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
References: <Kzx-h75ep7zO29dcg-Kgatcj_bycs0LhLg5-us1zU9g=.5ba23609-5fd5-436a-a2bd-1f5043f2bfd5@github.com>
Message-ID: <E0uELWry2zRoVwsT5FkA6Bv0Kbg4JTJ7E9Qckm-05V0=.c94c60cf-3bb8-473e-8685-e32d4facdb11@github.com>

On Thu, 13 Jun 2024 13:07:23 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8333724](https://bugs.openjdk.org/browse/JDK-8333724), commit [8ffc35d1](https://github.com/openjdk/jdk/commit/8ffc35d117846a7a2aa08afed662273d2f887770) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Matthias Baesken on 7 Jun 2024 and was reviewed by Lutz Schmidt and Sergey Bylokhov.
> 
> Since this is a test update, it can be pushed under RDP1 ruling.
> 
> Thanks!
> Christoph

Ah, wasn't aware of that. Added. Thanks for the hint.

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

PR Comment: https://git.openjdk.org/jdk/pull/19697#issuecomment-2168463671


From ascarpino at openjdk.org  Fri Jun 14 17:37:12 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jun 2024 17:37:12 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <PSao292oeYC3Lit4E4EcZMAQXci-IVluJKDFKl-vA9o=.7267844c-8d7d-4084-af39-01689da33fb0@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <PSao292oeYC3Lit4E4EcZMAQXci-IVluJKDFKl-vA9o=.7267844c-8d7d-4084-af39-01689da33fb0@github.com>
Message-ID: <RQ3WKHJMNNcxT8rOtU9eq1y5LL53gbO_YaCz0R4nvHY=.ce6b5211-4474-47f6-a238-29bb494e73f1@github.com>

On Fri, 14 Jun 2024 01:14:55 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 127:
> 
>> 125:     static final int serverNewSessionTicketCount;
>> 126:     // Default for NST
>> 127:     static final int SERVER_NST_DEFAULT = 3;
> 
> I suggest you make the default 1 or 2 rather than 3.  NSTs can get pretty large and we may want to preserve bandwidth a bit, especially for servers at scale.  I think for many applications the default we're currently doing of 1 NST per connection might be enough, and the property allows folks to ratchet up the number of NSTs to fit their needs.  But defaulting to 2 is probably fine also.

A default of 1 makes sense as it's consistent with today's NST usage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640151732


From ascarpino at openjdk.org  Fri Jun 14 17:37:13 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jun 2024 17:37:13 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <4Ud5vy-9GMiyUMhornL9OeyrjRP58BOiAcDB_48H1dQ=.cf71298d-a509-4854-a717-6a83e183b15c@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <4Ud5vy-9GMiyUMhornL9OeyrjRP58BOiAcDB_48H1dQ=.cf71298d-a509-4854-a717-6a83e183b15c@github.com>
Message-ID: <IUovyNEmiMRTJ0A-scZkC8ZWNZMsNDfFzxuxPzLIkiE=.f9045229-934e-4975-88a8-3d82bff43080@github.com>

On Fri, 14 Jun 2024 07:46:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 202:
> 
>> 200:         Integer nstServerCount = GetIntegerAction.privilegedGetProperty(
>> 201:             "jdk.tls.server.newSessionTicketCount");
>> 202:         if (nstServerCount == null || nstServerCount < 1 ||
> 
> Please permit zero here. It is useful for preventing the connection reset on connections where the client is only writing and never reading from the socket.

I have been on the fence with zero.  I can support it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640152857


From valeriep at openjdk.org  Fri Jun 14 17:51:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 17:51:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <wcJ6GKdi7u7cnPWXmmVM0csgsMqCAVKnvv3rh_JbbHQ=.a09faac2-4840-48b0-b7ad-d8bcffbacc4a@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>
 <wcJ6GKdi7u7cnPWXmmVM0csgsMqCAVKnvv3rh_JbbHQ=.a09faac2-4840-48b0-b7ad-d8bcffbacc4a@github.com>
Message-ID: <Bsy4Uck2TL50fWnQ1lSkfyNzvajeQUTjv0X1bpb_xEc=.992868c9-9783-4c42-a684-b7bc6c74c489@github.com>

On Fri, 14 Jun 2024 09:47:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SHA3.java line 73:
>> 
>>> 71:     // The following array is allocated to size WIDTH bytes, but we only
>>> 72:     // ever use the first blockSize bytes it (for bytes <-> long conversions)
>>> 73:     private byte[] byteState = new byte[WIDTH];
>> 
>> Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?
>
> This is interesting: if I use WIDTH (or in blockSize) long arrays in the local level, the performance drops a few per cents. Even more when I only declare the local array in the block in which it is used. However, since we really only need 8 bytes, if I allocate that at the beginning of the function, I don't see that performance drop. So I rewrote the output loop in the function and got rid of the class level declaration.

Interesting...
Good that we go with the local 8-byte approach, it improves the readability also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1640166504


From valeriep at openjdk.org  Fri Jun 14 18:07:12 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 18:07:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v3]
In-Reply-To: <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
Message-ID: <r1l2EtsFvRtkfN4XOlZb_h7wOJkuVGJXYtkber3YlH4=.5666c201-14ca-4cbf-91b5-f5f4d8e35d18@github.com>

On Fri, 14 Jun 2024 10:39:45 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accept more review suggestions

src/java.base/share/classes/sun/security/provider/SHA3.java line 137:

> 135:             asLittleEndian.set(out, ofs, state[numLongs - 1]);
> 136:         } else {
> 137:             asLittleEndian.set(byteState, 0, state[numLongs - 1]);

So, is the performance better placing the `byteState` declaration up there at line 111 instead of here? It's only used in this block...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1640180265


From valeriep at openjdk.org  Fri Jun 14 18:15:16 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 18:15:16 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v3]
In-Reply-To: <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
Message-ID: <lqIk2-MeCSnlG3TjY7c7TBXn7YcEMRp_WvoNxzDItNw=.9b29f117-2c49-46be-bb20-c184dc3e2e8b@github.com>

On Fri, 14 Jun 2024 10:39:45 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accept more review suggestions

Looks good

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19632#pullrequestreview-2118989182


From djelinski at openjdk.org  Fri Jun 14 18:53:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 14 Jun 2024 18:53:10 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <WZhX0BFqwWd_8aRS1_BGotSQen8-x_v9nKnfh0pziFg=.6a6c87fb-302c-4efe-b1cf-f0c19632072d@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
 <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>
 <WZhX0BFqwWd_8aRS1_BGotSQen8-x_v9nKnfh0pziFg=.6a6c87fb-302c-4efe-b1cf-f0c19632072d@github.com>
Message-ID: <kBi3JLnFbWUIcaalskPGch3jm2W4fHKI7u7WN4NEIvM=.cd365f6c-d7df-4b3b-b09e-ad01105a44e9@github.com>

On Fri, 14 Jun 2024 16:44:42 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> And your suggestion would be?
>
> This is a low level networking error beyond my control.  All this code can do is accept that the operating system has sent it a fatal error that has blocked the servers ability to read data from the socket on data that was by the client already.   This data is no lost, which is not a good situation to be in.  Catching the exception doesn't resolved the lost data.  A similar situation has occurred before with [JDK-8235973](https://bugs.openjdk.org/browse/JDK-8235973).  Their solution does not fit here as this is during a normal read operation, but shows working around the issue was necessary.

On the contrary, you are in control of this error. The client OS resets the connection whenever the client closes the socket without reading all available data from the buffers. When the reset is delivered to the server, any data that was not received yet is lost.

The best approach depends on the type of traffic on the connection. If the client is expected to receive data, we can send the NewSessionTicket message as before. If we don't know if the client is expected to receive data, we should delay sending the NewSessionTicket messages until the server actually writes data over the connection.

Sending the NewSessionTicket messages in a thread only adds variability to the mix... without a thread, the messages were guaranteed to be sent before user data. Now the messages can be sent any time before, in the middle, or after user data.

OpenSSL added a function to configure the number of tickets sent automatically after the finished message, and a function to request sending a ticket with the next application data. We should probably do the same.

https://www.openssl.org/docs/manmaster/man3/SSL_new_session_ticket.html

Regarding the failing test, there are 2 options to fix it:
- configure the server to send zero tickets, or
- receive at least one byte of data on the client side before closing the socket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640223767


From valeriep at openjdk.org  Fri Jun 14 18:59:18 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 18:59:18 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic [v2]
In-Reply-To: <eK8Vzdmh4n9xbfD6GfkG3wezZjOTAQrciod37_pYkts=.fe26e333-be41-483a-bf9a-82f66be35f2c@github.com>
References: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
 <GZRRKZ5JHtjvxstX44u_YqWemaYo9k5_5yt-C5iNOa4=.f2eedf91-fb94-4518-928e-f9fa8797980e@github.com>
 <YGa6VInoBmj3CgwM_EQq2PEZ5Hu9tZfjPFF9vIzaWts=.31710da2-3ee1-491e-9b91-734ccd20724e@github.com>
 <eK8Vzdmh4n9xbfD6GfkG3wezZjOTAQrciod37_pYkts=.fe26e333-be41-483a-bf9a-82f66be35f2c@github.com>
Message-ID: <m0sHCN9vhHd13BgPqpZRWC_5lKpRXvW0Tr9gdWvVVO0=.1dd0c77f-45a5-40e4-9df5-a418f546e6df@github.com>

On Tue, 16 Apr 2024 22:30:57 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> What about testing?
>
> @mcpowers I am about to leave for vacation. Will wait for your review and resume on this PR after I return. Thanks!

> UP @valeriepeng possible to backport PKCS11 configuration attribute part on JDK 17 or 21 ?

I am not sure, let me check and get back to you.

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

PR Comment: https://git.openjdk.org/jdk/pull/18387#issuecomment-2168588548


From duke at openjdk.org  Fri Jun 14 20:31:44 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 14 Jun 2024 20:31:44 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after JDK-8329538
Message-ID: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>

This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.

The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (i.e. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.

I have a slightly better mult() intrinsic that does reduction at the end, but decided to use a more conservative fix and just keep the reduction in Java (i.e. original mult() refactored into multImpl() and reducePositive()) Will commit these optimizations I discovered while working on this in next release.

---

Performance before Montgomery PR:

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s

Performance in master without mult() intrinsic

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6539.589 ? 132.844  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6202.530 ? 124.496  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1967.038 ?  15.819  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1931.667 ?  22.901  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1354.143 ? 24.861  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1354.139 ? 21.904  ops/s


Performance in master with mult() intrinsic

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  10534.707 ?  20.690  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3   9729.246 ? 102.803  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3   3549.011 ?  77.343  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3   3458.107 ?  14.622  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  2563.566 ? 94.381  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  2569.143 ? 53.337  ops/s
Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s


THIS PR without mult intrinsic

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6225.541 ? 111.874  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  5913.876 ? 121.556  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1837.740 ?  42.881  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1815.064 ?  72.015  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1271.716 ? 17.119  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1265.405 ? 19.382  ops/s


THIS PR with mult intrinsic

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  9560.700 ? 232.557  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  8916.806 ? 164.756  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  3064.470 ?  72.166  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  2991.568 ?  75.720  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  2200.308 ? 13.744  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  2203.028 ?  1.948  ops/s
Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8514.924 ? 59.022  ops/s

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

Commit messages:
 - whitespace
 - better reduction refactoring
 - Undo incomplete p256 mult reduction optimization

Changes: https://git.openjdk.org/jdk/pull/19728/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333583
  Stats: 130 lines in 9 files changed: 53 ins; 37 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/19728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19728/head:pull/19728

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


From duke at openjdk.org  Fri Jun 14 20:38:16 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 14 Jun 2024 20:38:16 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538
In-Reply-To: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
Message-ID: <aMn-F1qNSaMDifFNjt-HVn8VkC3Zs8TndTvhZkRlrIQ=.5c0a6862-474c-43a2-9b51-af8e6b1af068@github.com>

On Fri, 14 Jun 2024 20:23:04 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
> 
> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (i.e. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
> 
> I have a slightly better mult() intrinsic that does reduction at the end, but decided to use a more conservative fix and just keep the reduction in Java (i.e. original mult() refactored into multImpl() and reducePositive()) Will commit these optimizations I discovered while working on this in next release.
> 
> ---
> 
> Performance before Montgomery PR:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
> 
> Performance in master without mult() intrinsic
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6539.589 ? 132.844  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6202.530 ? 124.496  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1967.0...

@ascarpino Would you mind reviewing this again please? Mostly java you reviewed before.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2168728473


From duke at openjdk.org  Fri Jun 14 22:01:44 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 14 Jun 2024 22:01:44 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v2]
In-Reply-To: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
Message-ID: <emzfo-176WQwaHuSw-pJZJt6YAIPDk_Gc23UuRQJUJ4=.f276441f-40c7-4659-99b5-a40fd5579600@github.com>

> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
> 
> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
> 
> ---
> XDH.generateSecret performance 
> before Montgomery PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
> 
> after Montgomery PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
> 
> with this PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
> 
> ---
> 
> P256 performance with/without mult intrinsic:
> 
> Performance before Montgomery PR:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
> 
> Performance in master without mult() intrinsic
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Err...

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

  Improve non-intrinsic p256 performance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19728/files
  - new: https://git.openjdk.org/jdk/pull/19728/files/0219018b..2ab7bcbd

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

  Stats: 43 lines in 2 files changed: 5 ins; 38 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19728/head:pull/19728

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


From ascarpino at openjdk.org  Fri Jun 14 22:51:11 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Jun 2024 22:51:11 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <kBi3JLnFbWUIcaalskPGch3jm2W4fHKI7u7WN4NEIvM=.cd365f6c-d7df-4b3b-b09e-ad01105a44e9@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
 <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>
 <WZhX0BFqwWd_8aRS1_BGotSQen8-x_v9nKnfh0pziFg=.6a6c87fb-302c-4efe-b1cf-f0c19632072d@github.com>
 <kBi3JLnFbWUIcaalskPGch3jm2W4fHKI7u7WN4NEIvM=.cd365f6c-d7df-4b3b-b09e-ad01105a44e9@github.com>
Message-ID: <JxseMVH6Ptk2STPKDpZxv7m19D8OmxlHhp7kxGenJPc=.2efdfb44-a1a0-4176-890c-c35b83d65760@github.com>

On Fri, 14 Jun 2024 18:51:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This is a low level networking error beyond my control.  All this code can do is accept that the operating system has sent it a fatal error that has blocked the servers ability to read data from the socket on data that was by the client already.   This data is no lost, which is not a good situation to be in.  Catching the exception doesn't resolved the lost data.  A similar situation has occurred before with [JDK-8235973](https://bugs.openjdk.org/browse/JDK-8235973).  Their solution does not fit here as this is during a normal read operation, but shows working around the issue was necessary.
>
> On the contrary, you are in control of this error. The client OS resets the connection whenever the client closes the socket without reading all available data from the buffers. When the reset is delivered to the server, any data that was not received yet is lost.
> 
> The best approach depends on the type of traffic on the connection. If the client is expected to receive data, we can send the NewSessionTicket message as before. If we don't know if the client is expected to receive data, we should delay sending the NewSessionTicket messages until the server actually writes data over the connection.
> 
> Sending the NewSessionTicket messages in a thread only adds variability to the mix... without a thread, the messages were guaranteed to be sent before user data. Now the messages can be sent any time before, in the middle, or after user data.
> 
> OpenSSL added a function to configure the number of tickets sent automatically after the finished message, and a function to request sending a ticket with the next application data. We should probably do the same.
> 
> https://www.openssl.org/docs/manmaster/man3/SSL_new_session_ticket.html
> 
> Regarding the failing test, there are 2 options to fix it:
> - configure the server to send zero tickets, or
> - receive at least one byte of data on the client side before closing the socket.

Maybe the comment could use some rewording, but I tried to not write whole bug report in a code comment.

When this was first prototyped as non-threaded, the SocketException occurred because multiple NSTs were sent after the Finished.  The client sent a few messages and closed the connection immediately.  The server, sending the NSTs, runs into the WIndows SocketException when it tries to read the data sent by the client.  Failing to receive the any data or the close_notify.  The variability of the thread allowed the OS to handle the reset correctly and allow the TLS server to receive the close_notify and the data that was sent.

Waiting for application data to cross the wire may not work for clients that connect and immediately start multiple sessions via resumption to transfer data.  It will not have any tickets to resume from.  Additionally delaying the NST may not mean this problem will go away if the client closes during the NST creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640419711


From sviswanathan at openjdk.org  Fri Jun 14 23:48:12 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 14 Jun 2024 23:48:12 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v2]
In-Reply-To: <emzfo-176WQwaHuSw-pJZJt6YAIPDk_Gc23UuRQJUJ4=.f276441f-40c7-4659-99b5-a40fd5579600@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <emzfo-176WQwaHuSw-pJZJt6YAIPDk_Gc23UuRQJUJ4=.f276441f-40c7-4659-99b5-a40fd5579600@github.com>
Message-ID: <cH9NnKr3WJlL5EXcpoQJ7xHMuyKvbTOyoONmtkQ0mAM=.50df3a64-79b3-4506-9861-b38d5f98adef@github.com>

On Fri, 14 Jun 2024 22:01:44 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve non-intrinsic p256 performance

src/hotspot/share/opto/runtime.cpp line 1417:

> 1415:   // result type needed
> 1416:   fields = TypeTuple::fields(1);
> 1417:   fields[TypeFunc::Parms + 0] = NULL;

A minor nit: here NULL could be nullptr instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19728#discussion_r1640466077


From syan at openjdk.org  Sun Jun 16 02:02:21 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 16 Jun 2024 02:02:21 GMT
Subject: RFR: 8332492: Mark CAInterop.java#globalsigne46 as intermittent
In-Reply-To: <jn3tWA0jkPwOc9hHQXvahZM2DG_6T9AQ5Qz8RoReAuQ=.a7e0482f-0017-4675-b561-918d7eba10ea@github.com>
References: <jn3tWA0jkPwOc9hHQXvahZM2DG_6T9AQ5Qz8RoReAuQ=.a7e0482f-0017-4675-b561-918d7eba10ea@github.com>
Message-ID: <ip3T-odVFb-RH0--T2KJFJ41EDuUg7RvpsaNS8RWORw=.e205d150-5ec3-40b0-aecd-5cdbf5ae4c98@github.com>

On Sat, 18 May 2024 12:34:39 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   Before `CAInterop.java#globalsigne46` imtermittent [failure](https://bugs.openjdk.org/browse/JDK-8332433) has been resolved, mark the test as intermittent.

Hi, can anyone take look this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19291#issuecomment-2171010763


From clanger at openjdk.org  Mon Jun 17 07:50:11 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 07:50:11 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <Mhj1U5srPyevII4i6OUNTiVXJsndYGdu03NurR8j1ms=.32286386-5a1d-4f18-9543-62517d9d720e@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

@rhalade could you please bless this exclusion now since it pops up in tests of all our codelines every day...

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2172539065


From clanger at openjdk.org  Mon Jun 17 07:53:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 07:53:15 GMT
Subject: RFR: 8334202: Exclude CAInterop.java#sslrooteccca,sslrootevrsaca
In-Reply-To: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
References: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
Message-ID: <JmB8eFZFhW3_gOS0ElCTPry3kFci-ec2mQopW8Yd2DE=.c75f95b3-8317-4386-af5e-a37ebff5349c@github.com>

On Thu, 13 Jun 2024 09:25:11 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Let's exclude these CAInterop tests until the problem is fixed.

@rhalade could you please bless this exclusion quickly since it pops up in tests of all our codelines every day...

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

PR Comment: https://git.openjdk.org/jdk/pull/19690#issuecomment-2172546561


From clanger at openjdk.org  Mon Jun 17 08:06:34 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 08:06:34 GMT
Subject: RFR: 8334365: Problemlist CAInterop.java#microsoftecc2017
Message-ID: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>

Exclude CAInterop.java#microsoftecc2017 because it generates lots of noice in CI.

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

Commit messages:
 - JDK-8334365

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

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


From clanger at openjdk.org  Mon Jun 17 08:13:13 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 08:13:13 GMT
Subject: RFR: 8334365: Problemlist CAInterop.java#microsoftecc2017
In-Reply-To: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>
References: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>
Message-ID: <b5BTBVNuvGan9XAQh1mKCHVNRRRCA3SX4oitI07wpSM=.88e80957-3ddd-4529-b8ab-a5c99d35fc4e@github.com>

On Mon, 17 Jun 2024 08:01:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Exclude CAInterop.java#microsoftecc2017 because it generates lots of noice in CI.

@rhalade Please also have a look at this one. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/19741#issuecomment-2172587640


From azeller at openjdk.org  Mon Jun 17 10:01:16 2024
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 17 Jun 2024 10:01:16 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
 <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
 <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
Message-ID: <7OmY2pQUhUGu3UzZFFFNkUtefINzS6ewB0BRNiiq1tg=.2dc7afd5-3a8f-453a-bae1-0635b4eb13cf@github.com>

On Fri, 14 Jun 2024 00:58:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> The infra tests are not part of any of our CI tiers, so generally there is more time to investigate and figure out what the issue is in tests like this before putting it on the Problem List. Often the certificate tests fail because of an issue on the CA side, which sometimes can be fixed quickly after contacting the CA.

@seanjmullan : I am a bit astonished that the CAInterop tests are not part of any of your CI tiers. We do run the JDK tier 4 JTreg tests (that contains everything expect tier 1 , 2 and 3) on a regular time schedule and these CAInterop tests cause a lot of noise in our testing environment. Do you think you could add the CAInterop test to your automated tests too - or on the other hand, perhaps they could be simply marked manually or intermittent to avoid automated execution?

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2172937379


From fguallini at openjdk.org  Mon Jun 17 14:14:35 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 17 Jun 2024 14:14:35 GMT
Subject: RFR: 8329335: HttpsURLConnectionTest fails due to network firewall
 rules
Message-ID: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>

Since HttpsURLConnectionTest attempts to reach external servers, it can fail if run on hosts without outbound traffic allowed. Therefore, it should not be executed in CI pipelines but rather manually on a host with no firewall rules preventing egress traffic.

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

Commit messages:
 - test should be run manually to avoid proxy problems

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

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


From duke at openjdk.org  Mon Jun 17 14:27:22 2024
From: duke at openjdk.org (Nibedita Jena)
Date: Mon, 17 Jun 2024 14:27:22 GMT
Subject: RFR: 8332524: Instead of printing TLSv1.3, it is showing TLS13
Message-ID: <5fjk8LQo8BfanBrNCfhVuxp4_gmUcBul6fDKaLRaBjI=.922ce1f9-f0f8-4bfd-9e6b-e4f77ce0e790@github.com>

While doing SSL/TLS connection, start the Client with protocol TLSv1.2 and Server with protocol TLSv1.3. During handshake process, the exception shows as "javax.net.ssl.SSLHandshakeException: The client supported protocol versions [TLSv1.2] are not accepted by server preferences [TLS13]", where printing as TLS13 and not formatted to TLSv1.3.

After the given change, the protocol version is correctly printing:
javax.net.ssl.SSLHandshakeException: (protocol_version) The client supported protocol versions [TLSv1.2] are not accepted by server preferences [TLSv1.3]

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

Commit messages:
 - 8332524: Instead of printing TLSv1.3, it is showing TLS13

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

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


From mchhipa at openjdk.org  Mon Jun 17 14:50:11 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Mon, 17 Jun 2024 14:50:11 GMT
Subject: RFR: 8329335: HttpsURLConnectionTest fails due to network firewall
 rules
In-Reply-To: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
References: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
Message-ID: <kcqBf8v4slJY6Ue0JSfkNYeUTZKGnWQzOz7gZSdTPGA=.20816b7c-0fbe-42a4-a434-27fd25ac9831@github.com>

On Mon, 17 Jun 2024 09:16:45 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Since HttpsURLConnectionTest attempts to reach external servers, it can fail if run on hosts without outbound traffic allowed. Therefore, it should not be executed in CI pipelines but rather manually on a host with no firewall rules preventing egress traffic.

Hi @fguallini , what if NAT Gateway of CI machines VCN is configured to allow one way initiation traffic to specific external server. Then this change is not required.

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

PR Comment: https://git.openjdk.org/jdk/pull/19745#issuecomment-2173618927


From djelinski at openjdk.org  Mon Jun 17 16:31:16 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Jun 2024 16:31:16 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <JxseMVH6Ptk2STPKDpZxv7m19D8OmxlHhp7kxGenJPc=.2efdfb44-a1a0-4176-890c-c35b83d65760@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
 <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>
 <WZhX0BFqwWd_8aRS1_BGotSQen8-x_v9nKnfh0pziFg=.6a6c87fb-302c-4efe-b1cf-f0c19632072d@github.com>
 <kBi3JLnFbWUIcaalskPGch3jm2W4fHKI7u7WN4NEIvM=.cd365f6c-d7df-4b3b-b09e-ad01105a44e9@github.com>
 <JxseMVH6Ptk2STPKDpZxv7m19D8OmxlHhp7kxGenJPc=.2efdfb44-a1a0-4176-890c-c35b83d65760@github.com>
Message-ID: <ovK9WSDxIA7mYjo5ziyifTAH4DApzPSy4JubNZOVFGo=.b4d719a7-f45d-4b16-a65b-c78cef314412@github.com>

On Fri, 14 Jun 2024 22:48:59 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> On the contrary, you are in control of this error. The client OS resets the connection whenever the client closes the socket without reading all available data from the buffers. When the reset is delivered to the server, any data that was not received yet is lost.
>> 
>> The best approach depends on the type of traffic on the connection. If the client is expected to receive data, we can send the NewSessionTicket message as before. If we don't know if the client is expected to receive data, we should delay sending the NewSessionTicket messages until the server actually writes data over the connection.
>> 
>> Sending the NewSessionTicket messages in a thread only adds variability to the mix... without a thread, the messages were guaranteed to be sent before user data. Now the messages can be sent any time before, in the middle, or after user data.
>> 
>> OpenSSL added a function to configure the number of tickets sent automatically after the finished message, and a function to request sending a ticket with the next application data. We should probably do the same.
>> 
>> https://www.openssl.org/docs/manmaster/man3/SSL_new_session_ticket.html
>> 
>> Regarding the failing test, there are 2 options to fix it:
>> - configure the server to send zero tickets, or
>> - receive at least one byte of data on the client side before closing the socket.
>
> Maybe the comment could use some rewording, but I tried to not write whole bug report in a code comment.
> 
> When this was first prototyped as non-threaded, the SocketException occurred because multiple NSTs were sent after the Finished.  The client sent a few messages and closed the connection immediately.  The server, sending the NSTs, runs into the WIndows SocketException when it tries to read the data sent by the client.  Failing to receive the any data or the close_notify.  The variability of the thread allowed the OS to handle the reset correctly and allow the TLS server to receive the close_notify and the data that was sent.
> 
> Waiting for application data to cross the wire may not work for clients that connect and immediately start multiple sessions via resumption to transfer data.  It will not have any tickets to resume from.  Additionally delaying the NST may not mean this problem will go away if the client closes during the NST creation.

I experimented with the code a little, and I didn't observe any failures after inlining the thread code. On the other hand, when I moved the `hc.handshakeOutput.flush();` line inside the loop that sends NewSessionTicket messages, I immediately got a test failure. I forgot that the SSLSocket actually tries to "deplete" the socket before closing it, pretty sure that's the reason why the test didn't fail.

Are you sure the thread is still necessary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643086406


From duke at openjdk.org  Mon Jun 17 16:38:55 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Jun 2024 16:38:55 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
Message-ID: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>

> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
> 
> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
> 
> ---
> XDH.generateSecret performance 
> before Montgomery PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
> 
> after Montgomery PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
> 
> with this PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
> 
> ---
> 
> P256 performance with/without mult intrinsic:
> 
> Performance before Montgomery PR:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
> 
> Performance in master without mult() intrinsic
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Err...

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

  comment from Sandhya

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19728/files
  - new: https://git.openjdk.org/jdk/pull/19728/files/2ab7bcbd..960b8333

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

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

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


From duke at openjdk.org  Mon Jun 17 16:38:55 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Jun 2024 16:38:55 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v2]
In-Reply-To: <cH9NnKr3WJlL5EXcpoQJ7xHMuyKvbTOyoONmtkQ0mAM=.50df3a64-79b3-4506-9861-b38d5f98adef@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <emzfo-176WQwaHuSw-pJZJt6YAIPDk_Gc23UuRQJUJ4=.f276441f-40c7-4659-99b5-a40fd5579600@github.com>
 <cH9NnKr3WJlL5EXcpoQJ7xHMuyKvbTOyoONmtkQ0mAM=.50df3a64-79b3-4506-9861-b38d5f98adef@github.com>
Message-ID: <eMTdhI3rw8_UMWpsA1XK4mmOpTBqbSXOquOthWB9xEk=.ee81f7fd-45f1-4088-9412-c0b35d4ae8b0@github.com>

On Fri, 14 Jun 2024 23:39:54 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve non-intrinsic p256 performance
>
> src/hotspot/share/opto/runtime.cpp line 1417:
> 
>> 1415:   // result type needed
>> 1416:   fields = TypeTuple::fields(1);
>> 1417:   fields[TypeFunc::Parms + 0] = NULL;
> 
> A minor nit: here NULL could be nullptr instead.

done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19728#discussion_r1643093891


From sviswanathan at openjdk.org  Mon Jun 17 17:50:12 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 17 Jun 2024 17:50:12 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <VZ82zRB7Dain8nBnjKljdP2FrqjRbF8BsGS1DfHFd14=.3b4df39f-4fe3-48c4-b113-4c1de03aa95b@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19728#pullrequestreview-2123511329


From ascarpino at openjdk.org  Mon Jun 17 18:09:11 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 17 Jun 2024 18:09:11 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <ovK9WSDxIA7mYjo5ziyifTAH4DApzPSy4JubNZOVFGo=.b4d719a7-f45d-4b16-a65b-c78cef314412@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
 <KoJTkzBebNU7WxrvwVdTioBZWBMGv1M0CYPXdhlHp9Q=.5ec5f5a4-5120-4939-93d9-4af25f9827e8@github.com>
 <WZhX0BFqwWd_8aRS1_BGotSQen8-x_v9nKnfh0pziFg=.6a6c87fb-302c-4efe-b1cf-f0c19632072d@github.com>
 <kBi3JLnFbWUIcaalskPGch3jm2W4fHKI7u7WN4NEIvM=.cd365f6c-d7df-4b3b-b09e-ad01105a44e9@github.com>
 <JxseMVH6Ptk2STPKDpZxv7m19D8OmxlHhp7kxGenJPc=.2efdfb44-a1a0-4176-890c-c35b83d65760@github.com>
 <ovK9WSDxIA7mYjo5ziyifTAH4DApzPSy4JubNZOVFGo=.b4d719a7-f45d-4b16-a65b-c78cef314412@github.com>
Message-ID: <fQU6v0omHOu8eqPHuvqsPzG7nP_v7znGQFBJ7KzgAYI=.e886fdfc-055e-40e5-ada3-fa7187d1d2b2@github.com>

On Mon, 17 Jun 2024 16:28:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Maybe the comment could use some rewording, but I tried to not write whole bug report in a code comment.
>> 
>> When this was first prototyped as non-threaded, the SocketException occurred because multiple NSTs were sent after the Finished.  The client sent a few messages and closed the connection immediately.  The server, sending the NSTs, runs into the WIndows SocketException when it tries to read the data sent by the client.  Failing to receive the any data or the close_notify.  The variability of the thread allowed the OS to handle the reset correctly and allow the TLS server to receive the close_notify and the data that was sent.
>> 
>> Waiting for application data to cross the wire may not work for clients that connect and immediately start multiple sessions via resumption to transfer data.  It will not have any tickets to resume from.  Additionally delaying the NST may not mean this problem will go away if the client closes during the NST creation.
>
> I experimented with the code a little, and I didn't observe any failures after inlining the thread code. On the other hand, when I moved the `hc.handshakeOutput.flush();` line inside the loop that sends NewSessionTicket messages, I immediately got a test failure. I forgot that the SSLSocket actually tries to "deplete" the socket before closing it, pretty sure that's the reason why the test didn't fail.
> 
> Are you sure the thread is still necessary?

The thread has been the best way to handle this so far, but I've tried other ways with mixed results.
As you may or may not have seen with your `hc.handshakeOutput.flush()` experiment, was all the NST writes can max out the packet buffer size, so it needs occasional flushing.
This is all about IO and not getting the Windows exception.  Writing a lot of handshake data at once is causing the problem.  Using the thread can allow the IO to breathe a bit, even with maybe a `sleep()` help spread out the load. 
I'm also examining a way to use the socket writing to distribute the NSTs with the flow of other data.  The spec doesn't require all of them be sent immediately, but making sent too slow risks no tickets for multi resume clients.
I feel the solution to this isn't going to be perfect and will take some compromises.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643207977


From kvn at openjdk.org  Mon Jun 17 18:15:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 17 Jun 2024 18:15:13 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

What causes regression in P256 "(~-8-14%)"?
>From what I see, you re-arranged code to not execute some code ("reducePositive()") when it is not needed. How this affects P256?

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174028348


From duke at openjdk.org  Mon Jun 17 18:55:16 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Jun 2024 18:55:16 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
Message-ID: <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>

On Mon, 17 Jun 2024 18:12:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> What causes regression in P256 "(~-8-14%)"? From what I see, you re-arranged code to not execute some code ("reducePositive()") when it is not needed. How this affects P256?

Actually, the other way around; reducePositive is now an unconditionally executed for both pure java and the intrinsic paths. Perhaps that's what is misleading, it was only the mult() intrinsic that was taking advantage of this 'skip reduction' before. (pure java did not benefit from removing reduction, so I kept it. Now 'keeping it' for both paths)

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174201539


From mullan at openjdk.org  Mon Jun 17 19:18:11 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 19:18:11 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <7OmY2pQUhUGu3UzZFFFNkUtefINzS6ewB0BRNiiq1tg=.2dc7afd5-3a8f-453a-bae1-0635b4eb13cf@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
 <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
 <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
 <7OmY2pQUhUGu3UzZFFFNkUtefINzS6ewB0BRNiiq1tg=.2dc7afd5-3a8f-453a-bae1-0635b4eb13cf@github.com>
Message-ID: <B5MMAsjwtHg4BLyitq6v3mxuU7lVkm4XB2irlsDFu2Y=.3f1fe843-c376-4f6b-bf31-64e481c719dc@github.com>

On Mon, 17 Jun 2024 09:58:24 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> > The infra tests are not part of any of our CI tiers, so generally there is more time to investigate and figure out what the issue is in tests like this before putting it on the Problem List. Often the certificate tests fail because of an issue on the CA side, which sometimes can be fixed quickly after contacting the CA.
> 
> @seanjmullan : I am a bit astonished that the CAInterop tests are not part of any of your CI tiers. We do run the JDK tier 4 JTreg tests (that contains everything expect tier 1 , 2 and 3) on a regular time schedule and these CAInterop tests cause a lot of noise in our testing environment. Do you think you could add the CAInterop test to your automated tests too - or on the other hand, perhaps they could be simply marked manually or intermittent to avoid automated execution?

Our internal infrastructure restricts external connections. We normally run these tests manually before integrating changes in the security libs area.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2174239425


From ascarpino at openjdk.org  Mon Jun 17 19:25:13 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 17 Jun 2024 19:25:13 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
 <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
Message-ID: <ZV4qveeI_ZlXBHpCmdOwi_RmW45T9Qy9-1aEk3boubA=.b5ba45bd-868a-450e-b445-9c9ef4b300de@github.com>

On Mon, 17 Jun 2024 18:51:33 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> What causes regression in P256 "(~-8-14%)"?
>> From what I see, you re-arranged code to not execute some code ("reducePositive()") when it is not needed. How this affects P256?
>
>> What causes regression in P256 "(~-8-14%)"? From what I see, you re-arranged code to not execute some code ("reducePositive()") when it is not needed. How this affects P256?
> 
> Actually, the other way around; reducePositive is now an unconditionally executed for both pure java and the intrinsic paths. Perhaps that's what is misleading, it was only the mult() intrinsic that was taking advantage of this 'skip reduction' before. (pure java did not benefit from removing reduction, so I kept it. Now 'keeping it' for both paths)

Hi @vpaprotsk, 
@ferakocz is going to take a look at the change.  When he says it's ok, I'll approve the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174249460


From kvn at openjdk.org  Mon Jun 17 19:25:14 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 17 Jun 2024 19:25:14 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
 <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
Message-ID: <iSRFbtAvdxbqZznmcxW7Ht9-wxi4nsdNhHE6KTkoW2U=.44592c32-e24d-4f65-b040-7c2c2f5f0275@github.com>

On Mon, 17 Jun 2024 18:51:33 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Actually, the other way around; reducePositive is now an unconditionally executed for both pure java and the intrinsic paths. 

Looking on `MontgomeryIntegerPolynomialP256.java` the code in `multImpl() + reducePositive()` is similar to original `mult()` except new additional code at the end of `multImpl()`. Now you intrinsify only `multImpl()`. Looks like `reducePositive()`is not included into intrinsic and will be normally JIT compiled (hopeful inlined when JIT compiling `mult()`. Then what do you mean in above statement?

Also you did not change assembler for intrinsic but you changed corresponding Java code (`multImpl()`).  How it works?

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174250094


From duke at openjdk.org  Mon Jun 17 20:30:16 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Jun 2024 20:30:16 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <iSRFbtAvdxbqZznmcxW7Ht9-wxi4nsdNhHE6KTkoW2U=.44592c32-e24d-4f65-b040-7c2c2f5f0275@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
 <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
 <iSRFbtAvdxbqZznmcxW7Ht9-wxi4nsdNhHE6KTkoW2U=.44592c32-e24d-4f65-b040-7c2c2f5f0275@github.com>
Message-ID: <NetvFUeDQlfnIDvp8ytEkCAa-3_94e1nMzFAuCJFAdA=.317d3a34-89e5-492d-8d22-3ec4fed97ed5@github.com>

On Mon, 17 Jun 2024 19:22:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looking on `MontgomeryIntegerPolynomialP256.java` the code in `multImpl() + reducePositive()` is similar to original `mult()` except new additional code at the end of `multImpl()`. 

Yep, I split the original java mult() into multImpl() and reducePositive().

> Now you intrinsify only `multImpl()`. Looks like `reducePositive()`is not included into intrinsic and will be normally JIT compiled (hopeful inlined when JIT compiling `mult()`. Then what do you mean in above statement?
> Also you did not change assembler for intrinsic but you changed corresponding Java code (`multImpl()`). How it works?

The intrinsic used to return 1 (i.e. numAdds = 1), which would let the next operation decide if it needed to do the reduction or skip it. Now reducePositive() reduction always happens after the intrinsic (when it could had been skipped before).

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174364189


From rhalade at openjdk.org  Mon Jun 17 20:32:18 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 17 Jun 2024 20:32:18 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <Mhj1U5srPyevII4i6OUNTiVXJsndYGdu03NurR8j1ms=.32286386-5a1d-4f18-9543-62517d9d720e@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
 <Mhj1U5srPyevII4i6OUNTiVXJsndYGdu03NurR8j1ms=.32286386-5a1d-4f18-9543-62517d9d720e@github.com>
Message-ID: <SV0AsETNF4DhEdgG2tTdXYcYfz9n_fv8QI1oaRi9dU8=.fb22c5a6-c2f0-4ac5-97f9-60c600fa85aa@github.com>

On Mon, 17 Jun 2024 07:47:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> @rhalade could you please bless this exclusion now since it pops up in tests of all our codelines every day...

Drawing parallel with other reviews for this test and the pending discussion, we should hold on this PR for now. I will reach out to you later.

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2174367264


From kvn at openjdk.org  Mon Jun 17 21:23:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 17 Jun 2024 21:23:17 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <R74meoaT1TUCpH97f5O6vKnmr-TPm91-7bpXS-hDbms=.dce0d86d-81ab-4b3f-afc0-f3308f47a9ef@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

Let me know that I got it right:
- The reduction operation was optional and P256 benefitted by not executing it.
- Previous `mult()` **Java** code always retuned 0 because it executes reduction so callers do not need to do it.
- `_intpoly_montgomeryMult_P256` intrinsic code executes only part of code from previous `mult()` and it returns 1 to indicate that reduction should be executed if needed.
- Now `mult()` is split into 2 methods (with `multImpl()` intrinisfied) and always executes reduction so it can return 0.

I like new implementation because intrinsic matches Java code. It would allow avoid confusion I had.

The only question left: do we need to do something about Java code which checks return value? It is always 0 now. And I don't see you changed such checks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174446053


From duke at openjdk.org  Mon Jun 17 21:55:10 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Jun 2024 21:55:10 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <R74meoaT1TUCpH97f5O6vKnmr-TPm91-7bpXS-hDbms=.dce0d86d-81ab-4b3f-afc0-f3308f47a9ef@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <R74meoaT1TUCpH97f5O6vKnmr-TPm91-7bpXS-hDbms=.dce0d86d-81ab-4b3f-afc0-f3308f47a9ef@github.com>
Message-ID: <evU-E53v53rWr3I7Zm3JYBwDpkFeq881aTGViWmr3kM=.a1eff7c2-fca7-4f7c-812d-902ac18cbddf@github.com>

On Mon, 17 Jun 2024 21:21:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Let me know that I got it right:
> 
> * The reduction operation was optional and P256 benefitted by not executing it.
> * Previous `mult()` **Java** code always retuned 0 because it executes reduction so callers do not need to do it.
> * `_intpoly_montgomeryMult_P256` intrinsic code executes only part of code from previous `mult()` and it returns 1 to indicate that reduction should be executed if needed.
> * Now `mult()` is split into 2 methods (with `multImpl()` intrinisfied) and always executes reduction so it can return 0.

Thats it exactly. Except I would correct the last two words `return 0`. It is now void so no return (and I imagine that is why XDH did not like it; having it hardcoded to 0, without having to do inlining, opens the doors for some more optimizations. Also, the code I had checked in as part of montgomery PR was returning 0 everywhere but the intrinsic.

> I like new implementation because intrinsic matches Java code. It would allow avoid confusion I had.

I disliked this too. I originally removed the Java reduction too, but it hurt the non-intrinsic performance, so put it back in. (Before I got distracted with this bug, I was actually working on next ECC iteration, and was trying to fix this mismatch. But I also hadn't realized how much this optimization actually helped.)

There is also a 'bigger' complaint.. this optimization tried to use virtual methods to specialize one particular curve. Fairly standard practice. And it brought the other 'unaffected' curve down. If I can't use virtual methods for further optimizations.. how am I supposed to optimize further? Hmm. Not the time to discuss an answer, this release is going out, not the time to get 'creative', but this will give me problems next time I try to add code here.
 
> The only question left: do we need to do something about Java code which checks return value? It is always 0 now. And I don't see you changed such checks.

(Correction: no return, void). numAdds is now again pretty much a 'private' concept to the IntegerPolynomial class, so figure it was fine before, it should be fine now?

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174493638


From kvn at openjdk.org  Mon Jun 17 23:13:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 17 Jun 2024 23:13:10 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <evU-E53v53rWr3I7Zm3JYBwDpkFeq881aTGViWmr3kM=.a1eff7c2-fca7-4f7c-812d-902ac18cbddf@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <R74meoaT1TUCpH97f5O6vKnmr-TPm91-7bpXS-hDbms=.dce0d86d-81ab-4b3f-afc0-f3308f47a9ef@github.com>
 <evU-E53v53rWr3I7Zm3JYBwDpkFeq881aTGViWmr3kM=.a1eff7c2-fca7-4f7c-812d-902ac18cbddf@github.com>
Message-ID: <7HBid31iWxucnqfOrXblIH0zftUAnIwKTT1YtFGwkFs=.11485991-1bae-43a9-be45-5bcd681a8f18@github.com>

On Mon, 17 Jun 2024 21:52:22 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> numAdds is now again pretty much a 'private' concept to the IntegerPolynomial class, so figure it was fine before, it should be fine now?

I did not mean it for this changes but as general improvement of code in other RFE. But it is up to core libs group to decide.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174593762


From kvn at openjdk.org  Mon Jun 17 23:32:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 17 Jun 2024 23:32:12 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <8ZwlWoI93ja8DTfsPYPOCjVY4rQd8CpAhpsWTkyqYkg=.b0447eed-81ed-41f8-a7b4-039ca4d29b47@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

Talking about future improvements. Is it possible to optimize reduction code by converting it to intrinsic too?  Or code generated by C2 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174616789


From duke at openjdk.org  Tue Jun 18 00:54:18 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 18 Jun 2024 00:54:18 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <8ZwlWoI93ja8DTfsPYPOCjVY4rQd8CpAhpsWTkyqYkg=.b0447eed-81ed-41f8-a7b4-039ca4d29b47@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <8ZwlWoI93ja8DTfsPYPOCjVY4rQd8CpAhpsWTkyqYkg=.b0447eed-81ed-41f8-a7b4-039ca4d29b47@github.com>
Message-ID: <_zQhvRV5931epNYRcVbD7CGAnhOZOu7fresZxhkzkJU=.bc041541-0650-47b7-a8e0-1ad89fc126f7@github.com>

On Mon, 17 Jun 2024 23:29:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Talking about future improvements. Is it possible to optimize reduction code by converting it to intrinsic too? Or code generated by C2 is good enough?

I had some experiments to try where I was using virtual methods to add optimizations, similar to the optimization here (i.e. the default method 'does nothing' and have just one override). 

Perhaps this issue could had been solved differently and there is something to do on the compiler side i.e. requires a specific order of optimizations.. specialize the IntegerPolynomial.setProduct() hot path for XDH field type, inline mult() from XDH field, realize that the return is always zero, which allows whatever optimizations that werent run for 4% performance. (I don't yet know enough about the C2 to be able to answer or 'fix' that)

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174701231


From kvn at openjdk.org  Tue Jun 18 01:32:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Jun 2024 01:32:12 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <VslghLXRsA7eFTqoIH4EWGTD5A2MCw0RuSitCowWzaY=.27409056-7485-4aae-b10a-09fd8b8bda4d@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

There are examples in C2 how to check method's class holder (intrinsic's predicate) before executing intrinsic code.
See, for example, code for `_counterMode_AESCrypt` in `library_call.cpp`. I am not sure is this what you are asking for.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2174736168


From aturbanov at openjdk.org  Tue Jun 18 06:56:10 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Jun 2024 06:56:10 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <xBYe1p6Dexuj5W0STE_1NRZY38r5xDvIwA6mu1DS-74=.55c3c3cc-1e98-4a0d-825c-c58cea8d8332@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 75:

> 73:  * @author David Brownell
> 74:  */
> 75: final public class SSLSessionImpl extends ExtendedSSLSession {

Use blessed modifiers order
Suggestion:

public final class SSLSessionImpl extends ExtendedSSLSession {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643921249


From duke at openjdk.org  Tue Jun 18 07:03:38 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 18 Jun 2024 07:03:38 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v4]
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <1sYLyt2IjOt4mKaUOTiAp11jfLloVwkAoGsNmSzbKVw=.30096712-0701-4349-a51d-cd833b56d813@github.com>

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

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

  Copyright year update.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19632/files
  - new: https://git.openjdk.org/jdk/pull/19632/files/4fcdd09f..2bcd3000

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

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

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


From jjiang at openjdk.org  Tue Jun 18 08:21:22 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 18 Jun 2024 08:21:22 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <eggIdpWZZ-QBCDpH30MNBpIEsELvpAdZgVKP6IrDusE=.b11d6195-7b36-4ac9-a6ca-cd5ca33022e6@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 369:

> 367:                 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
> 368:                     SSLLogger.fine("No session ticket produced: " +
> 369:                             "session timeout");

Here `session timeout` may be confused.
It looks indicate the session has timed out.

`T12NewSessionTicketProducer::produce` uses `Session timeout is too long. No ticket sent`.
Could this log also use these wordings?

src/java.base/share/classes/sun/security/util/Cache.java line 310:

> 308:      * method.
> 309:      */
> 310: 

Could this blank line be removed?

src/java.base/share/classes/sun/security/util/Cache.java line 340:

> 338:             }
> 339:         }
> 340: 

Could this blank line be removed?

src/java.base/share/classes/sun/security/util/Cache.java line 353:

> 351:      * Scan all entries and remove all expired ones.
> 352:      */
> 353: 

Could this blank line be removed?

test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTClient.java line 34:

> 32:  * @run main/othervm MultiNSTClient -Djdk.tls.client.protocols=TLSv1.3 -Djdk.tls.server.enableSessionTicketExtension=false -Djdk.tls.client.enableSessionTicketExtension=false
> 33:  * @run main/othervm MultiNSTClient -Djdk.tls.client.protocols=TLSv1.2 -Djdk.tls.server.enableSessionTicketExtension=true -Djdk.tls.client.enableSessionTicketExtension=true
> 34:  * @summary Verifies multiple session tickets are PSKs are used by JSSE

Typically the`@run` lines should be the last part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643986123
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643988261
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643988678
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643988984
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1644028812


From mdonovan at openjdk.org  Tue Jun 18 12:18:41 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 18 Jun 2024 12:18:41 GMT
Subject: RFR: 8324841: PKCS11 tests still skip execution
Message-ID: <liYAEAcwoAS7ATb2oGlETPrsAx6k3TR2RMQUjqm-yY8=.a62da2d5-57c4-4652-a078-d27419202291@github.com>

In this PR, I updated PKCS11Test to throw a RuntimeException if the NSS binaries are not found in a directory specified with the property jdk.test.lib.artifacts.nsslib-<platform>.  If the property is not specified, the tests will throw a SkippedException.

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

Commit messages:
 - 8324841: PKCS11 tests still skip execution

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

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


From mullan at openjdk.org  Tue Jun 18 13:21:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 18 Jun 2024 13:21:09 GMT
Subject: RFR: 8332524: Instead of printing "TLSv1.3,
 " it is showing "TLS13"
In-Reply-To: <5fjk8LQo8BfanBrNCfhVuxp4_gmUcBul6fDKaLRaBjI=.922ce1f9-f0f8-4bfd-9e6b-e4f77ce0e790@github.com>
References: <5fjk8LQo8BfanBrNCfhVuxp4_gmUcBul6fDKaLRaBjI=.922ce1f9-f0f8-4bfd-9e6b-e4f77ce0e790@github.com>
Message-ID: <KMKNgnKtlYItxbJyeuUHZNmzfd4ifWqaQwRNQeOBdX0=.b88bdb91-c1ac-4d0b-8190-e6bc4b8901ac@github.com>

On Mon, 17 Jun 2024 14:22:28 GMT, Nibedita Jena <duke at openjdk.org> wrote:

> While doing SSL/TLS connection, start the Client with protocol TLSv1.2 and Server with protocol TLSv1.3. During handshake process, the exception shows as "javax.net.ssl.SSLHandshakeException: The client supported protocol versions [TLSv1.2] are not accepted by server preferences [TLS13]", where printing as TLS13 and not formatted to TLSv1.3.
> 
> After the given change, the protocol version is correctly printing:
> javax.net.ssl.SSLHandshakeException: (protocol_version) The client supported protocol versions [TLSv1.2] are not accepted by server preferences [TLSv1.3]

The JBS issue should have a `noreg` label, probably `noreg-trivial` is ok. Looks good otherwise.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19749#pullrequestreview-2125501098


From duke at openjdk.org  Tue Jun 18 13:31:20 2024
From: duke at openjdk.org (Nibedita Jena)
Date: Tue, 18 Jun 2024 13:31:20 GMT
Subject: Integrated: 8332524: Instead of printing "TLSv1.3," it is showing
 "TLS13"
In-Reply-To: <5fjk8LQo8BfanBrNCfhVuxp4_gmUcBul6fDKaLRaBjI=.922ce1f9-f0f8-4bfd-9e6b-e4f77ce0e790@github.com>
References: <5fjk8LQo8BfanBrNCfhVuxp4_gmUcBul6fDKaLRaBjI=.922ce1f9-f0f8-4bfd-9e6b-e4f77ce0e790@github.com>
Message-ID: <JhAnbrxMntJz2jIYEY9LSx6LSGLVoAc68VfJDbXEoxk=.828c8f39-1d8d-4bc2-8a14-05b4b563d2bc@github.com>

On Mon, 17 Jun 2024 14:22:28 GMT, Nibedita Jena <duke at openjdk.org> wrote:

> While doing SSL/TLS connection, start the Client with protocol TLSv1.2 and Server with protocol TLSv1.3. During handshake process, the exception shows as "javax.net.ssl.SSLHandshakeException: The client supported protocol versions [TLSv1.2] are not accepted by server preferences [TLS13]", where printing as TLS13 and not formatted to TLSv1.3.
> 
> After the given change, the protocol version is correctly printing:
> javax.net.ssl.SSLHandshakeException: (protocol_version) The client supported protocol versions [TLSv1.2] are not accepted by server preferences [TLSv1.3]

This pull request has now been integrated.

Changeset: e681b4e9
Author:    nibjen <jena.nibedita at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e681b4e9b3ae24f45d8c6adab4105df39e6b8a92
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8332524: Instead of printing "TLSv1.3," it is showing "TLS13"

Reviewed-by: mullan

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

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


From kvn at openjdk.org  Tue Jun 18 15:13:15 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Jun 2024 15:13:15 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <HtWRplCCFfZoJjEFkipuZsgIoTzhF0G2OxTEs-wNfd4=.6fb8234b-81bd-4ac4-8010-c5f6a4644258@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

Approved for VM changes.

@TobiHartmann ran our testing and it passed.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19728#pullrequestreview-2125802405
PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2176347091


From duke at openjdk.org  Tue Jun 18 15:34:23 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 18 Jun 2024 15:34:23 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <HtWRplCCFfZoJjEFkipuZsgIoTzhF0G2OxTEs-wNfd4=.6fb8234b-81bd-4ac4-8010-c5f6a4644258@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <HtWRplCCFfZoJjEFkipuZsgIoTzhF0G2OxTEs-wNfd4=.6fb8234b-81bd-4ac4-8010-c5f6a4644258@github.com>
Message-ID: <01gvTW3KEfA0QBgffjs0F-EqZPdWn3MmZTnTR0vnbL0=.4018624a-c493-4aad-a8ce-c51d363edf8f@github.com>

On Tue, 18 Jun 2024 15:10:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment from Sandhya
>
> @TobiHartmann ran our testing and it passed.

Thanks @vnkozlov @TobiHartmann !

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2176392727


From ascarpino at openjdk.org  Tue Jun 18 23:42:09 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 18 Jun 2024 23:42:09 GMT
Subject: RFR: 8333754: Add a Test against ECDSA and ECDH NIST Test vector
In-Reply-To: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
References: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
Message-ID: <1Q5EJGRqhyQIqqP9eniuG9Okf_ODAegyXQiMyt0x2uc=.2ed9f215-8779-44b3-8e22-9bd7946bb825@github.com>

On Fri, 14 Jun 2024 06:23:32 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Tests added against ECDSA and ECDH NIST Test vector.

The changes look good to me.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19715#pullrequestreview-2126732468


From ascarpino at openjdk.org  Wed Jun 19 00:07:15 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Jun 2024 00:07:15 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <eggIdpWZZ-QBCDpH30MNBpIEsELvpAdZgVKP6IrDusE=.b11d6195-7b36-4ac9-a6ca-cd5ca33022e6@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <eggIdpWZZ-QBCDpH30MNBpIEsELvpAdZgVKP6IrDusE=.b11d6195-7b36-4ac9-a6ca-cd5ca33022e6@github.com>
Message-ID: <mwWz7BEKhTJo3e_bsbe3Jjat-nI5YXiHvq2rJkhB7V0=.a16899a3-580d-4513-9d07-ce8546fc1772@github.com>

On Tue, 18 Jun 2024 07:41:06 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 369:
> 
>> 367:                 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
>> 368:                     SSLLogger.fine("No session ticket produced: " +
>> 369:                             "session timeout");
> 
> Here `session timeout` may be confused.
> It looks indicate the session has timed out.
> 
> `T12NewSessionTicketProducer::produce` uses `Session timeout is too long. No ticket sent`.
> Could this log also use these wordings?

All the T13 log messages use the same format.  I agree it is different from the T12 log messages, but it helps distinguish the failures for different protocols.
Thought saying "session timed out" is probably better

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1645234984


From ascarpino at openjdk.org  Wed Jun 19 02:09:11 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Jun 2024 02:09:11 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <xBYe1p6Dexuj5W0STE_1NRZY38r5xDvIwA6mu1DS-74=.55c3c3cc-1e98-4a0d-825c-c58cea8d8332@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <xBYe1p6Dexuj5W0STE_1NRZY38r5xDvIwA6mu1DS-74=.55c3c3cc-1e98-4a0d-825c-c58cea8d8332@github.com>
Message-ID: <VozzZUK8IiRCrgcJdvkS162kQmYg3FZDtlqteyz3jaw=.36fbb864-c74b-4473-adb6-a69ff94c3e03@github.com>

On Tue, 18 Jun 2024 06:53:25 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 75:
> 
>> 73:  * @author David Brownell
>> 74:  */
>> 75: final public class SSLSessionImpl extends ExtendedSSLSession {
> 
> Use blessed modifiers order
> Suggestion:
> 
> public final class SSLSessionImpl extends ExtendedSSLSession {

Actually being public wasn't necessary anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1645296064


From jjiang at openjdk.org  Wed Jun 19 02:46:10 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 19 Jun 2024 02:46:10 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <mwWz7BEKhTJo3e_bsbe3Jjat-nI5YXiHvq2rJkhB7V0=.a16899a3-580d-4513-9d07-ce8546fc1772@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <eggIdpWZZ-QBCDpH30MNBpIEsELvpAdZgVKP6IrDusE=.b11d6195-7b36-4ac9-a6ca-cd5ca33022e6@github.com>
 <mwWz7BEKhTJo3e_bsbe3Jjat-nI5YXiHvq2rJkhB7V0=.a16899a3-580d-4513-9d07-ce8546fc1772@github.com>
Message-ID: <u_Hu5zaHB2TMpcxJFcOqKaEDi-e0ODcaJG9_Yi607pI=.6d5a4310-7448-4ce6-af76-532dae5c67fd@github.com>

On Wed, 19 Jun 2024 00:04:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 369:
>> 
>>> 367:                 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
>>> 368:                     SSLLogger.fine("No session ticket produced: " +
>>> 369:                             "session timeout");
>> 
>> Here `session timeout` may be confused.
>> It looks indicate the session has timed out.
>> 
>> `T12NewSessionTicketProducer::produce` uses `Session timeout is too long. No ticket sent`.
>> Could this log also use these wordings?
>
> All the T13 log messages use the same format.  I agree it is different from the T12 log messages, but it helps distinguish the failures for different protocols.
> Though saying "session timed out" is probably better

Here the session ticked is not produced due to the session timeout value is too big, but not the session has timed out.
If my understanding is correct, the log could be "No session ticket produced: session timeout is too long".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1645329523


From ascarpino at openjdk.org  Wed Jun 19 03:28:10 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Jun 2024 03:28:10 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <IoI06Mld5nacB_TKDfPtkqcm4-RdgAhyZnmB2VFEFU0=.8e86935a-0d4c-4189-8edd-2519a56e1d71@github.com>
Message-ID: <O7eYVW99_ZTxXP7W8Sxgqv8c-1zbZQnFut7865bWhRU=.8a09b19e-53c7-49c1-9d67-cde6ba154ece@github.com>

On Fri, 14 Jun 2024 09:14:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> src/java.base/share/classes/sun/security/util/Cache.java line 300:
> 
>> 298:         }
>> 299: 
>> 300:         cacheMap = new ConcurrentHashMap<>();
> 
> With LinkedHashMap we were removing least recently used entries on overflow (see the implementation of `put`); with ConcurrentHashMap we will remove entries in random order. Is that intentional? If it is, you might want to review the class's JavaDoc.

No.  That's unfortunate about the ordering.  I was more focused on helping threading.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1645350766


From fguallini at openjdk.org  Wed Jun 19 09:06:17 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 19 Jun 2024 09:06:17 GMT
Subject: Withdrawn: 8329335: HttpsURLConnectionTest fails due to network
 firewall rules
In-Reply-To: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
References: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
Message-ID: <tY6GHUCOsAM4-2IvXFnZ2QKoP6_3lite_OLMVKXXnJw=.20b7c52b-6966-4301-9e39-01222a776d83@github.com>

On Mon, 17 Jun 2024 09:16:45 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Since HttpsURLConnectionTest attempts to reach external servers, it can fail if run on hosts without outbound traffic allowed. Therefore, it should not be executed in CI pipelines but rather manually on a host with no firewall rules preventing egress traffic.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.org  Wed Jun 19 11:58:24 2024
From: duke at openjdk.org (duke)
Date: Wed, 19 Jun 2024 11:58:24 GMT
Subject: Withdrawn: 8315487: Security Providers Filter
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <5PNi_dgjCITWqq16SbW9qhJEBj0NJLI5DcpKQVS8-jw=.62d23893-1ba1-4474-a784-5c339b7e9d94@github.com>

On Fri, 1 Sep 2023 15:13:46 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

This pull request has been closed without being integrated.

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

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


From ascarpino at openjdk.org  Wed Jun 19 15:06:12 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Jun 2024 15:06:12 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <u_Hu5zaHB2TMpcxJFcOqKaEDi-e0ODcaJG9_Yi607pI=.6d5a4310-7448-4ce6-af76-532dae5c67fd@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <eggIdpWZZ-QBCDpH30MNBpIEsELvpAdZgVKP6IrDusE=.b11d6195-7b36-4ac9-a6ca-cd5ca33022e6@github.com>
 <mwWz7BEKhTJo3e_bsbe3Jjat-nI5YXiHvq2rJkhB7V0=.a16899a3-580d-4513-9d07-ce8546fc1772@github.com>
 <u_Hu5zaHB2TMpcxJFcOqKaEDi-e0ODcaJG9_Yi607pI=.6d5a4310-7448-4ce6-af76-532dae5c67fd@github.com>
Message-ID: <1tLXF9v7gSL6jLslyC5KPo_4m2d4X64P7UU4-t5yDh8=.0c9703f1-0ce0-4007-ae2e-9e05d7f99231@github.com>

On Wed, 19 Jun 2024 02:43:56 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> All the T13 log messages use the same format.  I agree it is different from the T12 log messages, but it helps distinguish the failures for different protocols.
>> Though saying "session timed out" is probably better
>
> Here the session ticket is not produced due to the session timeout value is too big, but not the session has timed out.
> If my understanding is correct, the log could be "No session ticket produced: session timeout is too long".

Ok, I see what you are saying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1646357573


From jjiang at openjdk.org  Wed Jun 19 15:18:13 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 19 Jun 2024 15:18:13 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <fU5bsFzAyK0Df2k1Zr6Uxs8iK_a3SRb8N5lVHoYeI4w=.81a69385-da8f-4221-ae7a-b3ff5f4e3552@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <eBrc1lr_voa0Ho189jHE2QtafSo-hU0QcriiQqZDJEI=.9670324c-c6ba-43fe-8528-4880d91956d7@github.com>
 <fU5bsFzAyK0Df2k1Zr6Uxs8iK_a3SRb8N5lVHoYeI4w=.81a69385-da8f-4221-ae7a-b3ff5f4e3552@github.com>
Message-ID: <O4u9yMu16heR1jSvXw08iREo86PqSXFElgseTbz3imQ=.26b0d89f-2cce-410e-9437-9d5f623c511e@github.com>

On Wed, 5 Jun 2024 17:33:02 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Cache.java line 683:
>> 
>>> 681: 
>>> 682:         // Limit the number of queue entries.
>>> 683:         private static final int MAXQUEUESIZE = 10;
>> 
>> What do you think about making this tunable through the constructor, perhaps with a default value of 10?
>
> I thought about this, but found no reason as this is an internal API.   `QueueCacheEntry<>` is only for TLS client NewSessionTicket situation and the API would have to set that at the time the whole cache is built.  Even with that, it would still be a hard coded number, just somewhere else.  Unless we have yet another system property.  I don?t see a need for individual tuning at this time and we can always up the hardcoded limit if more are needed. If it is necessary in the future we can revisit this.

I have a similar idea as that Jamil thought about.
However, I think the constant `MAXQUEUESIZE` can be moved to class `MemoryCache` as a field.
It may be better to ask the applications to determine the size limit when the cache is instantiated.
Then, all the `QueueCacheEntry`s in a single `MemoryCache` have the same size limit, but different caches can have different limits.

This JSSE feature designs that the server sends 10 or less session tickets, so it's fine that `MAXQUEUESIZE` or the queue size limit is 10, but other (future) features may want different limits.
Although class `sun.security.util.Cache` is an internal utility, it's not JSSE internal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1646372716


From jjiang at openjdk.org  Wed Jun 19 15:18:11 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 19 Jun 2024 15:18:11 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <moUbNOQuNkVExKj5yZNOJ99emWILpqQW52vS8hyYUAs=.cc2cfdc4-eeca-4faa-bca2-5f9cfac8e088@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

src/java.base/share/classes/sun/security/util/Cache.java line 417:

> 415:      * @param canQueue can the value be put into a QueueCacheEntry
> 416:      */
> 417:     public synchronized void put(K key, V value, boolean canQueue) {

In practice, can `QueueCacheEntry` and other `CacheEntry` instances be stored in a single cache?
If not, the argument `canQueue` in this method could be moved to class `MemoryCache` as a field.
Then, if `canQueue` is true, the `put` method always adds the value into the `QueueCacheEntry` associated with the `key`; otherwise, this method just uses other `CacheEntry` types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1646354546


From clanger at openjdk.org  Wed Jun 19 15:34:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 19 Jun 2024 15:34:15 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
 <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
 <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
Message-ID: <bgYeC_l2-HSsxQ3wXCC9HsUbAJlk-ZLOWKETuV4O2Sw=.de4a5874-b422-4636-8af7-672ec4c91f3f@github.com>

On Fri, 14 Jun 2024 00:58:30 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Thanks for the approved.
>
>> @sendaoYan As a best practice, it would be useful to first understand why the test is not working before putting it on the ProblemList. Depending on the severity of the problem that is not always possible, but it should be the first step in an evaluation in my opinion. Minimally, the referenced issue should have an Assignee so that it is assured someone will look into it. Once an issue is on the ProblemList, it unfortunately doesn't address the underlying issue, and may not get the same attention if some evaluation had been done beforehand. Another suggestion is to ask about it on the OpenJDK security-dev alias, where there are Security Group members who have more experience with these tests and can decide what the best course of action is.
>> 
>> The infra tests are not part of any of our CI tiers, so generally there is more time to investigate and figure out what the issue is in tests like this before putting it on the Problem List. Often the certificate tests fail because of an issue on the CA side, which sometimes can be fixed quickly after contacting the CA.
>> 
>> In summary, please hold off on adding this test to the ProblemList until we have some time to evaluate the test failure. Thank you.
> 
> Got it. Thank you for your detailed explanation.
> If this issue fails cause by CA side or some other reason, and the the failure can fixed quickly, I think we should close these related PRs.

@sendaoYan Looks like the root cause was fixed by the CA and this PR (and according bug) can be closed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2178986290


From clanger at openjdk.org  Wed Jun 19 15:39:09 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 19 Jun 2024 15:39:09 GMT
Subject: RFR: 8333938: Exclude CAInterop.java#digicerttlsrsarootg5
In-Reply-To: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
References: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
Message-ID: <l8BvVkUgBl9PXB-agJgVZLqt0wpnWRc0TGGvOOoLYgE=.b18e139a-dedf-4e96-9d1f-58312b487625@github.com>

On Thu, 13 Jun 2024 12:32:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlsrsarootg5` report failure as failed to validate, before the validate issue has been fixed, should we problem list the testcase.

Looks like this PR can be closed. The underlying issue has been resolved by the CA.

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

PR Comment: https://git.openjdk.org/jdk/pull/19694#issuecomment-2178998048


From clanger at openjdk.org  Wed Jun 19 15:46:11 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 19 Jun 2024 15:46:11 GMT
Subject: RFR: 8334202: Exclude CAInterop.java#sslrooteccca,sslrootevrsaca
In-Reply-To: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
References: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
Message-ID: <kZ5tFfAGuldrgpTLurMFbgbRx5k5paE8lKrr1_26yaU=.e85a97ce-3e76-4e2a-8a99-b83df3b199b3@github.com>

On Thu, 13 Jun 2024 09:25:11 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Let's exclude these CAInterop tests until the problem is fixed.

I'll integrate this if we don't hear back from the CA by the end of the week.

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

PR Comment: https://git.openjdk.org/jdk/pull/19690#issuecomment-2179010698


From fguallini at openjdk.org  Wed Jun 19 15:46:33 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 19 Jun 2024 15:46:33 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
Message-ID: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>

The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.

In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

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

Commit messages:
 - test TextCallbackHandler/Default.java is automated

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

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


From clanger at openjdk.org  Wed Jun 19 15:51:11 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 19 Jun 2024 15:51:11 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <VfKWHW6lQtlHSE_9EKWeQmSGiD4f95CGPhq5ewMgs80=.88bf4aa7-9299-46a6-b5b9-62d3a563cc4e@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

Any updates? If not, I would like to integrate this after end of this week...

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2179020383


From stuefe at openjdk.org  Wed Jun 19 16:00:14 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 19 Jun 2024 16:00:14 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <qKl9JABm2nkeUF3Inrm0qT9EIKB_eHELApZx-OxKlgg=.5ac9a93f-0016-4628-9c73-39c181a04ff4@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

What is the point of stalling this PR? The test causes test errors, so it should be problemlisted. And if https://bugs.openjdk.org/browse/JDK-8331883 is urgent, it should be worked on with high priority. But surely there is no need to burden CIs with a failing test?

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2179036959


From syan at openjdk.org  Wed Jun 19 16:01:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Jun 2024 16:01:19 GMT
Subject: RFR: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due to
 JDK-8334105 [v2]
In-Reply-To: <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
 <7fOMlCRHopy9HMCQ7Ajl_Tb6VTYTuHJCpJ8hHl1tPTg=.ef7bfca3-08cf-40f3-b3f8-5e1a0b436d69@github.com>
 <ag1pXPcLK8zqC7hBdclIlVMFD_BMe1y53Klz9Pmeef8=.603b6978-807d-4a46-8ec8-572c1b44e864@github.com>
 <zY1_X4VrwxMTSbggNh8HlHvyPGjPHy5dpVaswnLyYW0=.12f7bbaa-f9db-4418-8456-460b6e5f1e04@github.com>
Message-ID: <NmT3JjiCFo7QciVuRI0Xvf6Krop0PULFk1y-KBdGW1c=.e67b6d2d-3ac2-4b21-81c8-f730a9a531af@github.com>

On Fri, 14 Jun 2024 00:58:30 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Thanks for the approved.
>
>> @sendaoYan As a best practice, it would be useful to first understand why the test is not working before putting it on the ProblemList. Depending on the severity of the problem that is not always possible, but it should be the first step in an evaluation in my opinion. Minimally, the referenced issue should have an Assignee so that it is assured someone will look into it. Once an issue is on the ProblemList, it unfortunately doesn't address the underlying issue, and may not get the same attention if some evaluation had been done beforehand. Another suggestion is to ask about it on the OpenJDK security-dev alias, where there are Security Group members who have more experience with these tests and can decide what the best course of action is.
>> 
>> The infra tests are not part of any of our CI tiers, so generally there is more time to investigate and figure out what the issue is in tests like this before putting it on the Problem List. Often the certificate tests fail because of an issue on the CA side, which sometimes can be fixed quickly after contacting the CA.
>> 
>> In summary, please hold off on adding this test to the ProblemList until we have some time to evaluate the test failure. Thank you.
> 
> Got it. Thank you for your detailed explanation.
> If this issue fails cause by CA side or some other reason, and the the failure can fixed quickly, I think we should close these related PRs.

> @sendaoYan Looks like the root cause was fixed by the CA and this PR (and according bug) can be closed now.

Okey.

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

PR Comment: https://git.openjdk.org/jdk/pull/19685#issuecomment-2179037838


From syan at openjdk.org  Wed Jun 19 16:01:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Jun 2024 16:01:19 GMT
Subject: Withdrawn: 8334106: Problemlist CAInterop.java#quovadisrootca1g3 due
 to JDK-8334105
In-Reply-To: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
References: <P6T5uAk3RdLxtHxXvQUv7Tzp9jF2uyXWLeRLgelNujk=.2f864446-a7ea-4015-9011-5135126eb900@github.com>
Message-ID: <92px7ISI8m-zgK_mVpUCaixvkvCCiqY6kpxXst87zcI=.f116e2e0-622d-4f2d-8910-833168cdbd4b@github.com>

On Thu, 13 Jun 2024 01:20:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all, 
>   Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3` report failure as `failed to validate`, before the validate issue has been fixed, should we problem list the testcase.

This pull request has been closed without being integrated.

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

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


From syan at openjdk.org  Wed Jun 19 16:02:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Jun 2024 16:02:14 GMT
Subject: RFR: 8333938: Exclude CAInterop.java#digicerttlsrsarootg5
In-Reply-To: <l8BvVkUgBl9PXB-agJgVZLqt0wpnWRc0TGGvOOoLYgE=.b18e139a-dedf-4e96-9d1f-58312b487625@github.com>
References: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
 <l8BvVkUgBl9PXB-agJgVZLqt0wpnWRc0TGGvOOoLYgE=.b18e139a-dedf-4e96-9d1f-58312b487625@github.com>
Message-ID: <vDvCPTuwwQmz0PN6DRnhd04i0lEdobgnIwXgfPdpH8M=.e86e0b45-59c5-4fe3-a5a6-3c4b46673fec@github.com>

On Wed, 19 Jun 2024 15:36:44 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Looks like this PR can be closed. The underlying issue has been resolved by the CA.

Okey.

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

PR Comment: https://git.openjdk.org/jdk/pull/19694#issuecomment-2179040063


From syan at openjdk.org  Wed Jun 19 16:02:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Jun 2024 16:02:15 GMT
Subject: Withdrawn: 8333938: Exclude CAInterop.java#digicerttlsrsarootg5
In-Reply-To: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
References: <BkjatqqzwvAalQYGF-x-mWo3AdOhGgCBT16n0lkVU_s=.6577f0ae-e105-46e8-86e1-7d524df2bd10@github.com>
Message-ID: <bZL2Q_MojMmW2go_KEDthINSovcljNST4GYnrB0ft3s=.6b87ddf1-0f7d-4366-8445-8bd031c9f6d2@github.com>

On Thu, 13 Jun 2024 12:32:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlsrsarootg5` report failure as failed to validate, before the validate issue has been fixed, should we problem list the testcase.

This pull request has been closed without being integrated.

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

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


From ssahoo at openjdk.org  Thu Jun 20 04:21:19 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Thu, 20 Jun 2024 04:21:19 GMT
Subject: Integrated: 8333754: Add a Test against ECDSA and ECDH NIST Test
 vector
In-Reply-To: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
References: <VGe8_YPdebmRSVcQUfpYrpjRa1_JQc5Bxi-efx8ag7I=.2331441c-e133-4702-a578-2280ff942b57@github.com>
Message-ID: <bibqXF5aVVTpKgX7EiL-XsVZoByEeeyaUYivCBLPzIE=.bf7bae76-8921-45c2-88e9-51b2ff17d731@github.com>

On Fri, 14 Jun 2024 06:23:32 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Tests added against ECDSA and ECDH NIST Test vector.

This pull request has now been integrated.

Changeset: fad6644e
Author:    Sibabrata Sahoo <ssahoo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fad6644eabbad6b6d3472206d9db946408aca612
Stats:     9501 lines in 4 files changed: 9501 ins; 0 del; 0 mod

8333754: Add a Test against ECDSA and ECDH NIST Test vector

Reviewed-by: ascarpino

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

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


From jjiang at openjdk.org  Thu Jun 20 05:18:09 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 20 Jun 2024 05:18:09 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <82uPY8zwhqC7GrJfZxYkZ-PIcbtkUoo8NLS9caMT4yc=.2716a5fe-aec0-4fdc-afb6-558b67a4ed77@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

This enhancement allows the server side to send multiple tickets and the client side to store multiple ones.
However, how does the client side use the tickets in the cache?

This PR just takes the client side to find the first valid ticket from the cache queue to try to resume the session.
Since the tickets are generated by the server in bulk, so their lifetimes are almost the same.
Generally, the first valid ticket is the first ticket in the cache queue (otherwise, no valid ticket can be found).
What about the remaining tickets? They are unlikely to be used.

Furthermore, now that no public API supports the client-side applications to access the cached tickets,
so the clients cannot use all the tickets for resuming multiple sessions in the subsequent connections.
Then, could this PR not change the cache?
The client still stores the last ticket sent by the server in a connection.
That can simplify the solution and implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2179830838


From valeriep at openjdk.org  Thu Jun 20 07:57:17 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 20 Jun 2024 07:57:17 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v4]
In-Reply-To: <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>
Message-ID: <HCMNYfmG-Nktj4-IEQ-d6y04itMe09PVCY1PhvXAei8=.9d68023f-2073-4452-bda9-e7c09d162a54@github.com>

On Fri, 14 Jun 2024 13:11:06 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8333364
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move variables to above try block

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19535#pullrequestreview-2129691334


From fguallini at openjdk.org  Thu Jun 20 14:45:12 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 20 Jun 2024 14:45:12 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v4]
In-Reply-To: <3soIcVwBexljOfnkrTIQJkzjp69RqcVvlViK3z90EDU=.7282f312-d10d-4a8e-a3a7-262a40a6c6d3@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
 <3soIcVwBexljOfnkrTIQJkzjp69RqcVvlViK3z90EDU=.7282f312-d10d-4a8e-a3a7-262a40a6c6d3@github.com>
Message-ID: <rJZkpt0qannjCrksq0zpcy9HwdV3Gsoo5mxEKvHTYiE=.f7e6fb27-7837-48ba-ac62-a822f7d61973@github.com>

On Thu, 6 Jun 2024 15:45:54 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> As highlighted in the bug description, The test **security/Security/SynchronizedAccess.java** have some issues:
>> 
>> 1. it needs to implement the sigalg, otherwise it throws java.security.NoSuchAlgorithmException . Even though it does not fail as it catches the exception, it never reaches the removeProvider loop. Also, adding an extra assertion to verify the local providers were actually removed.
>> 2. It is reassigning the **provs** variable with Security.getProviders(). This will start adding/removing some of the system providers, in addition to the local providers, which it is not the test intent.
>> 3. Adding othervm flag to run in isolation.
>> 
>> Test runs in tier2
>
> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - added brackets, and refactor a comment and an exception message
>  - Regtest java/security/Security/SynchronizedAccess.java is  incorrect.

hi @bradfordwetmore  Could you please review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/19480#issuecomment-2180885528


From rhalade at openjdk.org  Thu Jun 20 15:12:14 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 20 Jun 2024 15:12:14 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <qKl9JABm2nkeUF3Inrm0qT9EIKB_eHELApZx-OxKlgg=.5ac9a93f-0016-4628-9c73-39c181a04ff4@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
 <qKl9JABm2nkeUF3Inrm0qT9EIKB_eHELApZx-OxKlgg=.5ac9a93f-0016-4628-9c73-39c181a04ff4@github.com>
Message-ID: <Oi4889imwoQ0kGKz2efeHp6muu9QwcHH183n_pF05gU=.83fb4d86-da77-4ba5-94b6-a30c8e54d2c8@github.com>

On Wed, 19 Jun 2024 15:57:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> What is the point of stalling this PR? The test causes test errors, so it should be problemlisted. And if https://bugs.openjdk.org/browse/JDK-8331883 is urgent, it should be worked on with high priority. But surely there is no need to burden CIs with a failing test?

These test failures are result of an external issue so the tests would be added and removed from ProblemList without any other change. Also, there is a risk that these tests start passing but not run because they remain on the ProblemList. The suggestion was to remove these runs from CI, refer JDK-8334441. I agree with that as we have seen few failures recently and will continue to see failures as and when CA needs an update or have an issue with infrastructure.

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2180943484


From kdriver at openjdk.org  Thu Jun 20 17:48:52 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 20 Jun 2024 17:48:52 GMT
Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API
 (Preview) [v80]
In-Reply-To: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
References: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
Message-ID: <-GH1yNPlMBbmrocnrwlFc2be5CrZKpKOwO7wTSu6N2o=.626bc10a-35a5-4e5b-8f0a-74ccc3a9ea0a@github.com>

> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478).

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:

 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - javadoc formatting
 - javadoc formatting
 - remove unused declared exception in impls
 - throw a ProviderException instead of "eating" an NSAE for Mac
 - fix edge-case in consolidateKeyMaterial
 - change thrown exception in engineDeriveKey in impl code
 - edge case handling in deriveXXX methods and a few javadoc fixes
 - ... and 90 more: https://git.openjdk.org/jdk/compare/265a0f55...4a34aa41

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

Changes: https://git.openjdk.org/jdk/pull/18924/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18924&range=79
  Stats: 2246 lines in 14 files changed: 2245 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18924/head:pull/18924

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


From duke at openjdk.org  Thu Jun 20 18:35:13 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 20 Jun 2024 18:35:13 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <_0jtDLz3WT2dPvhlE3oi8s3pRETfC38Uvng1wwu1y3w=.406d44cf-7821-4e2c-be26-3194016ab89d@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

@ferakocz just tagging you as reminder of (the many) items in your queue :) 
Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2181297371


From rhalade at openjdk.org  Thu Jun 20 18:39:34 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 20 Jun 2024 18:39:34 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
Message-ID: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>

Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

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

Commit messages:
 - Update comments
 - comment explaining why these are manual
 - update ProblemList
 - 8334441: Mark tests in jdk_security_infra group as manual

Changes: https://git.openjdk.org/jdk/pull/19814/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19814&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334441
  Stats: 160 lines in 10 files changed: 5 ins; 2 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/19814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19814/head:pull/19814

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


From mpowers at openjdk.org  Thu Jun 20 19:24:13 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 20 Jun 2024 19:24:13 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v4]
In-Reply-To: <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>
Message-ID: <veypAu1xKiu9yPtSRzJdqV5bFBtOB7HHXKcy8aXuW-I=.1a7a16fd-731c-486a-b5af-5296b2ded707@github.com>

On Fri, 14 Jun 2024 13:11:06 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8333364
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move variables to above try block

Thanks for the review Valerie!

I just ran tiers 1-3 as a sanity check. All tests passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19535#issuecomment-2181373192


From valeriep at openjdk.org  Thu Jun 20 20:36:09 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 20 Jun 2024 20:36:09 GMT
Subject: RFR: 8248981: Specify list of standard message digest and mgf
 algorithms for RSASSA-PSS signature
In-Reply-To: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>
References: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>
Message-ID: <LoG6odv8kHU1f9eMdXKOlq1bMhdG_UlaLtSy8qSDHkc=.32a7a707-2611-4d18-a9f0-f462ad62a1c7@github.com>

On Fri, 14 Jun 2024 15:32:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Added links from the `PSSParameterSpec` API to new section in Standard Algorithm Names specification for PSSParameterSpec (changes for that are in closed repo). Also made a couple of links to the Standard Algorithm Names specification in `ECGenParameterSpec` and `NamedParameterSpec` more specific.

I will take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/19724#issuecomment-2181510316


From valeriep at openjdk.org  Thu Jun 20 21:00:10 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 20 Jun 2024 21:00:10 GMT
Subject: RFR: 8248981: Specify list of standard message digest and mgf
 algorithms for RSASSA-PSS signature
In-Reply-To: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>
References: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>
Message-ID: <6Nftu48PyyNWvjv7J8BjmtOASes8a3dLTOkPgE75tL4=.b8d00b96-de8d-42a9-acc5-6267aaf75918@github.com>

On Fri, 14 Jun 2024 15:32:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Added links from the `PSSParameterSpec` API to new section in Standard Algorithm Names specification for PSSParameterSpec (changes for that are in closed repo). Also made a couple of links to the Standard Algorithm Names specification in `ECGenParameterSpec` and `NamedParameterSpec` more specific.

Looks good. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19724#pullrequestreview-2131344473


From ascarpino at openjdk.org  Fri Jun 21 02:07:09 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 21 Jun 2024 02:07:09 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <82uPY8zwhqC7GrJfZxYkZ-PIcbtkUoo8NLS9caMT4yc=.2716a5fe-aec0-4fdc-afb6-558b67a4ed77@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <82uPY8zwhqC7GrJfZxYkZ-PIcbtkUoo8NLS9caMT4yc=.2716a5fe-aec0-4fdc-afb6-558b67a4ed77@github.com>
Message-ID: <TIwJK5cM9-ViZg9Pwr3elaRkcjqO-xAJQJHzLK3zBQw=.675212b3-a100-4192-bafe-e50fcb70f625@github.com>

On Thu, 20 Jun 2024 05:15:10 GMT, John Jiang <jjiang at openjdk.org> wrote:

> This enhancement allows the server side to send multiple tickets and the client side to store multiple ones. However, how does the client side use the tickets in the cache?

Yes

> 
> This PR just takes the client side to find the first valid ticket from the cache queue to try to resume the session. Since the tickets are generated by the server in bulk, so their lifetimes are almost the same. Generally, the first valid ticket is the first ticket in the cache queue (otherwise, no valid ticket can be found). What about the remaining tickets? They are unlikely to be used.

The application calls `getSession()` from the same SSLContext of the original connection.  The same way resumption is performed today.  The remaining tickets sit on the client if they need them.  Some applications may choose to resume multiple times to download data/images.  This is a configurable option on the server because it's not applicable to all situations.  Given this is stored on the client, the memory usage is minimal.  If the client's lifetime is short, the tickets are deleted quickly.

> 
> Furthermore, now that no public API supports the client-side applications to access the cached tickets, so the clients cannot use all the tickets for resuming multiple sessions in the subsequent connections. Then, could this PR not change the cache? The client still stores the last ticket sent by the server in a connection. That can simplify the solution and implementation.

These cached entries are not for public API usage.  They are just for resumption of existing sessions.  This is no different than it is today where a TLS v1.3 stateless ticket or PSK cannot be accessed by the public API.  Creating a public API would be a big change given there is no public object to identify a cached entry and no way to start a new session from a cached entry.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2181846075


From ssahoo at openjdk.org  Fri Jun 21 05:01:18 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 21 Jun 2024 05:01:18 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
Message-ID: <W_-ya1T-zYQrFMhd7WcUamsOxY4OJoV4GeLdnAl1160=.eec3aa72-8464-4502-83f2-2356b2f0c25e@github.com>

On Wed, 5 Jun 2024 02:57:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for this simple change to fix a threading problem with the test. The server thread was not completing before the check occurred on the main thread.  The failure showed up in windows and macos, but not linux.  With this fix, running 100 times, windows & macos showed no failures.
> 
> Tony

Marked as reviewed by ssahoo (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19553#pullrequestreview-2131781820


From jjiang at openjdk.org  Fri Jun 21 08:18:14 2024
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 21 Jun 2024 08:18:14 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <OMMLRWD2rmBSlgD_83X4URbQ2mmW5q8dOzKGluObYQQ=.3c4e1bbd-2f9d-4ced-a89c-354ebbd2d69b@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

> The application calls?`getSession()`?from the same SSLContext of the original connection.
> ...
> The remaining tickets sit on the client if they need them. Some applications may choose to resume multiple times to download data/images.

I might miss something.
The client can connect to the server in parallel, and these new connections can share the SSLContext from a previous connection.
And the new connections automatically pick the cached sessions in that SSLContext one by one.
Right?

> These cached entries are not for public API usage. They are just for resumption of existing sessions. This is no different than it is today where a TLS v1.3 stateless ticket or PSK cannot be accessed by the public API. Creating a public API would be a big change given there is no public object to identify a cached entry and no way to start a new session from a cached entry. A public API is not in the scope of this change.

I did understand that and did not call for new public APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2182243938


From ssahoo at openjdk.org  Fri Jun 21 09:57:10 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 21 Jun 2024 09:57:10 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <XNGIwbdGu2zeo55U2ecOm1uTwnTpZyaQE9HdLNFDXIU=.2c89e27f-72ab-4db8-91c8-cdef5e62f0e4@github.com>

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

Just for knowledge: If the client has multiple PSK Identity previously shared by server and client initiate a PSK resumption of type(psk_dhe_ke) and it receive a HelloRetryRequest from Server, then should client send the same PSK Identity in current ClientHello same as in previous ClientHello(after changing ticket_age and binder value) or it has option to choose any one of remaining unused PSK Identity in 'pre_shared_key' extension?

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2182420527


From clanger at openjdk.org  Fri Jun 21 13:13:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 21 Jun 2024 13:13:12 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
In-Reply-To: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
Message-ID: <0duwUwX0rmRuucpAKb5i-kze6YtKOQhfSLIH6E_yfaQ=.dc24f3ad-448a-44c1-b425-a6e38c8f0365@github.com>

On Thu, 20 Jun 2024 18:35:00 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

Looks good, although I don't see why sometimes the directive is @run main/othervm/manual/manual (double occurence of manual).

test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 30:

> 28:  * @library /test/lib
> 29:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
> 30:  * @run main/othervm/manual/manual -Djava.security.debug=certpath,ocsp

What is the reason why manual is written twice? (Here and in all other places in this file...)

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19814#pullrequestreview-2132623582
PR Review Comment: https://git.openjdk.org/jdk/pull/19814#discussion_r1648943324


From clanger at openjdk.org  Fri Jun 21 13:16:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 21 Jun 2024 13:16:14 GMT
Subject: RFR: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <qKSzjoI6AZS1QON15KUyuaBpOqfLt6DaNPtK7_PhiJI=.7b99d450-3a98-4195-947e-113c0f1cd8f5@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

Withdrawing in favor of #19814 ([JDK-8334441](https://bugs.openjdk.org/browse/JDK-8334441)).

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

PR Comment: https://git.openjdk.org/jdk/pull/19689#issuecomment-2182731663


From clanger at openjdk.org  Fri Jun 21 13:16:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 21 Jun 2024 13:16:14 GMT
Subject: Withdrawn: 8334201: Exclude CAInterop.java#certignarootca
In-Reply-To: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
References: <cEBl_hncOU6n1nxrv6vvgsnYLWdWbcoY_6ZcFVDRYBY=.787559eb-9b77-49fb-898a-1ed43fd884e5@github.com>
Message-ID: <6lHOdWcUZKBPIJDBVGDFJYhfpAK9dBmD3rdyN-v_bnE=.4b70bdd1-45d9-4a50-b5c6-0e6f605c5d37@github.com>

On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test is failing currently and the JBS issue could not be resolved since about a month, so let's exclude the test for now.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.org  Fri Jun 21 14:19:17 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 21 Jun 2024 14:19:17 GMT
Subject: Integrated: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <yEVTNCIkUony-ap9tFiPkQxDH5rQf-Sh1bTl1O_OIiU=.6c3680be-f311-4052-96e0-96c9de492321@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

This pull request has now been integrated.

Changeset: 75bea280
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75bea280b9adb6dac9fefafbb3f4b212f100fbb5
Stats:     86 lines in 3 files changed: 24 ins; 35 del; 27 mod

8333867: SHA3 performance can be improved

Reviewed-by: kvn, valeriep

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

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


From ascarpino at openjdk.org  Fri Jun 21 15:38:10 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 21 Jun 2024 15:38:10 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <OMMLRWD2rmBSlgD_83X4URbQ2mmW5q8dOzKGluObYQQ=.3c4e1bbd-2f9d-4ced-a89c-354ebbd2d69b@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <OMMLRWD2rmBSlgD_83X4URbQ2mmW5q8dOzKGluObYQQ=.3c4e1bbd-2f9d-4ced-a89c-354ebbd2d69b@github.com>
Message-ID: <rpiz8UaT06abVOEeaIxxLLSq23o_dN5hgBrdn6vVSdQ=.5ce89b22-e434-4e98-9f6c-bbb098466cfb@github.com>

On Fri, 21 Jun 2024 08:15:42 GMT, John Jiang <jjiang at openjdk.org> wrote:

> > The application calls `getSession()` from the same SSLContext of the original connection.
> > ...
> > The remaining tickets sit on the client if they need them. Some applications may choose to resume multiple times to download data/images.
> 
> I might miss something. The client can connect to the server in parallel, and these new connections can share the SSLContext from a previous connection. And the new connections automatically pick the cached sessions in that SSLContext one by one. Right?

Let me start from the beginning and hopefully it will clear things up.

Today, each Finished connection gets one resumption ticket.  That session's SSLContext contains the cache.  When someone wants to resume, they use the same SSLContext to make a new session.  That new session will look into the cache, find the resumption ticket, and take it out to use.  Tickets are one-time use.  On completion of the resumed session, a new ticket is placed into cache under the same entry as the previous one. 

Clients that want to open parallel sessions are unable to use resumption effectively.  The current client cache can only hold one ticket, throwing away any other tickets the server may have sent it.  Additionally, the time between taking the resumption ticket and receiving a new ticket is too slow for parallel connecting clients.  The first resumption session takes that ticket, while the second resumption session sees no ticket and has to do a full handshake.    This change allows multiple tickets to be stored on the client cache, solving the parallel clients problem, without the application having to change.

If the application uses new SSLContext instances for each connection, it does not have access to the same cache.  This change does not modify that.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2182982688


From rhalade at openjdk.org  Fri Jun 21 16:11:34 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Jun 2024 16:11:34 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
Message-ID: <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>

> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

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

  fix typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19814/files
  - new: https://git.openjdk.org/jdk/pull/19814/files/5f1889af..2fdaa890

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

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

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


From rhalade at openjdk.org  Fri Jun 21 16:11:35 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Jun 2024 16:11:35 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <0duwUwX0rmRuucpAKb5i-kze6YtKOQhfSLIH6E_yfaQ=.dc24f3ad-448a-44c1-b425-a6e38c8f0365@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <0duwUwX0rmRuucpAKb5i-kze6YtKOQhfSLIH6E_yfaQ=.dc24f3ad-448a-44c1-b425-a6e38c8f0365@github.com>
Message-ID: <J_MbQDsAkVL4faYoch_tU7wbDsxopO_avgTAYNU_h7w=.1af8ef01-591b-43df-bb0a-c9ed23584e39@github.com>

On Fri, 21 Jun 2024 13:10:00 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typos
>
> test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 30:
> 
>> 28:  * @library /test/lib
>> 29:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
>> 30:  * @run main/othervm/manual/manual -Djava.security.debug=certpath,ocsp
> 
> What is the reason why manual is written twice? (Here and in all other places in this file...)

good catch! I have fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19814#discussion_r1649163406


From ascarpino at openjdk.org  Fri Jun 21 16:12:14 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 21 Jun 2024 16:12:14 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <XNGIwbdGu2zeo55U2ecOm1uTwnTpZyaQE9HdLNFDXIU=.2c89e27f-72ab-4db8-91c8-cdef5e62f0e4@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <XNGIwbdGu2zeo55U2ecOm1uTwnTpZyaQE9HdLNFDXIU=.2c89e27f-72ab-4db8-91c8-cdef5e62f0e4@github.com>
Message-ID: <EF0QXLv1C6-EjzqbezbYl19uyq3RziscqFb2HgleHMA=.3b50baaf-fb28-4929-a492-e5aca6650263@github.com>

On Fri, 21 Jun 2024 09:54:34 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Just for knowledge: If the client has multiple PSK Identity previously shared by server and client initiate a PSK resumption of type(psk_dhe_ke) and it receive a HelloRetryRequest from Server, then should client send the same PSK Identity in current ClientHello same as in previous ClientHello(after changing ticket_age and binder value) or it has option to choose any one of remaining unused PSK Identity or let send all unused PSK identities available in 'pre_shared_key' extension?

Looking at the code, it should be the same PSK.  I did not change anything in this area, so I would expect the same behavior as before.  In the existing code, given the first CH would take the PSK out of the cache, there would be no new PSK for the second CH to change to.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183040021


From mullan at openjdk.org  Fri Jun 21 16:36:11 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 21 Jun 2024 16:36:11 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
Message-ID: <H4K8GAjMQEiwgZeIWsFr-6-Jb_PO1qJlfKvZxSl8qcI=.4740263f-286c-4639-bbd0-a6703da2b70e@github.com>

On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typos

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19814#pullrequestreview-2133029865


From rhalade at openjdk.org  Fri Jun 21 16:40:16 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Jun 2024 16:40:16 GMT
Subject: Integrated: 8334441: Mark tests in jdk_security_infra group as manual
In-Reply-To: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
Message-ID: <99xuXYSt1gT7lmTPPvSB1lBZljI71AEaPlb37Wv0gtM=.b0958bd5-7d23-470e-bfad-19ccdee4ac3e@github.com>

On Thu, 20 Jun 2024 18:35:00 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

This pull request has now been integrated.

Changeset: 8e1d2b09
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a
Stats:     160 lines in 10 files changed: 5 ins; 2 del; 153 mod

8334441: Mark tests in jdk_security_infra group as manual

Reviewed-by: clanger, mullan

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

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


From ssahoo at openjdk.org  Fri Jun 21 17:20:14 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 21 Jun 2024 17:20:14 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <EF0QXLv1C6-EjzqbezbYl19uyq3RziscqFb2HgleHMA=.3b50baaf-fb28-4929-a492-e5aca6650263@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <XNGIwbdGu2zeo55U2ecOm1uTwnTpZyaQE9HdLNFDXIU=.2c89e27f-72ab-4db8-91c8-cdef5e62f0e4@github.com>
 <EF0QXLv1C6-EjzqbezbYl19uyq3RziscqFb2HgleHMA=.3b50baaf-fb28-4929-a492-e5aca6650263@github.com>
Message-ID: <JVHe96uctITUhlHe76LovdrsscNq8B3HyqoIMyOQrG0=.366c88ef-312b-4bcc-a1bf-6fe877121bf5@github.com>

On Fri, 21 Jun 2024 16:09:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> > Just for knowledge: If the client has multiple PSK Identity previously shared by server and client initiate a PSK resumption of type(psk_dhe_ke) and it receive a HelloRetryRequest from Server, then should client send the same PSK Identity in current ClientHello same as in previous ClientHello(after changing ticket_age and binder value) or it has option to choose any one of remaining unused PSK Identity or let send all unused PSK identities available in 'pre_shared_key' extension?
> 
> Looking at the code, it should be the same PSK. I did not change anything in this area, so I would expect the same behavior as before. In the existing code, given the first CH would take the PSK out of the cache, there would be no new PSK for the second CH to change to.

May be i am not clear fully. You mean after HRR, the next CH will go for a Full Handshake as the existing PSK identity removed from cache before next CH and after HRR reply? As per RFC. the CH after HRR can use the previous PSK Identity presented in initial resumption CH but after changing ticket_age and binder value.
Also would not it nice to send all applicable PSK identity available in client side in initial resumption CH and take real advantage of having multiple PSK identity and let server choose one out of it.
Sorry the question may not be practical as i am asking something theoretical point of view and i am not friendly with TLS code yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183140491


From ascarpino at openjdk.org  Fri Jun 21 20:04:11 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 21 Jun 2024 20:04:11 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <JVHe96uctITUhlHe76LovdrsscNq8B3HyqoIMyOQrG0=.366c88ef-312b-4bcc-a1bf-6fe877121bf5@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <XNGIwbdGu2zeo55U2ecOm1uTwnTpZyaQE9HdLNFDXIU=.2c89e27f-72ab-4db8-91c8-cdef5e62f0e4@github.com>
 <EF0QXLv1C6-EjzqbezbYl19uyq3RziscqFb2HgleHMA=.3b50baaf-fb28-4929-a492-e5aca6650263@github.com>
 <JVHe96uctITUhlHe76LovdrsscNq8B3HyqoIMyOQrG0=.366c88ef-312b-4bcc-a1bf-6fe877121bf5@github.com>
Message-ID: <Nv6VoGooMoxvkgdTsQj7sQtbRMhUbIl2C58t-px5rsA=.2eea2a7e-8b62-4527-862b-67af0201b7d3@github.com>

On Fri, 21 Jun 2024 17:17:57 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> > > Just for knowledge: If the client has multiple PSK Identity previously shared by server and client initiate a PSK resumption of type(psk_dhe_ke) and it receive a HelloRetryRequest from Server, then should client send the same PSK Identity in current ClientHello same as in previous ClientHello(after changing ticket_age and binder value) or it has option to choose any one of remaining unused PSK Identity or let send all unused PSK identities available in 'pre_shared_key' extension?
> > 
> > 
> > Looking at the code, it should be the same PSK. I did not change anything in this area, so I would expect the same behavior as before. In the existing code, given the first CH would take the PSK out of the cache, there would be no new PSK for the second CH to change to.
> 
> May be i am not clear fully. You mean after HRR, the next CH will go for a Full Handshake as the existing PSK identity removed from cache before next CH and after HRR reply? As per RFC. the CH after HRR can use the previous PSK Identity presented in initial resumption CH but after changing ticket_age and binder value. Also would not it nice to send all applicable PSK identity available in client side in initial resumption CH and take real advantage of having multiple PSK identity and let server choose one out of it. Sorry the question may not be practical as i am asking something theoretical point of view and i am not friendly with TLS code yet.

The second CH will still contain the first CH's PSK and do the modifications according to the spec.  I was just pointing out that the PSK was removed from the cache, so using another PSK isn't an option today.

Theoretically it seems possible.  The spec does allow multiple identities be sent.  I hadn't considered sending multiple PSKs.  The spec implies this maybe more for situations with 0-RTT and Early Data.  I could see where a client with many identities it can resume and wants the server to pick one.  Without a public API managing ticket/identities handling, I don't see this as an option for us. Any PSK's used in the CH would need to be removed from the cache, running the risk of causing the problem with an empty cache.  I would guess this maybe used in multi-server situations rather than the simple situation where all the NSTs come from the same server.  Interesting thought.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183374993


From valeriep at openjdk.org  Fri Jun 21 20:53:08 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 21 Jun 2024 20:53:08 GMT
Subject: RFR: 8324841: PKCS11 tests still skip execution
In-Reply-To: <liYAEAcwoAS7ATb2oGlETPrsAx6k3TR2RMQUjqm-yY8=.a62da2d5-57c4-4652-a078-d27419202291@github.com>
References: <liYAEAcwoAS7ATb2oGlETPrsAx6k3TR2RMQUjqm-yY8=.a62da2d5-57c4-4652-a078-d27419202291@github.com>
Message-ID: <wsyDcq75SwWyGiI7AZjwm8n86w5VgDePFD5Q0n2tGbQ=.710f4186-e8b9-48a2-b76a-5525c58d8b0f@github.com>

On Tue, 18 Jun 2024 12:13:13 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated PKCS11Test to throw a RuntimeException if the NSS binaries are not found in a directory specified with the property jdk.test.lib.artifacts.nsslib-<platform>.  If the property is not specified, the tests will throw a SkippedException.

Looks fine. Thanks!

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19767#pullrequestreview-2133402241


From jjiang at openjdk.org  Fri Jun 21 23:28:13 2024
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 21 Jun 2024 23:28:13 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS
In-Reply-To: <rpiz8UaT06abVOEeaIxxLLSq23o_dN5hgBrdn6vVSdQ=.5ce89b22-e434-4e98-9f6c-bbb098466cfb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <OMMLRWD2rmBSlgD_83X4URbQ2mmW5q8dOzKGluObYQQ=.3c4e1bbd-2f9d-4ced-a89c-354ebbd2d69b@github.com>
 <rpiz8UaT06abVOEeaIxxLLSq23o_dN5hgBrdn6vVSdQ=.5ce89b22-e434-4e98-9f6c-bbb098466cfb@github.com>
Message-ID: <Tr6g5NdFOJ2Y9VcvZCMCV18Nheht90xiQ3A4ekYOPWU=.1ae67d22-f34b-4e3d-a5d0-482b537ebf6d@github.com>

On Fri, 21 Jun 2024 15:35:46 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Let me start from the beginning and hopefully it will clear things up.
> 
> Today, each Finished connection gets one resumption ticket. That session's SSLContext contains the cache. When someone wants to resume, they use the same SSLContext to make a new session. That new session will look into the cache, find the resumption ticket, and take it out to use. Tickets are one-time use. On completion of the resumed session, a new ticket is placed into cache under the same entry as the previous one.
> 
> Clients that want to open parallel sessions are unable to use resumption effectively. The current client cache can only hold one ticket, throwing away any other tickets the server may have sent it. Additionally, the time between taking the resumption ticket and receiving a new ticket is too slow for parallel connecting clients. The first resumption session takes that ticket, while the second resumption session sees no ticket and has to do a full handshake. This change allows multiple tickets to be stored on the client cache, solving the parallel clients problem, without the application having to change.
> 
> If the application uses new SSLContext instances for each connection, it does not have access to the same cache. This change does not modify that.

Thanks for this clarification.
I was not clear how can multiple connections apply all the cached tickets in parallel.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183575943


From syan at openjdk.org  Sat Jun 22 08:12:33 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Jun 2024 08:12:33 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as manual
Message-ID: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>

Hi all,

This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.

Thanks!

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

Commit messages:
 - Backport 8e1d2b091c9a311d98a0b886a803fb18d4405d8a

Changes: https://git.openjdk.org/jdk/pull/19841/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334441
  Stats: 160 lines in 10 files changed: 5 ins; 2 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/19841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19841/head:pull/19841

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


From clanger at openjdk.org  Sat Jun 22 16:49:09 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 22 Jun 2024 16:49:09 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <Dut_xRz089GHRCb5A2QVqgL1GwyS3UEfTY1QT4-bZUI=.f17ce666-59aa-4c1a-9155-fab35ae900f5@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

Thanks for doing the backport.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19841#pullrequestreview-2133855195


From wetmore at openjdk.org  Sat Jun 22 17:40:10 2024
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 22 Jun 2024 17:40:10 GMT
Subject: RFR: 8028127: Regtest
 java/security/Security/SynchronizedAccess.java is incorrect [v4]
In-Reply-To: <rJZkpt0qannjCrksq0zpcy9HwdV3Gsoo5mxEKvHTYiE=.f7e6fb27-7837-48ba-ac62-a822f7d61973@github.com>
References: <MOyKY5f0uQnaZ09Er_6f-7v-JGfX_ng3aQssVXMtx9M=.960de266-2d2f-41d6-81b9-cd69f8e7dda4@github.com>
 <3soIcVwBexljOfnkrTIQJkzjp69RqcVvlViK3z90EDU=.7282f312-d10d-4a8e-a3a7-262a40a6c6d3@github.com>
 <rJZkpt0qannjCrksq0zpcy9HwdV3Gsoo5mxEKvHTYiE=.f7e6fb27-7837-48ba-ac62-a822f7d61973@github.com>
Message-ID: <IGYu1cfm6l74Gde5MIentHdtwq2uePgyXyPvkn9t94c=.e3679a59-39eb-4065-900e-d6ba288328b2@github.com>

On Thu, 20 Jun 2024 14:42:21 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> hi @bradfordwetmore Could you please review this PR?

Hi, just back from vacation, and busy until Tuesday at earliest.  I'll put a note in calendar, but please ping me if I haven't responded by Thursday.

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

PR Comment: https://git.openjdk.org/jdk/pull/19480#issuecomment-2184124144


From syan at openjdk.org  Sun Jun 23 00:37:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Jun 2024 00:37:09 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <JclxbYiWzL5w7suXCWGo2AxMLQwvnmxav20sMYsKd34=.2b3a4217-b3d9-4b8f-9ca0-d186c92882ec@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19841#issuecomment-2184269585


From syan at openjdk.org  Sun Jun 23 16:46:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Jun 2024 16:46:15 GMT
Subject: [jdk23] Integrated: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <qN3U8jgina59iUU6qLDdo_TIhFUwCPUbn9CBXs9f1n8=.aa6c16e6-db5e-460a-95e4-bbc9220f7def@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 10d81a33
Author:    SendaoYan <syan at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10d81a337d45d4ab05ffdbc722ffc7dd832f5c82
Stats:     160 lines in 10 files changed: 5 ins; 2 del; 153 mod

8334441: Mark tests in jdk_security_infra group as manual

Reviewed-by: clanger
Backport-of: 8e1d2b091c9a311d98a0b886a803fb18d4405d8a

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

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


From syan at openjdk.org  Mon Jun 24 00:44:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 00:44:22 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <Maq17kbCJSqljaKUsdt98yw5_r4XCFxj81_L8oFBVSc=.6e481ddd-b1f5-4913-8bcc-7f3ad99e0934@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

Thanks for the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19841#issuecomment-2185391474


From clanger at openjdk.org  Mon Jun 24 06:30:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 24 Jun 2024 06:30:15 GMT
Subject: RFR: 8334202: Exclude CAInterop.java#sslrooteccca,sslrootevrsaca
In-Reply-To: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
References: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
Message-ID: <BnJzDoCUgD7FY7U7ky4ruYFvQViiD6Z5uRKN99iSVQ8=.00f7d620-7989-4472-9d42-5cadb34a7370@github.com>

On Thu, 13 Jun 2024 09:25:11 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Let's exclude these CAInterop tests until the problem is fixed.

Closing in favor of https://bugs.openjdk.org/browse/JDK-8334441

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

PR Comment: https://git.openjdk.org/jdk/pull/19690#issuecomment-2185711351


From clanger at openjdk.org  Mon Jun 24 06:30:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 24 Jun 2024 06:30:15 GMT
Subject: Withdrawn: 8334202: Exclude CAInterop.java#sslrooteccca,
 sslrootevrsaca
In-Reply-To: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
References: <L5GmMLEcRwcJG8TTmUwwij8yQQmxqVkyujl8OYXTeGk=.5640e177-9090-4b6d-8066-66d4f94d623a@github.com>
Message-ID: <Q-gAu7Mc3dc853jtWMewi8noLbtB81DaJ5pdRXt2lvc=.1fa869dc-e8da-4cc4-adca-ef2f84976bec@github.com>

On Thu, 13 Jun 2024 09:25:11 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Let's exclude these CAInterop tests until the problem is fixed.

This pull request has been closed without being integrated.

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

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


From clanger at openjdk.org  Mon Jun 24 06:34:20 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 24 Jun 2024 06:34:20 GMT
Subject: RFR: 8334365: Problemlist CAInterop.java#microsoftecc2017
In-Reply-To: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>
References: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>
Message-ID: <9dxNSUJeQCkvMUJUIi1Ur04tmXYbwpSznd9MxisQDoo=.46c646a7-2878-4387-bfc8-f25363da8760@github.com>

On Mon, 17 Jun 2024 08:01:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Exclude CAInterop.java#microsoftecc2017 because it generates lots of noice in CI.

Closing in favor of https://bugs.openjdk.org/browse/JDK-8334441

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

PR Comment: https://git.openjdk.org/jdk/pull/19741#issuecomment-2185715546


From clanger at openjdk.org  Mon Jun 24 06:34:21 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 24 Jun 2024 06:34:21 GMT
Subject: Withdrawn: 8334365: Problemlist CAInterop.java#microsoftecc2017
In-Reply-To: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>
References: <ADZWtoQLJXkVYz0YPBOpWJOpcWrH5FlHek4VZMAw8g4=.20cb620a-51ea-4597-b157-10c94f50c0d9@github.com>
Message-ID: <iV8Sl05W_jAcyqZ92oHCl1I6NKJ1bRdkVlcSbXmft_Q=.c01fe3c0-d909-4c49-b177-276c1f75b0f6@github.com>

On Mon, 17 Jun 2024 08:01:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Exclude CAInterop.java#microsoftecc2017 because it generates lots of noice in CI.

This pull request has been closed without being integrated.

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

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


From mdonovan at openjdk.org  Mon Jun 24 11:18:17 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 24 Jun 2024 11:18:17 GMT
Subject: Integrated: 8324841: PKCS11 tests still skip execution
In-Reply-To: <liYAEAcwoAS7ATb2oGlETPrsAx6k3TR2RMQUjqm-yY8=.a62da2d5-57c4-4652-a078-d27419202291@github.com>
References: <liYAEAcwoAS7ATb2oGlETPrsAx6k3TR2RMQUjqm-yY8=.a62da2d5-57c4-4652-a078-d27419202291@github.com>
Message-ID: <cyXTr1hVaqHuaY8sBR02jLN6UL430mLlqitw02DihAU=.144df59a-d191-4f18-90a4-6dd70fe50f36@github.com>

On Tue, 18 Jun 2024 12:13:13 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated PKCS11Test to throw a RuntimeException if the NSS binaries are not found in a directory specified with the property jdk.test.lib.artifacts.nsslib-<platform>.  If the property is not specified, the tests will throw a SkippedException.

This pull request has now been integrated.

Changeset: 9d4a4bd2
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d4a4bd2c2a4bd16bbc80b602b15b448c52220f6
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8324841: PKCS11 tests still skip execution

Reviewed-by: valeriep

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

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


From mdonovan at openjdk.org  Mon Jun 24 12:12:34 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 24 Jun 2024 12:12:34 GMT
Subject: RFR: 8333317: Test
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with: Invalid ECDH
 ServerKeyExchange signature
Message-ID: <VHxy3lRk-zv9SYRVN5FCgpOuOhxRo8fjFcwRiwsHHKE=.1cfdb10f-4356-469a-a20f-b1453ba87a56@github.com>

In this PR, I updated the version of NSS to 3.101 and removed the test from the ProblemList for all platforms but linux-ppc64le (that bug is still outstanding.)

I also updated the skipTest logic in TestDSAKeyLength.java. Prior to my change, it compared the version numbers as double values but that doesn't work when version 3.101 is later (i.e., greater) than 3.14.

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

Commit messages:
 - 8333317: Test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with: Invalid ECDH ServerKeyExchange signature

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

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


From mdonovan at openjdk.org  Mon Jun 24 12:36:31 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 24 Jun 2024 12:36:31 GMT
Subject: [jdk23] RFR: 8324841: PKCS11 tests still skip execution
Message-ID: <Nxvtx_uTLRl0MzJM_cIS6TIrKpjRtITLm1Gs8DhAI1Y=.ee5eb34e-3ee1-455b-8beb-1d201680de41@github.com>

8324841: PKCS11 tests still skip execution

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

Commit messages:
 - Backport 9d4a4bd2c2a4bd16bbc80b602b15b448c52220f6

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

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


From duke at openjdk.org  Mon Jun 24 14:51:20 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 24 Jun 2024 14:51:20 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <_0jtDLz3WT2dPvhlE3oi8s3pRETfC38Uvng1wwu1y3w=.406d44cf-7821-4e2c-be26-3194016ab89d@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <_0jtDLz3WT2dPvhlE3oi8s3pRETfC38Uvng1wwu1y3w=.406d44cf-7821-4e2c-be26-3194016ab89d@github.com>
Message-ID: <jlyphiOtiZZWapXwcBfAHhri9ffQuTD9XjGz9NA348E=.3818010f-240b-4569-812c-185306b8dcff@github.com>

On Thu, 20 Jun 2024 18:32:14 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> @ferakocz just tagging you as reminder of (the many) items in your queue :) Thanks!

Sorry, I was out of office last week. I will take a deeper look at the changes tomorrow, but I have a question based on my first look at it: Do you attribute the performance loss of the XDH code path to the mult() function returning an int instead of being void? Do you think that this prevented some optimization in the hotspot compiler?

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2186762776


From mullan at openjdk.org  Mon Jun 24 14:53:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 24 Jun 2024 14:53:14 GMT
Subject: RFR: 8333772: Incorrect Kerberos behavior when
 udp_preference_limit = 0
In-Reply-To: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
References: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
Message-ID: <4eD1Gjn4Srs52Dz4HXVe5Wwt02DwIViLrXidmrosjoE=.a9ed910b-95ef-47cf-aab3-9c50f4759e57@github.com>

On Mon, 10 Jun 2024 20:29:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Allow `udp_preference_limit = 0` to force TCP.
> 
> The reason for this bug is that it was read in a similar way as `kdc_timeout` and `max_retries`, both must be positive to have effect.

Looks good. BTW, does MIT Kerberos also ignore negative values?

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19638#pullrequestreview-2136042998


From duke at openjdk.org  Mon Jun 24 15:31:12 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 24 Jun 2024 15:31:12 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <jlyphiOtiZZWapXwcBfAHhri9ffQuTD9XjGz9NA348E=.3818010f-240b-4569-812c-185306b8dcff@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <_0jtDLz3WT2dPvhlE3oi8s3pRETfC38Uvng1wwu1y3w=.406d44cf-7821-4e2c-be26-3194016ab89d@github.com>
 <jlyphiOtiZZWapXwcBfAHhri9ffQuTD9XjGz9NA348E=.3818010f-240b-4569-812c-185306b8dcff@github.com>
Message-ID: <EKGxPP8Kf9-HwiDwUGihydF2ekT3_knmABusx1T8bao=.d3ac8946-cc71-4ed7-ae1f-ab12b4b57e6b@github.com>

On Mon, 24 Jun 2024 14:48:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> @ferakocz just tagging you as reminder of (the many) items in your queue :) 
>> Thanks!
>
>> @ferakocz just tagging you as reminder of (the many) items in your queue :) Thanks!
> 
> Sorry, I was out of office last week. I will take a deeper look at the changes tomorrow, but I have a question based on my first look at it: Do you attribute the performance loss of the XDH code path to the mult() function returning an int instead of being void? Do you think that this prevented some optimization in the hotspot compiler?

@ferakocz, now I was out on long weekend...

> Do you attribute the performance loss of the XDH code path to the mult() function returning an int instead of being void? Do you think that this prevented some optimization in the hotspot compiler?

That's exactly it. I 'proved experimentally' that that's the case. Though I haven't identified which exact sequence of optimizations is missing deterministically from compilation logs. That's beyond me yet. Identifying which optimization(s) is missing might be great for long term, but figured since we are closing down commits for this release, I should put something in soonest. This PR essentially 'reverts' the part of my ECC PR to original code. Which in turn should be easiest to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2186847183


From ascarpino at openjdk.org  Mon Jun 24 16:02:34 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 24 Jun 2024 16:02:34 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation
Message-ID: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>

Hi,

I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 

thanks

Tony

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

Commit messages:
 - copyright
 - Incorrect calculation

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

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


From ascarpino at openjdk.org  Mon Jun 24 16:03:43 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 24 Jun 2024 16:03:43 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS [v2]
In-Reply-To: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
Message-ID: <vrMZX6t4B-COLRVEhNM53fIyu9s91nCEe8WyjPBSpVY=.91615777-81f1-4c6e-b31d-4943011007b4@github.com>

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:

 - remove frag issue
 - Comments, remove thread, set NST default to 1, allow 0
 - comment cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19465/files
  - new: https://git.openjdk.org/jdk/pull/19465/files/fc7c5419..f103c804

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

  Stats: 255 lines in 9 files changed: 83 ins; 84 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/19465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19465/head:pull/19465

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


From mullan at openjdk.org  Mon Jun 24 18:33:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 24 Jun 2024 18:33:15 GMT
Subject: RFR: 8333364: Minor cleanup could be done in
 com.sun.crypto.provider [v4]
In-Reply-To: <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>
References: <n1EDq2HRU2Mxt1c_-WKI_zIbuKR_mkA5OTD3JK0KtuU=.ca4793d4-b07d-4eb9-939a-d6696a528e8f@github.com>
 <QN-P_iOn82a2vij7_egzwNpwZGYO-EV5O3v2efnHNKk=.7c1fe03c-20d9-4c0a-b4c4-5b3f54ab7c9a@github.com>
Message-ID: <KReb8qbxIraGzrQS4du278Lsqxnphb4CFJp3zY8b5fI=.54350775-3eba-4f4d-bcfe-1c7e3ca083d0@github.com>

On Fri, 14 Jun 2024 13:11:06 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8333364
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move variables to above try block

Some comments after reviewing part of it.

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 1261:

> 1259:      *
> 1260:      * @throws ShortBufferException if there is insufficient room to
> 1261:      *      write the tag.

>From line 751, `engineUpdate` can throw `ShortBufferExc` but wraps it in a `ProviderException`. Is that case possible? If so, we should change the @throws spec to a `ProviderException` but remove it from the throws line since it is a runtime exc.

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Poly1305Parameters.java line 210:

> 208:         HexDumpEncoder encoder = new HexDumpEncoder();
> 209:         return LINE_SEP + "nonce:" +
> 210:                 LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]";

This is probably not a performance sensitive method, but another fix would be to keep `StringBuilder` but call append() for each part of the String. Causes fewer objects to be created. I could accept either fix though unless there is an obvious performance issue.

src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 175:

> 173:      * Diffie-Hellman between 2 parties, this would be the other party's
> 174:      * Diffie-Hellman public key.
> 175:      * @param lastPhase flag which indicates whether this is the last

s/whether/if/

src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java line 160:

> 158:      int encryptFinal(byte[] plain, int plainOffset, int plainLen,
> 159:                       byte[] cipher, int cipherOffset)
> 160:          throws IllegalBlockSizeException, ShortBufferException {

Why was SBE removed?

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 275:

> 273:      * This is an intrinsified method.  The method's argument list must match
> 274:      * the hotspot signature.  This method and methods called by it, cannot
> 275:      * throw exceptions or allocate arrays as it will break intrinsics

Add period to end of sentence.

src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java line 86:

> 84:                             }
> 85:                         }
> 86:                     } catch (NoSuchAlgorithmException ignored) {

Debatable whether it is ok to remove that line. If code is ever added after this line and within this for block, then this code could behave differently because it would not be the same as continue.

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

PR Review: https://git.openjdk.org/jdk/pull/19535#pullrequestreview-2136470781
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1651440877
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1651443179
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1651450723
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1651454821
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1651455506
PR Review Comment: https://git.openjdk.org/jdk/pull/19535#discussion_r1651457973


From michael.osipov at innomotics.com  Wed Jun  5 09:51:36 2024
From: michael.osipov at innomotics.com (Osipov, Michael)
Date: Wed, 05 Jun 2024 09:51:36 -0000
Subject: Missing element-list for
 https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec
In-Reply-To: <d93a2dfe-50b8-4fe3-a680-cdad8aef4b81@oracle.com>
References: <5947f22d-0c8d-4063-b721-42b7dd44ba4c@siemens.com>
 <47A81E8E-1DFB-4CE1-A465-7FDE83F183DA@oracle.com>
 <d93a2dfe-50b8-4fe3-a680-cdad8aef4b81@oracle.com>
Message-ID: <PAVPR10MB7035701A19D9F217B471B27C8AF92@PAVPR10MB7035.EURPRD10.PROD.OUTLOOK.COM>

On 2024-05-31 21:38, Jonathan Gibbons wrote:
> Michael,
> 
> There is no `element-list` file for any version of JDK before JDK 9.    
> Before JDK 9, the appropriate information was in the `package-list` 
> file. In JDK 9, with the introduction of modules, the format of the file 
> was updated to include modules, and because this was an incompatible 
> change, the file was renamed as well, to `element-list`.
> 
> It is an annoying misconfiguration of `docs.oracle.com` that you are 
> seeing `302 Moved Temporarily` instead of `404 Not Found` which would be 
> a more semantically accurate response.
> 
> That leaves the question of why whatever you were doing was looking for 
> `element-list` in JDK 8. To answer that, we need more info, to determine 
> whether it is just a command-line error on your part, or any error in 
> the `javadoc` tool itself. What version of JDK and javadoc are you 
> using; what external libraries were you referencing in `-link` or `- 
> linkoffline` options; and what source level were you using, with either 
> the `-source` or `--release` options?

John,

thanks for the elaboration. Let me better clarify what happens.

The code is question with a modification for you is available at: 
https://github.com/michael-o/tomcatspnegoad/tree/javadoc-issue

Class net.sf.michaelo.tomcat.pac.asn1.AdIfRelevantAsn1Parser uses 
com.sun.security.jgss.AuthorizationDataEntry and others use private Sun 
classes which does not allow me to use -release for now, only -source. 
The source is Java 8. When I run javadoc:javadoc with Zulu 8 all links 
are generated successfully. Running Zulu 11 with extracted Javadoc call 
(&"C:\Program Files\Zulu\zulu-11\bin\javadoc.exe" -verbose "@options" 
"@packages") gives me no warning, even in verbose mode. It simply does 
not link.
When trying Temurin 22.0.1 (&"C:\Temp\jdk-22.0.1+8\bin\javadoc.exe" 
-verbose "@options" "@packages") it gives me:
> Warnung: URL https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec/element-list wurde umgeleitet an https://docs.oracle.com/en/java/javase/22/ - Aktualisieren Sie die Befehlszeilenoptionen, um diese Warnung zu unterdr?cken.

That is the redirect. Either I am misunderstanding or I have hit an edge 
case for public classes outside of the standard JDK (Java namespaces). 
Here is the input to Javadoc (@options, @packages) if you cannot try 
yourself: https://gist.github.com/michael-o/212c6797b000914b9142f1f077b1d9df

I have tried:
> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
> Java version: 11.0.18, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-11
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
> Java version: 1.8.0_362, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-8\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
> Java version: 22.0.1, vendor: Eclipse Adoptium, runtime: C:\Temp\jdk-22.0.1+8
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Note: I have routed the Javadoc traffic through Fiddler and it clearly 
following the misconfigured docs.oracle.com location:
> #	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom	
> 10	302	HTTPS	docs.oracle.com	/javase/8/docs/jre/api/security/jgss/spec/element-list	1			javadoc:24660			
> #	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom	
> 12	200	HTTPS	docs.oracle.com	/en/java/javase/22/	33 431	max-age=19052	text/html	javadoc:24660			


Regards,

Michael



From denis.gauthier at oracle.com  Fri Jun  7 02:11:02 2024
From: denis.gauthier at oracle.com (Denis Gauthier)
Date: Fri, 07 Jun 2024 02:11:02 -0000
Subject: [External] : Status of project "Brisbane"?
In-Reply-To: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>
References: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>
Message-ID: <IA1PR10MB7239FDC911CD77C545AF8F04E9FB2@IA1PR10MB7239.namprd10.prod.outlook.com>

Thanks for asking, Volker.

At this stage we're still bootstrapping the project and going through internal processes to publish its OpenJDK repositories with code. We?re also juggling other projects. I can let you know once the mailing list and repository are available. In the meantime, feel free to ping me again if you don't hear anything in the next couple of months.

Best regards,

Denis

From: Volker Simonis <volker.simonis at gmail.com>
Date: Tuesday, 4 June 2024 at 1:03?AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>, security-dev <security-dev at openjdk.java.net>, Denis Gauthier <denis.gauthier at oracle.com>
Subject: [External] : Status of project "Brisbane"?
Hi,

What's the status of Project Brisbane? According to [1], the Project
was approved two month ago on April 4th, but until now I can't find it
listed on openjdk.org nor can I find a corresponding mailing list?

Best regards,
Volker

[1] https://mail.openjdk.org/pipermail/announce/2024-April/000350.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240607/37e6752e/attachment.htm>

From weijun at openjdk.org  Mon Jun 24 20:51:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 24 Jun 2024 20:51:12 GMT
Subject: RFR: 8333772: Incorrect Kerberos behavior when
 udp_preference_limit = 0
In-Reply-To: <4eD1Gjn4Srs52Dz4HXVe5Wwt02DwIViLrXidmrosjoE=.a9ed910b-95ef-47cf-aab3-9c50f4759e57@github.com>
References: <0q44YSmFqO1fMptueypRG3kuzJv4bRhYbCnhuUEjnAU=.11d5c36c-b55e-44b6-b44e-899de22bb504@github.com>
 <4eD1Gjn4Srs52Dz4HXVe5Wwt02DwIViLrXidmrosjoE=.a9ed910b-95ef-47cf-aab3-9c50f4759e57@github.com>
Message-ID: <EEWugiZEMJ-QVpHfp9LJ6ILPlkmnE8bOrT1alR28r8U=.c8df86ce-26ef-42a9-af11-8f4e2cad4980@github.com>

On Mon, 24 Jun 2024 14:50:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Looks good. BTW, does MIT Kerberos also ignore negative values?

Yes. I set it to -1 and `kinit` shows UDP is used.

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

PR Comment: https://git.openjdk.org/jdk/pull/19638#issuecomment-2187376877


From abakhtin at openjdk.org  Tue Jun 25 02:19:20 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 25 Jun 2024 02:19:20 GMT
Subject: RFR: 8331163: Consider Trust Settings to select SSL certificate
Message-ID: <7m6ubMm0sz1f7mIcLvg-PpV7Qr5ZF0jc9DjYcNZ_kWo=.c4e0b9b3-cbfc-4655-be29-eb6f4bc85216@github.com>

Please review a proposal to verify Trust Settings for Keychain key entries.

Keychain-related Jtreg tests passed.

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

Commit messages:
 - 8331163: Consider Trust Settings to select SSL certificate

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

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


From djelinski at openjdk.org  Tue Jun 25 07:44:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Jun 2024 07:44:09 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation
In-Reply-To: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
Message-ID: <9CQXsM1ZrBLO5UOSB_FSUriYW6VELKqdDaEMRPYmZVc=.cb83251e-c248-4d5b-a8f1-84a4d368654c@github.com>

On Mon, 24 Jun 2024 15:57:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
> 
> thanks
> 
> Tony

LGTM. Thanks for fixing this!

In order to test this fix, we would need to trigger a situation where `count != position`, and it seems to be impossible, because we flush after every single message. We don't need to flush that often; I'll log a ticket for this.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19862#pullrequestreview-2137720958


From djelinski at openjdk.org  Tue Jun 25 08:17:14 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Jun 2024 08:17:14 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation
In-Reply-To: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
Message-ID: <zfLY6osiXUg4xgsN6Kl-6n9uve6aBqDOkze_41drs6o=.857c4661-b50d-4a6e-a83f-5f47abfd9d55@github.com>

On Mon, 24 Jun 2024 15:57:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
> 
> thanks
> 
> Tony

Actually, I think this line needs to be changed too.

src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java line 171:

> 169:             for (int limit = (offset + length); offset < limit;) {
> 170: 
> 171:                 int remains = (limit - offset) + (count - position);

Suggestion:

                int remains = (limit - offset);

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

Changes requested by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19862#pullrequestreview-2137826139
PR Review Comment: https://git.openjdk.org/jdk/pull/19862#discussion_r1652218588


From djelinski at openjdk.org  Tue Jun 25 10:00:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Jun 2024 10:00:15 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS [v2]
In-Reply-To: <vrMZX6t4B-COLRVEhNM53fIyu9s91nCEe8WyjPBSpVY=.91615777-81f1-4c6e-b31d-4943011007b4@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <vrMZX6t4B-COLRVEhNM53fIyu9s91nCEe8WyjPBSpVY=.91615777-81f1-4c6e-b31d-4943011007b4@github.com>
Message-ID: <Lv8O1_KsFKvZqT2qaZUTYsdgIO7kgz-lqZipsWR53q4=.79c2bb7e-d11c-445e-8ac6-4cf942910bad@github.com>

On Mon, 24 Jun 2024 16:03:43 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
>> 
>> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
>> 
>> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.
>
> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove frag issue
>  - Comments, remove thread, set NST default to 1, allow 0
>  - comment cleanup

Please add a test that starts multiple resumptions in parallel using the tickets received in the first connection. The test should verify that:
- each resumption uses a different ticket
- all resumptions succeed
- if all tickets are in use, starting another connection with setEnableSessionCreation(false) should fail

You can use multiple sslengines to run the handshakes in parallel, use setEnableSessionCreation to ensure that all sessions are resumptions, and disable stateless tickets on the server side to make sure that the sessions connections use distinct tickets.

src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 491:

> 489:     }
> 490: 
> 491:         /**

the indent still looks wrong

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 214:

> 212:                 SSLLogger.isOn("ssl,handshake")) {
> 213:                 SSLLogger.fine(
> 214:                     "jdk.tls.server.newSessionTicketCount defaults to 3 as " +

Please update the default

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 93:

> 91:         if (server) {
> 92:             sessionCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
> 93:             sessionHostPortCache = Cache.newSoftMemoryCache(cacheLimit, timeout);

preexisting, but I wonder if we could use nullCache here and in client's sessionCache

src/java.base/share/classes/sun/security/util/Cache.java line 716:

> 714:                 }
> 715:                 if (entry.isValid(time)) {
> 716:                     // SoftReference get() returns the same as entry.getValue()

this doesn't look right

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

PR Review: https://git.openjdk.org/jdk/pull/19465#pullrequestreview-2137983069
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1652325926
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1652325340
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1652327574
PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1652368738


From mullan at openjdk.org  Tue Jun 25 12:24:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Jun 2024 12:24:14 GMT
Subject: Integrated: 8248981: Specify list of standard message digest and mgf
 algorithms for RSASSA-PSS signature
In-Reply-To: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>
References: <hNOtizdKOO2zsqX3DDsaoa8mhR0qKs_51ZFN1WrRIHg=.03422470-2218-45cc-81f4-834e7ce560d7@github.com>
Message-ID: <fGimVNM7VknLAzJ-0KZZdidO118Qe0W7cPlmck15zxs=.42c662a3-a819-4492-8e59-1424804a3b66@github.com>

On Fri, 14 Jun 2024 15:32:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Added links from the `PSSParameterSpec` API to new section in Standard Algorithm Names specification for PSSParameterSpec (changes for that are in closed repo). Also made a couple of links to the Standard Algorithm Names specification in `ECGenParameterSpec` and `NamedParameterSpec` more specific.

This pull request has now been integrated.

Changeset: 75a2afac
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75a2afacc8f5fdec53350b1cb66076cdfeae12f0
Stats:     24 lines in 3 files changed: 11 ins; 0 del; 13 mod

8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature

Reviewed-by: valeriep

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

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


From rhalade at openjdk.org  Tue Jun 25 16:04:14 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 25 Jun 2024 16:04:14 GMT
Subject: RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
Message-ID: <o-IuHiCRLfqk92X8zFDX9RMrEtGCyMVPg95eaIZlCxs=.4f1e1ad1-51e7-453d-8f8c-045b45cdb82b@github.com>

On Wed, 5 Jun 2024 02:57:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for this simple change to fix a threading problem with the test. The server thread was not completing before the check occurred on the main thread.  The failure showed up in windows and macos, but not linux.  With this fix, running 100 times, windows & macos showed no failures.
> 
> Tony

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19553#pullrequestreview-2139144724


From duke at openjdk.org  Tue Jun 25 17:33:23 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 25 Jun 2024 17:33:23 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <ZV4qveeI_ZlXBHpCmdOwi_RmW45T9Qy9-1aEk3boubA=.b5ba45bd-868a-450e-b445-9c9ef4b300de@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
 <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
 <ZV4qveeI_ZlXBHpCmdOwi_RmW45T9Qy9-1aEk3boubA=.b5ba45bd-868a-450e-b445-9c9ef4b300de@github.com>
Message-ID: <VQM8JeYWbHfTe8Sa4B8DWjTkx9-7VmEVzqia__J5LHI=.2ad83f04-a782-411c-a0bf-19cac781267b@github.com>

On Mon, 17 Jun 2024 19:21:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>>> What causes regression in P256 "(~-8-14%)"? From what I see, you re-arranged code to not execute some code ("reducePositive()") when it is not needed. How this affects P256?
>> 
>> Actually, the other way around; reducePositive is now an unconditionally executed for both pure java and the intrinsic paths. Perhaps that's what is misleading, it was only the mult() intrinsic that was taking advantage of this 'skip reduction' before. (pure java did not benefit from removing reduction, so I kept it. Now 'keeping it' for both paths)
>
> Hi @vpaprotsk, 
> @ferakocz is going to take a look at the change.  When he says it's ok, I'll approve the PR.

@ascarpino please approve this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2189546944


From duke at openjdk.org  Tue Jun 25 17:33:22 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 25 Jun 2024 17:33:22 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <yy3rsqYKtGaldhNjepXxWFJvkCGxIkRwdqOAq-5sVYQ=.62155162-afa7-4c15-a5d2-a167bab02836@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

Looks good to me. It would be good, though, to figure out what else could be done to regain the P256 performance with keeping the speed of this code path.

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2189545307


From andrew at openjdk.org  Tue Jun 25 17:48:32 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 25 Jun 2024 17:48:32 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
Message-ID: <wGZSAaOyNa_ihdZyOXe2Wk2p0z-AitonYkxdgH4Ie2g=.8262bc97-3864-4822-8aa9-18c3e39c1197@github.com>

On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typos

Is there still going to be some monitoring of these tests? Making it harder to run these tests potentially means that genuine failures can go unnoticed and JDK certificates are not updated when needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19814#issuecomment-2189601735


From ascarpino at openjdk.org  Tue Jun 25 18:29:12 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Jun 2024 18:29:12 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation
In-Reply-To: <zfLY6osiXUg4xgsN6Kl-6n9uve6aBqDOkze_41drs6o=.857c4661-b50d-4a6e-a83f-5f47abfd9d55@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
 <zfLY6osiXUg4xgsN6Kl-6n9uve6aBqDOkze_41drs6o=.857c4661-b50d-4a6e-a83f-5f47abfd9d55@github.com>
Message-ID: <pOgA8-73KxJIfKm-v81T5C7CD7q5KydIstkLGOf9Gqw=.f77dabb1-6a9c-42d4-b165-2eea353bf197@github.com>

On Tue, 25 Jun 2024 08:14:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
>> 
>> thanks
>> 
>> Tony
>
> src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java line 171:
> 
>> 169:             for (int limit = (offset + length); offset < limit;) {
>> 170: 
>> 171:                 int remains = (limit - offset) + (count - position);
> 
> Suggestion:
> 
>                 int remains = (limit - offset);

I tried this and it caused a lockup in one of the tests.  I see why your think this is the right change, but it isn't proving out in the testing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19862#discussion_r1653335017


From djelinski at openjdk.org  Tue Jun 25 19:46:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Jun 2024 19:46:10 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation
In-Reply-To: <pOgA8-73KxJIfKm-v81T5C7CD7q5KydIstkLGOf9Gqw=.f77dabb1-6a9c-42d4-b165-2eea353bf197@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
 <zfLY6osiXUg4xgsN6Kl-6n9uve6aBqDOkze_41drs6o=.857c4661-b50d-4a6e-a83f-5f47abfd9d55@github.com>
 <pOgA8-73KxJIfKm-v81T5C7CD7q5KydIstkLGOf9Gqw=.f77dabb1-6a9c-42d4-b165-2eea353bf197@github.com>
Message-ID: <dRzqh5HAF0qxmpH5Hbw9SA-rKhHNy4rnWzrZ8lnQXJM=.b34eb47e-516a-4e43-b6e4-d8ad3881a738@github.com>

On Tue, 25 Jun 2024 18:26:40 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java line 171:
>> 
>>> 169:             for (int limit = (offset + length); offset < limit;) {
>>> 170: 
>>> 171:                 int remains = (limit - offset) + (count - position);
>> 
>> Suggestion:
>> 
>>                 int remains = (limit - offset);
>
> I tried this and it caused a lockup in one of the tests.  I see why your think this is the right change, but it isn't proving out in the testing

That's very interesting! Which test was it? Was it with or without #19465?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19862#discussion_r1653464830


From ascarpino at openjdk.org  Tue Jun 25 21:49:10 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Jun 2024 21:49:10 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation
In-Reply-To: <dRzqh5HAF0qxmpH5Hbw9SA-rKhHNy4rnWzrZ8lnQXJM=.b34eb47e-516a-4e43-b6e4-d8ad3881a738@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
 <zfLY6osiXUg4xgsN6Kl-6n9uve6aBqDOkze_41drs6o=.857c4661-b50d-4a6e-a83f-5f47abfd9d55@github.com>
 <pOgA8-73KxJIfKm-v81T5C7CD7q5KydIstkLGOf9Gqw=.f77dabb1-6a9c-42d4-b165-2eea353bf197@github.com>
 <dRzqh5HAF0qxmpH5Hbw9SA-rKhHNy4rnWzrZ8lnQXJM=.b34eb47e-516a-4e43-b6e4-d8ad3881a738@github.com>
Message-ID: <zM42ER7SzXhMs1Ox4dzPRl9KF-7VgZ8gnMu00Tq7dDc=.eb5beaa6-3a85-4250-9c67-b07cc0757b33@github.com>

On Tue, 25 Jun 2024 19:44:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I tried this and it caused a lockup in one of the tests.  I see why your think this is the right change, but it isn't proving out in the testing
>
> That's very interesting! Which test was it? Was it with or without #19465?

I do run the tests layered on the current #19465, even though this PR is separate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19862#discussion_r1653610125


From ascarpino at openjdk.org  Tue Jun 25 22:16:11 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Jun 2024 22:16:11 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
Message-ID: <MsS67mjiaSARkaa0-mJb6OF6vXRzf07pIaAUmv4HF2s=.538ea159-5e8b-4700-b241-58af61a11a7a@github.com>

On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
>> 
>> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
>> 
>> ---
>> XDH.generateSecret performance 
>> before Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
>> 
>> after Montgomery PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
>> 
>> with this PR:
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
>> 
>> ---
>> 
>> P256 performance with/without mult intrinsic:
>> 
>> Performance before Montgomery PR:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
>> 
>> Performance in master without mult() intrinsic
>> 
>> Benchmark                        ...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sandhya

Approved with review by @ferakocz

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19728#pullrequestreview-2139971558


From duke at openjdk.org  Tue Jun 25 22:34:15 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 25 Jun 2024 22:34:15 GMT
Subject: RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538 [v3]
In-Reply-To: <VQM8JeYWbHfTe8Sa4B8DWjTkx9-7VmEVzqia__J5LHI=.2ad83f04-a782-411c-a0bf-19cac781267b@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
 <x4bG1wNlsTWC_7bbgTAAUZR_TMsEit8Iqr41y7GI9Nw=.38828804-4706-4902-8f64-f215f654774c@github.com>
 <xvQKkrdgpTD47a1ReBcwSpW72rM-Nk82qigaYL1qZ7g=.123f3a08-b67d-4717-af8d-e4381fb25504@github.com>
 <s4ALntfjPE_n0XOA4aGu4vtp9hkf1ez01VytUwHKchE=.d0217efe-8d06-4862-bc07-bc1b0693a9cb@github.com>
 <ZV4qveeI_ZlXBHpCmdOwi_RmW45T9Qy9-1aEk3boubA=.b5ba45bd-868a-450e-b445-9c9ef4b300de@github.com>
 <VQM8JeYWbHfTe8Sa4B8DWjTkx9-7VmEVzqia__J5LHI=.2ad83f04-a782-411c-a0bf-19cac781267b@github.com>
Message-ID: <5zUIiLs4JCGj0L7ullCkipQ0Q1V-gIYjkNt8ylS00YM=.2d42bed6-a3e0-429c-b4e2-14e8e0d1a474@github.com>

On Tue, 25 Jun 2024 17:31:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Hi @vpaprotsk, 
>> @ferakocz is going to take a look at the change.  When he says it's ok, I'll approve the PR.
>
> @ascarpino please approve this change.

Thanks @ferakocz @ascarpino

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

PR Comment: https://git.openjdk.org/jdk/pull/19728#issuecomment-2190106639


From duke at openjdk.org  Tue Jun 25 22:34:16 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 25 Jun 2024 22:34:16 GMT
Subject: Integrated: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538
In-Reply-To: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
References: <KvgLPTUCETLCHGhAdfyX_QQ-F9_MI0hC9oKf2Rmjy50=.6b817249-4819-4528-9eed-1bee618f79df@github.com>
Message-ID: <zfoxN4jG_koLn043VSw_00aiBXitW8tMzE1fNAY7irI=.c333cd63-c27d-4c37-8fdc-1ec9b0a5c292@github.com>

On Fri, 14 Jun 2024 20:23:04 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> This fix recovers XDH performance but removes some of the P256 gains (~-8-14%). Still faster, but not as much.
> 
> The fix is to undo 'int' return type on mult()/square(), which allowed to return partially reduced result (e.g. this avoids extra reductions when mult() result is fed into addition). This is the behaviour before the Montgomery ECC PR.
> 
> ---
> XDH.generateSecret performance 
> before Montgomery PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8435.277 ? 27.230  ops/s
> 
> after Montgomery PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8309.028 ? 22.071  ops/s
> 
> with this PR:
> 
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> KeyAgreementBench.XDH.generateSecret          XDH          255             XDH              thrpt    3  8491.268 ? 32.858  ops/s
> 
> ---
> 
> P256 performance with/without mult intrinsic:
> 
> Performance before Montgomery PR:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6398.727 ?  7.400  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6129.739 ?  5.995  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1889.928 ? 54.660  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1866.339 ? 42.438  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1350.745 ? 28.514  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1349.393 ? 32.050  ops/s
> 
> Performance in master without mult() intrinsic
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Err...

This pull request has now been integrated.

Changeset: f101e153
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522
Stats:     125 lines in 9 files changed: 35 ins; 52 del; 38 mod

8333583: Crypto-XDH.generateSecret regression after JDK-8329538

Reviewed-by: sviswanathan, kvn, ascarpino

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

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


From ascarpino at openjdk.org  Tue Jun 25 23:14:38 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Jun 2024 23:14:38 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation [v2]
In-Reply-To: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
Message-ID: <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>

> Hi,
> 
> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
> 
> thanks
> 
> Tony

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

  updated changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19862/files
  - new: https://git.openjdk.org/jdk/pull/19862/files/ec5fe598..daee7cdd

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

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

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


From duke at openjdk.org  Tue Jun 25 23:55:35 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 25 Jun 2024 23:55:35 GMT
Subject: [jdk23] RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538
Message-ID: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>

Hi all,

This pull request contains a backport of commit [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Thanks!

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

Commit messages:
 - Backport f101e153cee68750fcf1f12da10e29806875b522

Changes: https://git.openjdk.org/jdk/pull/19893/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333583
  Stats: 125 lines in 9 files changed: 35 ins; 52 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/19893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19893/head:pull/19893

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


From duke at openjdk.org  Wed Jun 26 03:04:11 2024
From: duke at openjdk.org (Aksh Desai)
Date: Wed, 26 Jun 2024 03:04:11 GMT
Subject: [jdk23] RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538
In-Reply-To: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
References: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
Message-ID: <CPqOIdbqJzsF6o4McQMihP6nHrjUzPPmo3mxiZmofnc=.c92a401a-4ced-4251-a706-d887972ff59d@github.com>

On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Volodymyr Paprotski on 25 Jun 2024 and was reviewed by Sandhya Viswanathan, Vladimir Kozlov, Ferenc Rakoczi and Anthony Scarpino.
> 
> Thanks!

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

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

PR Review: https://git.openjdk.org/jdk/pull/19893#pullrequestreview-2140336933


From ssahoo at openjdk.org  Wed Jun 26 05:32:10 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 26 Jun 2024 05:32:10 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation [v2]
In-Reply-To: <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
 <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>
Message-ID: <Nw6aICx-ClxCNplxkhgEqCfV-0mJEVLHNHcxnKjf2AQ=.e682c2af-658a-4e03-a2d5-d3188fb59df2@github.com>

On Tue, 25 Jun 2024 23:14:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated changes

Is it possible to add a Test?

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

PR Review: https://git.openjdk.org/jdk/pull/19862#pullrequestreview-2140632064


From thartmann at openjdk.org  Wed Jun 26 06:34:12 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 26 Jun 2024 06:34:12 GMT
Subject: [jdk23] RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538
In-Reply-To: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
References: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
Message-ID: <dsRsYI8jRPdflwBF66wlunxoclRYV7ZNfte2DtKyVpE=.9b8f7aed-8c44-4e91-a1cd-f5ce606f6765@github.com>

On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Volodymyr Paprotski on 25 Jun 2024 and was reviewed by Sandhya Viswanathan, Vladimir Kozlov, Ferenc Rakoczi and Anthony Scarpino.
> 
> Thanks!

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19893#pullrequestreview-2140832004


From djelinski at openjdk.org  Wed Jun 26 06:57:14 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 26 Jun 2024 06:57:14 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation [v2]
In-Reply-To: <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
 <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>
Message-ID: <fdoBtvRW3J0OLTdVjqID2cf2zLkkHBrPw6YgIwL90eE=.9d1cf753-5cc5-404d-9b18-da19478d63fd@github.com>

On Tue, 25 Jun 2024 23:14:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated changes

Thanks for making the change. LGTM.
> Is it possible to add a Test?

I don't think it is possible; right now we flush after every handshake message. As a result, `count == position` every time we enter this loop, so the change doesn't really change anything. The problem only surfaced in #19465, and only when multiple NewSessionTicket messages exceeding 16KB were sent without flushing.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19862#pullrequestreview-2140881188


From ssahoo at openjdk.org  Wed Jun 26 06:57:14 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 26 Jun 2024 06:57:14 GMT
Subject: RFR: 8334670: SSLSocketOutputRecord buffer miscalculation [v2]
In-Reply-To: <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
 <y0cFIliJpBFQlA-h-o1RC5-viB4ivMgUvnc1gqlEnfw=.78315fcc-a4ff-4764-b4c3-a04a98ee4963@github.com>
Message-ID: <Q_DN98o4lD78U1R-_gcw_6w_9V3qNrk8Ibf3cyoFcn8=.90d8f396-9326-434a-a8d1-0836d86f6cde@github.com>

On Tue, 25 Jun 2024 23:14:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated changes

Marked as reviewed by ssahoo (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19862#pullrequestreview-2140886184


From fguallini at openjdk.org  Wed Jun 26 13:19:10 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 26 Jun 2024 13:19:10 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
Message-ID: <6S1leYCzb7SNfjp1NR1JJ6hAulsZb7PoJWPf2IJJPXo=.67e840cb-47e7-452a-bc58-cbad308818ae@github.com>

On Wed, 19 Jun 2024 12:47:33 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
> 
> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

Please, I would need a review on this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/19790#issuecomment-2191674728


From ascarpino at openjdk.org  Wed Jun 26 14:01:14 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 26 Jun 2024 14:01:14 GMT
Subject: Integrated: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
References: <KRcHY6nICWNENil-1AcDT7o0xBctZbyn7ixbfra0ls4=.98581f83-702d-44bc-aa85-3505ad758a63@github.com>
Message-ID: <F5KWX4uan9ZdtiC8Z2fHt2Su6hJq7C97vmJJkKkZni0=.4e8cbffa-d490-4d1a-9325-cdbd119e09c3@github.com>

On Wed, 5 Jun 2024 02:57:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for this simple change to fix a threading problem with the test. The server thread was not completing before the check occurred on the main thread.  The failure showed up in windows and macos, but not linux.  With this fix, running 100 times, windows & macos showed no failures.
> 
> Tony

This pull request has now been integrated.

Changeset: 4ffc5e60
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ffc5e60776353b03e9a557c39148e378b1690e2
Stats:     36 lines in 3 files changed: 13 ins; 5 del; 18 mod

8326705: Test CertMsgCheck.java fails to find alert certificate_required

Reviewed-by: ssahoo, rhalade

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

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


From rhalade at openjdk.org  Wed Jun 26 14:17:14 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 26 Jun 2024 14:17:14 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <wGZSAaOyNa_ihdZyOXe2Wk2p0z-AitonYkxdgH4Ie2g=.8262bc97-3864-4822-8aa9-18c3e39c1197@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
 <wGZSAaOyNa_ihdZyOXe2Wk2p0z-AitonYkxdgH4Ie2g=.8262bc97-3864-4822-8aa9-18c3e39c1197@github.com>
Message-ID: <RDhfkZcyfOWCgNcR_4w_gtnQiQTQK-gFNug9RntF6OE=.da006239-f38f-41cb-9636-13e3ea503837@github.com>

On Tue, 25 Jun 2024 17:45:23 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Is there still going to be some monitoring of these tests? Making it harder to run these tests potentially means that genuine failures can go unnoticed and JDK certificates are not updated when needed.

Tracking won?t be any different than other manual tests in the test suite. Within Oracle, we recommend that developers working on security libraries fixes run these tests before integration. All manual tests are definitely run during the release certification.

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

PR Comment: https://git.openjdk.org/jdk/pull/19814#issuecomment-2191822556


From weijun at openjdk.org  Wed Jun 26 15:26:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Jun 2024 15:26:12 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
Message-ID: <K4gQhjgHgn5nXzxH3HoautI3j4Big1a0y6oUZ2y0Kd8=.f1639986-505b-44bb-bc28-5a11736f84ef@github.com>

On Wed, 19 Jun 2024 12:47:33 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
> 
> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Default.java line 80:

> 78:         pipedOut.write("-1\n".getBytes());
> 79:         pipedOut.flush();
> 80:         textHandler.handle(new Callback[]{callback});

Can you handle 2 `Callback`s in a single `handle` call?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19790#discussion_r1655087405


From sviswanathan at openjdk.org  Wed Jun 26 15:27:23 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 26 Jun 2024 15:27:23 GMT
Subject: [jdk23] RFR: 8333583: Crypto-XDH.generateSecret regression after
 JDK-8329538
In-Reply-To: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
References: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
Message-ID: <CSasycsskm11sghX65nMkGV1lxlbaD7aYqzTLcu3lk0=.1bda09e0-c902-4cbc-a697-a1ed2951646a@github.com>

On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Volodymyr Paprotski on 25 Jun 2024 and was reviewed by Sandhya Viswanathan, Vladimir Kozlov, Ferenc Rakoczi and Anthony Scarpino.
> 
> Thanks!

Marked as reviewed by sviswanathan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19893#pullrequestreview-2142217862


From duke at openjdk.org  Wed Jun 26 15:27:23 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 26 Jun 2024 15:27:23 GMT
Subject: [jdk23] Integrated: 8333583: Crypto-XDH.generateSecret regression
 after JDK-8329538
In-Reply-To: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
References: <N4Uq_gGWv6UQdIZz2hjlssqF4diajCwbdbNTrc-Bx3I=.79afa7ad-6d6b-4ced-bf6c-dbc4688915f5@github.com>
Message-ID: <Frgj3vF9lZEQcdBac0l_Na8UWsbN3CIJW-MzbkpkzAE=.b2c6e661-3300-4b4d-bd6e-094623726bb4@github.com>

On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Volodymyr Paprotski on 25 Jun 2024 and was reviewed by Sandhya Viswanathan, Vladimir Kozlov, Ferenc Rakoczi and Anthony Scarpino.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b5fbdb21
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5fbdb2166352df63d9d9f5481f3b079238d6f90
Stats:     125 lines in 9 files changed: 35 ins; 52 del; 38 mod

8333583: Crypto-XDH.generateSecret regression after JDK-8329538

Reviewed-by: thartmann, sviswanathan
Backport-of: f101e153cee68750fcf1f12da10e29806875b522

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

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


From weijun at openjdk.org  Wed Jun 26 16:14:11 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Jun 2024 16:14:11 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <K4gQhjgHgn5nXzxH3HoautI3j4Big1a0y6oUZ2y0Kd8=.f1639986-505b-44bb-bc28-5a11736f84ef@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
 <K4gQhjgHgn5nXzxH3HoautI3j4Big1a0y6oUZ2y0Kd8=.f1639986-505b-44bb-bc28-5a11736f84ef@github.com>
Message-ID: <Lixf2a0V7QVg0D1OrNAV6LpooEIG3T9IJGoOgJv6L5o=.a0c9fc70-923d-4261-868c-5d44f56a2938@github.com>

On Wed, 26 Jun 2024 15:23:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
>> 
>> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.
>
> test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Default.java line 80:
> 
>> 78:         pipedOut.write("-1\n".getBytes());
>> 79:         pipedOut.flush();
>> 80:         textHandler.handle(new Callback[]{callback});
> 
> Can you handle 2 `Callback`s in a single `handle` call?

Try if this class works for you. https://github.com/openjdk/jdk/blob/45a616a891e4a4b0e77b1f2fa040522f4a99d172/test/jdk/sun/security/tools/keytool/KeyToolTest.java#L1885

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19790#discussion_r1655156432


From ascarpino at openjdk.org  Wed Jun 26 22:31:14 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 26 Jun 2024 22:31:14 GMT
Subject: Integrated: 8334670: SSLSocketOutputRecord buffer miscalculation
In-Reply-To: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
References: <TU3xJWZrhqnkSgUJRammt-5bRkymnh7chf4gGGrUkvM=.db6928e0-463f-475d-9a60-319845c8bcad@github.com>
Message-ID: <iS_9WNSUBSJ1aoGyeoCM7qNWt5XnR-xZJaZii_m2m4U=.3854a570-d185-4511-a577-15efd55c162f@github.com>

On Mon, 24 Jun 2024 15:57:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review to change the a fragment buffer size miscalculation error.   This appears when there are large handshake messages and hasn't been observed during application data.  This was found during testing of the NewSessionTicket change in [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608).  There is no regression test as the failure hasn't shown to fail every time. 
> 
> thanks
> 
> Tony

This pull request has now been integrated.

Changeset: 07bc523d
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07bc523df85fde81bf736fedac62874d3cb11ee3
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8334670: SSLSocketOutputRecord buffer miscalculation

Reviewed-by: djelinski, ssahoo

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

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


From ascarpino at openjdk.org  Wed Jun 26 23:11:31 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 26 Jun 2024 23:11:31 GMT
Subject: [jdk23] RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
Message-ID: <0syIDyTbKCpAg262Knc4LmlZCPkdf1Z03XvS-trxW1c=.8f713d25-45b0-483e-889d-cd972d78ecca@github.com>

Hi,

I need a review of this clean backport of this test fix to jdk23.

Tony

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

Commit messages:
 - Backport 4ffc5e60776353b03e9a557c39148e378b1690e2

Changes: https://git.openjdk.org/jdk/pull/19917/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19917&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326705
  Stats: 36 lines in 3 files changed: 13 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/19917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19917/head:pull/19917

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


From fguallini at openjdk.org  Thu Jun 27 10:03:11 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 27 Jun 2024 10:03:11 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <Lixf2a0V7QVg0D1OrNAV6LpooEIG3T9IJGoOgJv6L5o=.a0c9fc70-923d-4261-868c-5d44f56a2938@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
 <K4gQhjgHgn5nXzxH3HoautI3j4Big1a0y6oUZ2y0Kd8=.f1639986-505b-44bb-bc28-5a11736f84ef@github.com>
 <Lixf2a0V7QVg0D1OrNAV6LpooEIG3T9IJGoOgJv6L5o=.a0c9fc70-923d-4261-868c-5d44f56a2938@github.com>
Message-ID: <a1rYYBrUW4unLmAvJ__cADneU2PwLbs3zxx3b1cq5YY=.c6eb56de-0a71-4a7e-907b-b2af3d465b4c@github.com>

On Wed, 26 Jun 2024 16:11:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Default.java line 80:
>> 
>>> 78:         pipedOut.write("-1\n".getBytes());
>>> 79:         pipedOut.flush();
>>> 80:         textHandler.handle(new Callback[]{callback});
>> 
>> Can you handle 2 `Callback`s in a single `handle` call?
>
> Try if this class works for you. https://github.com/openjdk/jdk/blob/45a616a891e4a4b0e77b1f2fa040522f4a99d172/test/jdk/sun/security/tools/keytool/KeyToolTest.java#L1885

@wangweij 
I was handling the callback in 2 separate calls because it was blocking and timing out while waiting for input. Now, using _HumanInputStream_ allows handling it in a single call. Unfortunately this class is not visible for this jteg test. To compile it properly, I would need to include the following annotations in the test:

 * @modules java.base/sun.security.tools.keytool
 *          java.base/sun.security.util
 *          java.base/sun.security.x509
 * @compile ../../../../../../sun/security/tools/keytool/KeyToolTest.java

 But, this would couple both tests together. would it be useful extracting HumanInputStream into a common library class?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19790#discussion_r1656856262


From redestad at openjdk.org  Thu Jun 27 12:31:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 27 Jun 2024 12:31:20 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
Message-ID: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>

This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
(only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 

Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):


Name                                    Cnt     Base     Error      Test     Error  Unit  Change
StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
StringConcat.concatMix4String            50   89.243 ?   0.436    71.866 ?   0.894 ns/op   1.24x (p = 0.000*)
StringConcatStartup.MixedLarge.run       10  655.436 ?  29.787   649.730 ?  26.053 ms/op   1.01x (p = 0.500 )
StringConcatStartup.MixedSmall.run       20   51.676 ?   2.324    50.724 ?   5.050 ms/op   1.02x (p = 0.512 )
StringConcatStartup.StringLarge.run      10  166.022 ?  15.672   165.300 ?  14.433 ms/op   1.00x (p = 0.873 )
StringConcatStartup.StringSingle.run     40    0.168 ?   0.016     0.178 ?   0.024 ms/op   0.94x (p = 0.234 )
* = significant


Startup-wise it's more or less neutral as evidenced by the added `StringConcatStartup` micro (a simplified and JMH:ified version of some startup stress tests I've been tinkering with over the years). This PR does not change the total number of classes generated and loaded by this test (3359 total, 2499 generated).

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

Commit messages:
 - Add StringConcatStartup JMH
 - Merge branch 'master' into consolidated_prependers
 - Simplify
 - Remove getBytes changes
 - Streamline newArray
 - Consolidate to always end with newArrayWithSuffix
 - Merge branch 'master' into consolidated_prependers
 - Streamline prependers
 - Fix compilation errors from removing non-prefixed prepend methods
 - Remove non-prefix prepender methods, inline logic into prefixed variant
 - ... and 1 more: https://git.openjdk.org/jdk/compare/efb905e5...6525e945

Changes: https://git.openjdk.org/jdk/pull/19927/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19927&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335182
  Stats: 565 lines in 6 files changed: 412 ins; 114 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/19927.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19927/head:pull/19927

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


From weijun at openjdk.org  Thu Jun 27 12:50:10 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Jun 2024 12:50:10 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <a1rYYBrUW4unLmAvJ__cADneU2PwLbs3zxx3b1cq5YY=.c6eb56de-0a71-4a7e-907b-b2af3d465b4c@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
 <K4gQhjgHgn5nXzxH3HoautI3j4Big1a0y6oUZ2y0Kd8=.f1639986-505b-44bb-bc28-5a11736f84ef@github.com>
 <Lixf2a0V7QVg0D1OrNAV6LpooEIG3T9IJGoOgJv6L5o=.a0c9fc70-923d-4261-868c-5d44f56a2938@github.com>
 <a1rYYBrUW4unLmAvJ__cADneU2PwLbs3zxx3b1cq5YY=.c6eb56de-0a71-4a7e-907b-b2af3d465b4c@github.com>
Message-ID: <yxS19B-ep0pFnVT_ZTUbaPHHNhCstaf_y1munG0Oef8=.a34de74c-34cd-462a-9900-18d2f1a198bd@github.com>

On Thu, 27 Jun 2024 10:00:31 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> Try if this class works for you. https://github.com/openjdk/jdk/blob/45a616a891e4a4b0e77b1f2fa040522f4a99d172/test/jdk/sun/security/tools/keytool/KeyToolTest.java#L1885
>
> @wangweij 
> I was handling the callback in 2 separate calls because it was blocking and timing out while waiting for input. Now, using _HumanInputStream_ allows handling it in a single call. Unfortunately this class is not visible for this jteg test. To compile it properly, I would need to include the following annotations in the test:
> 
>  * @modules java.base/sun.security.tools.keytool
>  *          java.base/sun.security.util
>  *          java.base/sun.security.x509
>  * @compile ../../../../../../sun/security/tools/keytool/KeyToolTest.java
> 
>  But, this would couple both tests together. would it be useful extracting HumanInputStream into a common library class?

Sure, you can put it into `test/jdk/java/security/testlibrary`. I'm not sure if it's mature enough to be put into `test/lib`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19790#discussion_r1657075650


From rhalade at openjdk.org  Thu Jun 27 14:12:11 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 27 Jun 2024 14:12:11 GMT
Subject: [jdk23] RFR: 8326705: Test CertMsgCheck.java fails to find alert
 certificate_required
In-Reply-To: <0syIDyTbKCpAg262Knc4LmlZCPkdf1Z03XvS-trxW1c=.8f713d25-45b0-483e-889d-cd972d78ecca@github.com>
References: <0syIDyTbKCpAg262Knc4LmlZCPkdf1Z03XvS-trxW1c=.8f713d25-45b0-483e-889d-cd972d78ecca@github.com>
Message-ID: <VZaxwl9ru3zR2D7FiJtiWQ8Nh39L-UMPGxZRDdufxo0=.34d18030-515c-40fb-ba46-5b33696b888e@github.com>

On Wed, 26 Jun 2024 23:01:50 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this clean backport of this test fix to jdk23.
> 
> Tony

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19917#pullrequestreview-2145507373


From ascarpino at openjdk.org  Thu Jun 27 14:20:14 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Jun 2024 14:20:14 GMT
Subject: [jdk23] Integrated: 8326705: Test CertMsgCheck.java fails to find
 alert certificate_required
In-Reply-To: <0syIDyTbKCpAg262Knc4LmlZCPkdf1Z03XvS-trxW1c=.8f713d25-45b0-483e-889d-cd972d78ecca@github.com>
References: <0syIDyTbKCpAg262Knc4LmlZCPkdf1Z03XvS-trxW1c=.8f713d25-45b0-483e-889d-cd972d78ecca@github.com>
Message-ID: <NpMVW9w0xRJbH8a5VlNGVPSvMYhxa4Jg1-eLsaBAUn4=.982492dc-9675-4296-87e4-ee1a6a2319e4@github.com>

On Wed, 26 Jun 2024 23:01:50 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this clean backport of this test fix to jdk23.
> 
> Tony

This pull request has now been integrated.

Changeset: 98fd657c
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98fd657cfa44e61b14651cc3e9b61aaf13a4fc47
Stats:     36 lines in 3 files changed: 13 ins; 5 del; 18 mod

8326705: Test CertMsgCheck.java fails to find alert certificate_required

Reviewed-by: rhalade
Backport-of: 4ffc5e60776353b03e9a557c39148e378b1690e2

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

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


From fferrari at openjdk.org  Thu Jun 27 15:10:17 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 27 Jun 2024 15:10:17 GMT
Subject: Integrated: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11
In-Reply-To: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
Message-ID: <vr5r2oopdphf_d8FrTumT4P5snSpURE8fX3k4zhe6T4=.1ac858c0-a0f0-45aa-a0c0-9a26d8870a9c@github.com>

On Mon, 22 Apr 2024 18:31:37 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> Hi,
> 
> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
> 
> What follows are implementation notes that describe the most relevant aspects of the proposed change.
> 
> ### Buffering
> 
> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block bu
 ffering will still work and allow it to support old versions of the NSS library.
> 
> ### `implUpdate` implementation
> 
> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
> 
> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the data source (`padBuffer` or input...

This pull request has now been integrated.

Changeset: 4ab7e98c
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Committer: Martin Balao <mbalao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e
Stats:     625 lines in 7 files changed: 533 ins; 28 del; 64 mod

8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11

Co-authored-by: Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Co-authored-by: Martin Balao <mbalao at openjdk.org>
Reviewed-by: valeriep

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

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


From jvernee at openjdk.org  Thu Jun 27 15:37:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Jun 2024 15:37:11 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <VDpq5Qg3ZUGvNPoxiUGEc38uNY7dacqZoZRpOc3E19I=.77c66597-b460-4183-9d53-ed642c41e399@github.com>

On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

Ok, so, it turns out that specializing no-prefix prependers is actually slower than using `""` as a prefix. Nice catch

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19927#pullrequestreview-2145774085


From fguallini at openjdk.org  Thu Jun 27 15:37:45 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 27 Jun 2024 15:37:45 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test [v2]
In-Reply-To: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
Message-ID: <QMvSq6QYIuZ1hvCqH2Hah2zgMjvYBAmRtmaEMs0VGxI=.624a5b0e-18c6-4ba2-baf2-dc1cc7a70e62@github.com>

> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
> 
> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

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

  move HumanInputStream to test library for reusability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19790/files
  - new: https://git.openjdk.org/jdk/pull/19790/files/648e556a..d9dbdfa3

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

  Stats: 382 lines in 3 files changed: 194 ins; 181 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19790.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19790/head:pull/19790

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


From fguallini at openjdk.org  Thu Jun 27 15:37:46 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 27 Jun 2024 15:37:46 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test [v2]
In-Reply-To: <yxS19B-ep0pFnVT_ZTUbaPHHNhCstaf_y1munG0Oef8=.a34de74c-34cd-462a-9900-18d2f1a198bd@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
 <K4gQhjgHgn5nXzxH3HoautI3j4Big1a0y6oUZ2y0Kd8=.f1639986-505b-44bb-bc28-5a11736f84ef@github.com>
 <Lixf2a0V7QVg0D1OrNAV6LpooEIG3T9IJGoOgJv6L5o=.a0c9fc70-923d-4261-868c-5d44f56a2938@github.com>
 <a1rYYBrUW4unLmAvJ__cADneU2PwLbs3zxx3b1cq5YY=.c6eb56de-0a71-4a7e-907b-b2af3d465b4c@github.com>
 <yxS19B-ep0pFnVT_ZTUbaPHHNhCstaf_y1munG0Oef8=.a34de74c-34cd-462a-9900-18d2f1a198bd@github.com>
Message-ID: <Ui78U8ua0F473VcptNJpXgt4uvfoXP4mJL9qzm38G8s=.805b6b3a-51de-4c04-98a4-913ebe2b0771@github.com>

On Thu, 27 Jun 2024 12:48:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> @wangweij 
>> I was handling the callback in 2 separate calls because it was blocking and timing out while waiting for input. Now, using _HumanInputStream_ allows handling it in a single call. Unfortunately this class is not visible for this jteg test. To compile it properly, I would need to include the following annotations in the test:
>> 
>>  * @modules java.base/sun.security.tools.keytool
>>  *          java.base/sun.security.util
>>  *          java.base/sun.security.x509
>>  * @compile ../../../../../../sun/security/tools/keytool/KeyToolTest.java
>> 
>>  But, this would couple both tests together. would it be useful extracting HumanInputStream into a common library class?
>
> Sure, you can put it into `test/jdk/java/security/testlibrary`. I'm not sure if it's mature enough to be put into `test/lib`.

Ok, it's moved now and updated the tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19790#discussion_r1657356010


From liach at openjdk.org  Thu Jun 27 16:10:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 16:10:13 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <IKh8aIpw-Oxj5Sg5J9RLk2thgvFtE3WG-RnX8VlukBI=.b9e2a627-4b25-466e-a6b9-8e4777efb7f2@github.com>

On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

src/java.base/share/classes/java/lang/StringConcatHelper.java line 157:

> 155:             }
> 156:             index -= prefix.length();
> 157:             prefix.getBytes(buf, index, String.LATIN1);

Since we are now passing in a lot of empty prefix, I wonder how this call is elided; is there some specific JIT intrinsic? The java code has no shortcut for `length == 0`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1657409710


From redestad at openjdk.org  Thu Jun 27 17:31:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 27 Jun 2024 17:31:44 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <IKh8aIpw-Oxj5Sg5J9RLk2thgvFtE3WG-RnX8VlukBI=.b9e2a627-4b25-466e-a6b9-8e4777efb7f2@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
 <IKh8aIpw-Oxj5Sg5J9RLk2thgvFtE3WG-RnX8VlukBI=.b9e2a627-4b25-466e-a6b9-8e4777efb7f2@github.com>
Message-ID: <962u_Z64emw2woyTXBL3pNKk7-qM9fluY6SqSnS5vfU=.b56c8e79-6d85-4b87-a6b4-7bf37c5fd891@github.com>

On Thu, 27 Jun 2024 16:05:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
>> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
>> 
>> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
>> 
>> 
>> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
>> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
>> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
>> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
>> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
>> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
>> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
>> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
>> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
>> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
>> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
>> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
>> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
>> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
>> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
>> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
>> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
>> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p...
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 157:
> 
>> 155:             }
>> 156:             index -= prefix.length();
>> 157:             prefix.getBytes(buf, index, String.LATIN1);
> 
> Since we are now passing in a lot of empty prefix, I wonder how this call is elided; is there some specific JIT intrinsic? The java code has no shortcut for `length == 0`.

Remember that the prefixes are all constants and bound into the MH at each call site, so one view is that this PR is mostly about tickling the code into something that just-so happens to be easier for the JIT to swallow

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1657513167


From duke at openjdk.org  Thu Jun 27 17:32:10 2024
From: duke at openjdk.org (duke)
Date: Thu, 27 Jun 2024 17:32:10 GMT
Subject: RFR: 8330842: Support AES CBC with Ciphertext Stealing (CTS) in
 SunPKCS11 [v10]
In-Reply-To: <YJO7mBJ883oHw8zDbWKbJZodOVf0-LThwd96TClwzlA=.1f080bc0-bfd1-4770-9c54-f1a1aa093d02@github.com>
References: <6IGSPGGIdOzJlZQRG1_gnGivfnfCrMTK4K5mQInB_Ys=.bd1845ff-b73a-447b-aa15-b34f8479a18d@github.com>
 <YJO7mBJ883oHw8zDbWKbJZodOVf0-LThwd96TClwzlA=.1f080bc0-bfd1-4770-9c54-f1a1aa093d02@github.com>
Message-ID: <dtM2mlSSOb_0R55OqGpSv-mPnFhDSB6ZMT4RU9qslCI=.e325f0f7-dbfd-4405-b1b6-b04fd69a8b76@github.com>

On Fri, 7 Jun 2024 19:25:45 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose an implementation to support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11, according to what has been specified in [JDK-8330843 CSR](https://bugs.openjdk.org/browse/JDK-8330843).
>> 
>> What follows are implementation notes that describe the most relevant aspects of the proposed change.
>> 
>> ### Buffering
>> 
>> A buffering mechanism was implemented so PKCS #?11 tokens only receive multipart input updates (`C_EncryptUpdate` or `C_DecryptUpdate`) in multiples of the block size. This mechanism protects against tokens ?such as NSS? that assume an update with data not multiple of the block size is final and do variant ordering between the last 2 blocks, returning an incorrect partial output and resetting state. For example, when encrypting, a token may receive an update with an input not multiple of the block size and prematurely finalize the operation returning the last two blocks of ciphertext according to its ordering. By buffering on the Java side, the token is not aware of the end of the stream during updates and SunPKCS11 retains full control to do the last two blocks at `C_EncryptFinal` or `C_DecryptFinal`. A bug in NSS (see [1823875](https://bugzilla.mozilla.org/show_bug.cgi?id=1823875#c2)) requires buffering three blocks instead of two. If this bug gets fixed, the three block b
 uffering will still work and allow it to support old versions of the NSS library.
>> 
>> ### `implUpdate` implementation
>> 
>> The code added to `P11Cipher::implUpdate` follows the existing three-stage strategy: 1) Process data in the `padBuffer`, 2) Process data in the input and 3) Buffer to `padBuffer`. Stage #?1 for CTS has some additional complexity that is worth describing in this section.
>> 
>> The stage begins by calculating the total data available (what is already buffered in `padBuffer` + the new input) and assigning this value to the variable `totalInLen`. `newPadBufferLen` is the number of bytes that must be buffered at the end of the update operation, irrespective of where they come from (`padBuffer` or input). This number of bytes is determined out of `totalInLen` and based on the fact that each operation must retain bytes from the last two ?or three, for NSS? blocks in `padBuffer`, or retain whatever is available if less than that. `dataForP11Update` is the number of bytes to be passed to the token during the operation (`C_EncryptUpdate` or `C_DecryptUpdate` calls), irrespective of the stage in which they are passed and of the dat...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test clarity and avoid code duplication
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

@franferrax 
Your change (at version 33a64b2c59a603343032696f632dd052f37ba4f9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2194417979


From liach at openjdk.org  Thu Jun 27 18:08:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 18:08:18 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <6Fvzdxc1DMGrfqk2ITKDDf1qOSrfh8x9UsoidlY3_9U=.d15ee23f-1f20-4858-b66c-3bec467fcb4d@github.com>

On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

Great cleanup! `StringConcatHelper` needs a copyright year bump.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19927#pullrequestreview-2146139871


From ascarpino at openjdk.org  Thu Jun 27 18:13:27 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Jun 2024 18:13:27 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS [v2]
In-Reply-To: <Lv8O1_KsFKvZqT2qaZUTYsdgIO7kgz-lqZipsWR53q4=.79c2bb7e-d11c-445e-8ac6-4cf942910bad@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <vrMZX6t4B-COLRVEhNM53fIyu9s91nCEe8WyjPBSpVY=.91615777-81f1-4c6e-b31d-4943011007b4@github.com>
 <Lv8O1_KsFKvZqT2qaZUTYsdgIO7kgz-lqZipsWR53q4=.79c2bb7e-d11c-445e-8ac6-4cf942910bad@github.com>
Message-ID: <ZomuzmZQuktW1Y4hxnUr1OVUUTg6LBRmp2qUIMeN8QQ=.7f190ca4-e24b-4537-aa09-bb4017671a63@github.com>

On Tue, 25 Jun 2024 09:38:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove frag issue
>>  - Comments, remove thread, set NST default to 1, allow 0
>>  - comment cleanup
>
> src/java.base/share/classes/sun/security/util/Cache.java line 716:
> 
>> 714:                 }
>> 715:                 if (entry.isValid(time)) {
>> 716:                     // SoftReference get() returns the same as entry.getValue()
> 
> this doesn't look right

I checked it through debugging.  I was a bit surprised myself that it didn't return the `QueueCacheEntry`.get().  I can switch it the below if that's agreeable.

                if (entry.isValid(time)) {
                    if (entry instanceof SoftCacheEntry<K,V> sce) {
                        return sce.get();
                    }
                    return entry.getValue();
                }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1657583824


From ascarpino at openjdk.org  Thu Jun 27 18:34:26 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Jun 2024 18:34:26 GMT
Subject: RFR: 8328608: Multiple NewSessionTicket support for TLS [v2]
In-Reply-To: <Lv8O1_KsFKvZqT2qaZUTYsdgIO7kgz-lqZipsWR53q4=.79c2bb7e-d11c-445e-8ac6-4cf942910bad@github.com>
References: <jqubHqPRI_jsHe_z2u0U-iVz8ElOqBxvht1MmhRXVog=.653d45b6-1ee0-4251-af10-c938c17697fb@github.com>
 <vrMZX6t4B-COLRVEhNM53fIyu9s91nCEe8WyjPBSpVY=.91615777-81f1-4c6e-b31d-4943011007b4@github.com>
 <Lv8O1_KsFKvZqT2qaZUTYsdgIO7kgz-lqZipsWR53q4=.79c2bb7e-d11c-445e-8ac6-4cf942910bad@github.com>
Message-ID: <h8Jbj2slfR6HbuMZJkXWpN3u-HfAZQjz8d7BxRTqYuA=.9fad8707-eb47-4054-b12c-c68d9ce0a055@github.com>

On Tue, 25 Jun 2024 09:14:12 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove frag issue
>>  - Comments, remove thread, set NST default to 1, allow 0
>>  - comment cleanup
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 93:
> 
>> 91:         if (server) {
>> 92:             sessionCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
>> 93:             sessionHostPortCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
> 
> preexisting, but I wonder if we could use nullCache here and in client's sessionCache

Let's deal with that outside of this RFE, but there are tests that use it and I'm pretty sure this has public API usage with SSLSessionContext.getSession(byte[])

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1657634183


From weijun at openjdk.org  Thu Jun 27 19:07:21 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Jun 2024 19:07:21 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test [v2]
In-Reply-To: <QMvSq6QYIuZ1hvCqH2Hah2zgMjvYBAmRtmaEMs0VGxI=.624a5b0e-18c6-4ba2-baf2-dc1cc7a70e62@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
 <QMvSq6QYIuZ1hvCqH2Hah2zgMjvYBAmRtmaEMs0VGxI=.624a5b0e-18c6-4ba2-baf2-dc1cc7a70e62@github.com>
Message-ID: <68rYq0sVpovESsE2IlzspSoYIrayaAdz-CD86d8-vGQ=.78611d88-dbc7-4d16-b686-844683561835@github.com>

On Thu, 27 Jun 2024 15:37:45 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
>> 
>> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HumanInputStream to test library for reusability

LGTM. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19790#pullrequestreview-2146292759


From valeriep at openjdk.org  Thu Jun 27 21:35:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 27 Jun 2024 21:35:24 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic [v2]
In-Reply-To: <m0sHCN9vhHd13BgPqpZRWC_5lKpRXvW0Tr9gdWvVVO0=.1dd0c77f-45a5-40e4-9df5-a418f546e6df@github.com>
References: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
 <GZRRKZ5JHtjvxstX44u_YqWemaYo9k5_5yt-C5iNOa4=.f2eedf91-fb94-4518-928e-f9fa8797980e@github.com>
 <YGa6VInoBmj3CgwM_EQq2PEZ5Hu9tZfjPFF9vIzaWts=.31710da2-3ee1-491e-9b91-734ccd20724e@github.com>
 <eK8Vzdmh4n9xbfD6GfkG3wezZjOTAQrciod37_pYkts=.fe26e333-be41-483a-bf9a-82f66be35f2c@github.com>
 <m0sHCN9vhHd13BgPqpZRWC_5lKpRXvW0Tr9gdWvVVO0=.1dd0c77f-45a5-40e4-9df5-a418f546e6df@github.com>
Message-ID: <-7bUzCa6BvnahjOOmRD3WwbLw-Oif4hgulEz4BCA7Io=.d676e952-30e6-476f-86db-b9b86fd57da1@github.com>

On Fri, 14 Jun 2024 18:56:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> UP @valeriepeng possible to backport PKCS11 configuration attribute part on JDK 17 or 21 ?

Based  on the feedback that I got, it should be ok to backport the PKCS11 configuration attribute, separate CSRs would be needed for that though.

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

PR Comment: https://git.openjdk.org/jdk/pull/18387#issuecomment-2195698362


From duke at openjdk.org  Fri Jun 28 08:30:20 2024
From: duke at openjdk.org (duke)
Date: Fri, 28 Jun 2024 08:30:20 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test [v2]
In-Reply-To: <QMvSq6QYIuZ1hvCqH2Hah2zgMjvYBAmRtmaEMs0VGxI=.624a5b0e-18c6-4ba2-baf2-dc1cc7a70e62@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
 <QMvSq6QYIuZ1hvCqH2Hah2zgMjvYBAmRtmaEMs0VGxI=.624a5b0e-18c6-4ba2-baf2-dc1cc7a70e62@github.com>
Message-ID: <2MDsX4TSTskGBqvEwTYzRoxBrK9-XhXHYw0n5mLfLnY=.b3a103bd-7a01-4f6b-ad09-bd7ba6421e52@github.com>

On Thu, 27 Jun 2024 15:37:45 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
>> 
>> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HumanInputStream to test library for reusability

@fguallini 
Your change (at version d9dbdfa3fe2a6038b31652a2a83bdad21492a0fb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19790#issuecomment-2196400260


From redestad at openjdk.org  Fri Jun 28 12:39:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jun 2024 12:39:32 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
 [v2]
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <n98Cj23KDJZUG9OWCc3JbEbRj3VhvGLoQxfojNQC8BQ=.22769ff5-2d7d-4a7f-a274-deece1bc00fb@github.com>

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

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

  Copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19927/files
  - new: https://git.openjdk.org/jdk/pull/19927/files/6525e945..7c50d7dd

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

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

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


From fguallini at openjdk.org  Fri Jun 28 12:48:25 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 28 Jun 2024 12:48:25 GMT
Subject: Integrated: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
Message-ID: <zgpfoaObIKhE4d3YXtcbkPLb6m3_8sQFbIe9sSJ7g5M=.faea4ecc-5b8d-4d95-b488-fde6dbbabb57@github.com>

On Wed, 19 Jun 2024 12:47:33 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
> 
> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

This pull request has now been integrated.

Changeset: f4d8c005
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4d8c005b35ce34c96027b7f3abb7a307bca3f4c
Stats:     401 lines in 5 files changed: 210 ins; 170 del; 21 mod

8334562: Automate com/sun/security/auth/callback/TextCallbackHandler/Default.java test

Reviewed-by: weijun

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

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


From weijun at openjdk.org  Fri Jun 28 13:10:18 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Jun 2024 13:10:18 GMT
Subject: RFR: 8331163: Consider Trust Settings to select SSL certificate
In-Reply-To: <7m6ubMm0sz1f7mIcLvg-PpV7Qr5ZF0jc9DjYcNZ_kWo=.c4e0b9b3-cbfc-4655-be29-eb6f4bc85216@github.com>
References: <7m6ubMm0sz1f7mIcLvg-PpV7Qr5ZF0jc9DjYcNZ_kWo=.c4e0b9b3-cbfc-4655-be29-eb6f4bc85216@github.com>
Message-ID: <SE2Y2ocDn7h9HgkPMtWfJ_hXdiiL7NfUwg5GP5Jq2Gg=.12ef1787-07c5-4926-9ca5-e3f5daffe0af@github.com>

On Tue, 25 Jun 2024 01:14:05 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a proposal to verify Trust Settings for Keychain key entries.
> 
> Keychain-related Jtreg tests passed.

Hi Alexey, sorry I'll be on vacation starting tomorrow and won't be able to review this in 3 weeks. At the mean time, can you try to create a test? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19872#issuecomment-2196867926


From kdriver at openjdk.org  Fri Jun 28 15:07:06 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Jun 2024 15:07:06 GMT
Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API
 (Preview) [v81]
In-Reply-To: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
References: <wGvUsPOGugy8mEjX774X4rkGnSvrBRrNBPqexhxiMa4=.aefb114e-9ef2-44cd-b6f8-fd19088065fd@github.com>
Message-ID: <kn4zGpArqD3FfNCdgSGrKuTEuev4z4aRG10C3HpjLyI=.4e46522c-36dd-4e07-ae24-96ec1b2c5c5c@github.com>

> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478).

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:

 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge remote-tracking branch 'origin/master' into kdf-jep-wip
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - javadoc formatting
 - javadoc formatting
 - remove unused declared exception in impls
 - throw a ProviderException instead of "eating" an NSAE for Mac
 - fix edge-case in consolidateKeyMaterial
 - change thrown exception in engineDeriveKey in impl code
 - ... and 91 more: https://git.openjdk.org/jdk/compare/486aa11e...443265eb

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

Changes: https://git.openjdk.org/jdk/pull/18924/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18924&range=80
  Stats: 2246 lines in 14 files changed: 2245 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18924/head:pull/18924

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


From fguallini at openjdk.org  Fri Jun 28 16:24:25 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 28 Jun 2024 16:24:25 GMT
Subject: RFR: 8335344: test/jdk/sun/security/tools/keytool/NssTest.java fails
 to compile
Message-ID: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>

There is a compilation issue in the test **test/jdk/sun/security/tools/keytool/NssTest.java** because the [HumanInputStream](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/testlibrary/HumanInputStream.java) class was moved from keytool/KeyToolTest.java to a library class in this [PR](https://github.com/openjdk/jdk/pull/19790) for reusability. NssTest is coupled with KeyToolTest.java, therefore it will also need to import HumanInputStream from the test library.

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

Commit messages:
 - add testlibrary to avoid compilation issue

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

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


From fguallini at openjdk.org  Fri Jun 28 16:41:00 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 28 Jun 2024 16:41:00 GMT
Subject: RFR: 8335344: test/jdk/sun/security/tools/keytool/NssTest.java
 fails to compile [v2]
In-Reply-To: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
References: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
Message-ID: <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>

> There is a compilation issue in the test **test/jdk/sun/security/tools/keytool/NssTest.java** because the [HumanInputStream](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/testlibrary/HumanInputStream.java) class was moved from keytool/KeyToolTest.java to a library class in this [PR](https://github.com/openjdk/jdk/pull/19790) for reusability. NssTest depends on KeyToolTest.java, therefore it will also need to import HumanInputStream from the test library.

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

  copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19946/files
  - new: https://git.openjdk.org/jdk/pull/19946/files/76545dbb..81522328

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

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

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


From weijun at openjdk.org  Fri Jun 28 16:41:00 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Jun 2024 16:41:00 GMT
Subject: RFR: 8335344: test/jdk/sun/security/tools/keytool/NssTest.java
 fails to compile [v2]
In-Reply-To: <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>
References: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
 <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>
Message-ID: <29T_VK-LVTMQjHMtXzaH-t2jx5lTXGtIgvqrF9hIkSE=.bcfa7f81-4250-42bf-8176-ac57a1d3abef@github.com>

On Fri, 28 Jun 2024 16:37:02 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> There is a compilation issue in the test **test/jdk/sun/security/tools/keytool/NssTest.java** because the [HumanInputStream](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/testlibrary/HumanInputStream.java) class was moved from keytool/KeyToolTest.java to a library class in this [PR](https://github.com/openjdk/jdk/pull/19790) for reusability. NssTest depends on KeyToolTest.java, therefore it will also need to import HumanInputStream from the test library.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

LGTM. You can also update the copyright year.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19946#pullrequestreview-2148457825


From weijun at openjdk.org  Fri Jun 28 16:42:20 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Jun 2024 16:42:20 GMT
Subject: RFR: 8335344: test/jdk/sun/security/tools/keytool/NssTest.java
 fails to compile [v2]
In-Reply-To: <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>
References: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
 <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>
Message-ID: <DDhWp4QnICjYFicMOeVw6Mp3oOdKnLI-Jz5_W05D8yY=.f0d79288-e587-43c5-a160-17c755501db5@github.com>

On Fri, 28 Jun 2024 16:41:00 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> There is a compilation issue in the test **test/jdk/sun/security/tools/keytool/NssTest.java** because the [HumanInputStream](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/testlibrary/HumanInputStream.java) class was moved from keytool/KeyToolTest.java to a library class in this [PR](https://github.com/openjdk/jdk/pull/19790) for reusability. NssTest depends on KeyToolTest.java, therefore it will also need to import HumanInputStream from the test library.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Perfect.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19946#pullrequestreview-2148466584


From abakhtin at openjdk.org  Fri Jun 28 17:43:19 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 28 Jun 2024 17:43:19 GMT
Subject: RFR: 8331163: Consider Trust Settings to select SSL certificate
In-Reply-To: <SE2Y2ocDn7h9HgkPMtWfJ_hXdiiL7NfUwg5GP5Jq2Gg=.12ef1787-07c5-4926-9ca5-e3f5daffe0af@github.com>
References: <7m6ubMm0sz1f7mIcLvg-PpV7Qr5ZF0jc9DjYcNZ_kWo=.c4e0b9b3-cbfc-4655-be29-eb6f4bc85216@github.com>
 <SE2Y2ocDn7h9HgkPMtWfJ_hXdiiL7NfUwg5GP5Jq2Gg=.12ef1787-07c5-4926-9ca5-e3f5daffe0af@github.com>
Message-ID: <rNiK4E8mB6oZc5UeniA0_vqIVIdFHZWuuu4-A6KyEGE=.88aac9f7-d76f-4513-aa64-d8992662a7ad@github.com>

On Fri, 28 Jun 2024 13:07:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Hi Alexey, sorry I'll be on vacation starting tomorrow and won't be able to review this in 3 weeks. At the mean time, can you try to create a test? Thanks.

Thank you. Will try.

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

PR Comment: https://git.openjdk.org/jdk/pull/19872#issuecomment-2197383712


From duke at openjdk.org  Fri Jun 28 19:00:18 2024
From: duke at openjdk.org (duke)
Date: Fri, 28 Jun 2024 19:00:18 GMT
Subject: RFR: 8335344: test/jdk/sun/security/tools/keytool/NssTest.java
 fails to compile [v2]
In-Reply-To: <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>
References: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
 <3zAk737CEQjTAYC3cq-64mC2v5sTkdX3PAPASfX8Of8=.d925a51f-3583-45d8-88e6-5e5d55ca18ff@github.com>
Message-ID: <gC1sRf84pMMjRa9GoyFMCGvG3ZNgpYrhjFkK67dGvDc=.e952742e-b896-4375-846d-da4db9ad1492@github.com>

On Fri, 28 Jun 2024 16:41:00 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> There is a compilation issue in the test **test/jdk/sun/security/tools/keytool/NssTest.java** because the [HumanInputStream](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/testlibrary/HumanInputStream.java) class was moved from keytool/KeyToolTest.java to a library class in this [PR](https://github.com/openjdk/jdk/pull/19790) for reusability. NssTest depends on KeyToolTest.java, therefore it will also need to import HumanInputStream from the test library.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

@fguallini 
Your change (at version 81522328020c320cd7ae1d5730144ff557c50d4e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19946#issuecomment-2197468093


From fguallini at openjdk.org  Fri Jun 28 19:20:25 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 28 Jun 2024 19:20:25 GMT
Subject: Integrated: 8335344: test/jdk/sun/security/tools/keytool/NssTest.java
 fails to compile
In-Reply-To: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
References: <wiohHixYiayS_kbJnrtC_8SndoT2BLDKPaZPOS2GIdA=.27f73793-c864-4483-aa6c-2911c5f5ef3b@github.com>
Message-ID: <CJ_X_rSDOu4UT77YLP38aKpeqHsa6ht0CSTWf2-HlZo=.0314f85a-edd0-47ff-b23b-ac4a6c817a96@github.com>

On Fri, 28 Jun 2024 16:11:02 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> There is a compilation issue in the test **test/jdk/sun/security/tools/keytool/NssTest.java** because the [HumanInputStream](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/testlibrary/HumanInputStream.java) class was moved from keytool/KeyToolTest.java to a library class in this [PR](https://github.com/openjdk/jdk/pull/19790) for reusability. NssTest depends on KeyToolTest.java, therefore it will also need to import HumanInputStream from the test library.

This pull request has now been integrated.

Changeset: 3e23e9c5
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e23e9c535e0ed1d7517a836d4703c7fb3e917e4
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8335344: test/jdk/sun/security/tools/keytool/NssTest.java fails to compile

Reviewed-by: weijun

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

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


From duke at openjdk.org  Sat Jun 29 05:22:28 2024
From: duke at openjdk.org (duke)
Date: Sat, 29 Jun 2024 05:22:28 GMT
Subject: Withdrawn: 8319332: Security properties files inclusion
In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
Message-ID: <zQsw2m8XuWoYVv5lS18m0YSQgbICVvDiZDk88LGFDW8=.12822659-febf-4ccd-b6ce-e8cff231ae73@github.com>

On Thu, 2 Nov 2023 19:07:48 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
> 
> ## Security properties loading (overview)
> 
> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
> 
> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
> 
> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
> 
> ## Loading security properties from paths (`loadFromPath` method)
> 
> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
> 
> ## Loading security properties from URLs (`loadFromUrl` method)
> 
> The extra properties file can be loaded from a URL. ...

This pull request has been closed without being integrated.

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

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


From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into zipentry-external-attributes
 - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
 - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
 - For clarity, use "externalFileAttributes" instead of "externalAttributes"
 - Merge branch 'master' into zipentry-external-attributes
 - Update copyright years for 2024
 - Merge branch 'master' into zipentry-external-attributes
 - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

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

Changes: https://git.openjdk.org/jdk/pull/16952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=04
  Stats: 56 lines in 12 files changed: 0 ins; 4 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/16952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952

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


From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
 <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>
Message-ID: <gKjp0nyzMBkSSTPjb8AFIw1FbpHVyJmwn-25t4eOGxA=.c95e9ca2-45c8-4b36-95cb-403827f7f5b9@github.com>

On Sun, 12 May 2024 14:37:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> I believe this field only captures the 2 bytes at higher indices of External File Attribute; it's not the complete 4-byte external file attributes and this value is not captured unless "Version made by" field's larger index byte (byte 5) is 3. So this name may still be imperfect.

The purpose of this PR was mainly to reduce the risk of confusion with the "extra field", which is an entirely unrelated concept.

While I agree that the name `externalFileAttributes` might not express the full semantics of the field perfectly, I'm honestly not sure which name would, given that `APPNOTE.TXT` is pretty opaque in describing what these two bytes express, and as you point out, the field only carries data when "Version Made By" indicates Unix.

Instead of trying to find name which covers the full semantics, I suggest that we keep `externalFileAttributes` and instead seek to improve the comments relevant to this field:

* The field comment currently says `// File type, setuid, setgid, sticky, POSIX permissions`, we could prepend something clarifying that the field only carries data for Unix entries.
* Line 699 says `// read all bits in this field, including sym link attributes`, this could be improved to clarify that only the higher two "unix-bytes" are read ("all bits in this field" is a bit unclear now)
* Line 700 masks off the Unix bytes with `0xFFFF`, this isn't strictly necessary since `CENATX_PERMS` already only reads the two bytes we want. Perhaps clearer just to drop this masking.
* `ZipUtils.CENATX_PERMS` reads the full 16 bits of the Unix external file attributes, not just the permissions. The current name is confusing.

Since I don't want to delay the integration of the this PR any further, I suggest we tackle the above clarifications in a follow-up PR. Would that be ok with you, @liach ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198283812


From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
 <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>
Message-ID: <J7HUrQoDGQzfTPObFhpkvw4GcDJ9PGXwvRQ6gj79Bx4=.69c20e3b-1d15-403d-8ed6-303116691a24@github.com>

On Thu, 9 May 2024 12:00:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Eirik, it will be better to merge with the latest master branch and run the tier tests before integrating.

Life happened, but I have now merged with the latest master and GHA runs green.

Did you want to run additional testing before integration @jaikiran ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198284302


From jpai at openjdk.org  Sun Jun 30 04:51:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 30 Jun 2024 04:51:31 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
Message-ID: <A1CrpCUTWpIWJYwh0OPZHZAvHkkyuOm9WIga5jl2tRs=.c23b1d13-e7f5-4b41-a392-feceae50606e@github.com>

On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
>  - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
>  - For clarity, use "externalFileAttributes" instead of "externalAttributes"
>  - Merge branch 'master' into zipentry-external-attributes
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

Hello Eirik, I'll run some tests and review this PR this coming week.

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198432408