From kdriver at openjdk.org  Wed Nov  1 05:04:04 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 1 Nov 2023 05:04:04 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v10]
In-Reply-To: <48P6KXIy_I7APATEpCYhYcKMuQk8cYu4RtRK_d-ch3w=.c5aad70e-3007-466c-ae48-64a701f71c2b@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <NSAg9RLa5Gmhdh-quk5G-z5N6R0eGXuYCFaoNHIy6c4=.d698403a-9b24-4394-86b1-a65ab1537c61@github.com>
 <48P6KXIy_I7APATEpCYhYcKMuQk8cYu4RtRK_d-ch3w=.c5aad70e-3007-466c-ae48-64a701f71c2b@github.com>
Message-ID: <mKf_eyu_og2Yu37IYdHZJaIlsRYvLuSobJguMK1rmW8=.97290a17-a7aa-4e26-82af-ff86fcf2ad63@github.com>

On Tue, 31 Oct 2023 20:36:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix indenting and wildcard imports
>
> test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java line 442:
> 
>> 440:         TrustManagerFactory tmf;
>> 441: 
>> 442:         try (FileInputStream fsIn = new FileInputStream(tsPath)) {
> 
> No need for this `FileInputStream`.

I left this due to the "try." I can remove if you prefer, but it seemed like it was better to leave in this check for the existence of the file due to the declared exception in the method signature.

> test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java line 466:
> 
>> 464:         KeyManagerFactory kmf;
>> 465: 
>> 466:         try (FileInputStream fsIn = new FileInputStream(ksPath)) {
> 
> No need for this `FileInputStream`.

I left this due to the "try." I can remove if you prefer, but it seemed like it was better to leave in this check for the existence of the file due to the declared exception in the method signature.

> test/jdk/javax/net/ssl/SSLSession/SessionCacheSizeTests.java line 319:
> 
>> 317:         KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>> 318:         KeyStore ks;
>> 319:         try (FileInputStream fis = new FileInputStream(keyFilename)) {
> 
> No need for this `FileInputStream`.

I left this due to the "try." I can remove if you prefer, but it seemed like it was better to leave in this check for the existence of the file due to the declared exception in the method signature.

> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 182:
> 
>> 180: 
>> 181:         try (FileInputStream keyFile = new FileInputStream(keyFilename);
>> 182:                 FileInputStream trustFile = new FileInputStream(trustFilename)) {
> 
> No need for these `FileInputStream`s.

I left this due to the "try." I can remove if you prefer, but it seemed like it was better to leave in this check for the existence of the file due to the declared exception in the method signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378395112
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378395163
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378395198
PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378395236


From xuelei at openjdk.org  Wed Nov  1 07:38:13 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 1 Nov 2023 07:38:13 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
Message-ID: <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>

On Mon, 30 Oct 2023 21:53:44 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> I agree that wording is more clear. We should also update the RN with that wording.
>
> This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!
> 
>         /*
>          * If either jdk.tls.server.maxInboundCertificateChainLength or
>          * jdk.tls.client.maxInboundCertificateChainLength is set, it will
>          * override jdk.tls.maxCertificateChainLength, regardless of whether
>          * jdk.tls.maxCertificateChainLength is set or not.
>          * If neither jdk.tls.server.maxInboundCertificateChainLength nor
>          * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior
>          * depends on the setting of jdk.tls.maxCertificateChainLength. If
>          * jdk.tls.maxCertificateChainLength is set, it falls back to that
>          * value; otherwise, it defaults to 8 for
>          * jdk.tls.server.maxInboundCertificateChainLength
>          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
>          * Usesrs can independently set either
>          * jdk.tls.server.maxInboundCertificateChainLength or
>          * jdk.tls.client.maxInboundCertificateChainLength.
>          */

Sorry, I did not get time to review this behavior update.

> This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!
> 
> ```
>         /*
>          * If either jdk.tls.server.maxInboundCertificateChainLength or
>          * jdk.tls.client.maxInboundCertificateChainLength is set, it will
>          * override jdk.tls.maxCertificateChainLength, regardless of whether
>          * jdk.tls.maxCertificateChainLength is set or not.
I'm not sure the statement is clear enough.  I think there are two points that need to clarify.  The 1st one is that there is a default value of  jdk.tls.maxCertificateChainLength, which is 10.  The 2nd one is that  jdk.tls.maxCertificateChainLength works for both client and server mode.  jdk.tls.server.maxInboundCertificateChainLength works on server mode, and it does not work for client mode, and therefore it cannot override client mode behavior for jdk.tls.maxCertificateChainLength.  The same for jdk.tls.client.maxInboundCertificateChainLength.

To be clear, the release note or the comment might be placed in different code block like:


/* If jdk.tls.server.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for server side.
 */

Integer inboundClientLen = ...

/* If jdk.tls.client.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for client side.
 */
 Integer inboundServerLen = GetIntegerAction.privilegedGetProperty(



>          * If neither jdk.tls.server.maxInboundCertificateChainLength nor
>          * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior
>          * depends on the setting of jdk.tls.maxCertificateChainLength. If
>          * jdk.tls.maxCertificateChainLength is set, it falls back to that
>          * value; otherwise, it defaults to 8 for
>          * jdk.tls.server.maxInboundCertificateChainLength

Previously, the jdk.tls.maxCertificateChainLength default value is 10.  Now it is changed to 8.  This is a behavior change, please document it in release note, or just use 10 in the implementation.


>          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
>          * Usesrs can independently set either
>          * jdk.tls.server.maxInboundCertificateChainLength or
>          * jdk.tls.client.maxInboundCertificateChainLength.
>          */ 
> ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1378477689


From weijun at openjdk.org  Wed Nov  1 13:38:07 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Nov 2023 13:38:07 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v10]
In-Reply-To: <mKf_eyu_og2Yu37IYdHZJaIlsRYvLuSobJguMK1rmW8=.97290a17-a7aa-4e26-82af-ff86fcf2ad63@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <NSAg9RLa5Gmhdh-quk5G-z5N6R0eGXuYCFaoNHIy6c4=.d698403a-9b24-4394-86b1-a65ab1537c61@github.com>
 <48P6KXIy_I7APATEpCYhYcKMuQk8cYu4RtRK_d-ch3w=.c5aad70e-3007-466c-ae48-64a701f71c2b@github.com>
 <mKf_eyu_og2Yu37IYdHZJaIlsRYvLuSobJguMK1rmW8=.97290a17-a7aa-4e26-82af-ff86fcf2ad63@github.com>
Message-ID: <01UN1qf2LwzfdKdr_rTbmoaHgXan5z_MOo4VA_3gWg8=.705650fd-cc17-4cc9-8241-71a726e6d938@github.com>

On Wed, 1 Nov 2023 05:01:18 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java line 466:
>> 
>>> 464:         KeyManagerFactory kmf;
>>> 465: 
>>> 466:         try (FileInputStream fsIn = new FileInputStream(ksPath)) {
>> 
>> No need for this `FileInputStream`.
>
> I left this due to the "try." I can remove if you prefer, but it seemed like it was better to leave in this check for the existence of the file due to the declared exception in the method signature.

I see what you mean, but in any of these tests, no matter if a FNFE or an IAE is thrown, it's not handled and the test simply fails. I don't think it's worth checking twice on the existence of the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16159#discussion_r1378811603


From mullan at openjdk.org  Wed Nov  1 13:41:17 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 1 Nov 2023 13:41:17 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
Message-ID: <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>

On Wed, 1 Nov 2023 07:35:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!
>> 
>>         /*
>>          * If either jdk.tls.server.maxInboundCertificateChainLength or
>>          * jdk.tls.client.maxInboundCertificateChainLength is set, it will
>>          * override jdk.tls.maxCertificateChainLength, regardless of whether
>>          * jdk.tls.maxCertificateChainLength is set or not.
>>          * If neither jdk.tls.server.maxInboundCertificateChainLength nor
>>          * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior
>>          * depends on the setting of jdk.tls.maxCertificateChainLength. If
>>          * jdk.tls.maxCertificateChainLength is set, it falls back to that
>>          * value; otherwise, it defaults to 8 for
>>          * jdk.tls.server.maxInboundCertificateChainLength
>>          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
>>          * Usesrs can independently set either
>>          * jdk.tls.server.maxInboundCertificateChainLength or
>>          * jdk.tls.client.maxInboundCertificateChainLength.
>>          */
>
> Sorry, I did not get time to review this behavior update.
> 
>> This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!
>> 
>> ```
>>         /*
>>          * If either jdk.tls.server.maxInboundCertificateChainLength or
>>          * jdk.tls.client.maxInboundCertificateChainLength is set, it will
>>          * override jdk.tls.maxCertificateChainLength, regardless of whether
>>          * jdk.tls.maxCertificateChainLength is set or not.
> I'm not sure the statement is clear enough.  I think there are two points that need to clarify.  The 1st one is that there is a default value of  jdk.tls.maxCertificateChainLength, which is 10.  The 2nd one is that  jdk.tls.maxCertificateChainLength works for both client and server mode.  jdk.tls.server.maxInboundCertificateChainLength works on server mode, and it does not work for client mode, and therefore it cannot override client mode behavior for jdk.tls.maxCertificateChainLength.  The same for jdk.tls.client.maxInboundCertificateChainLength.
> 
> To be clear, the release note or the comment might be placed in different code block like:
> 
> 
> /* If jdk.tls.server.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for server side.
>  */
> 
> Integer inboundClientLen = ...
> 
> /* If jdk.tls.client.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for client side.
>  */
>  Integer inboundServerLen = GetIntegerAction.privilegedGetProperty(
> 
> 
> 
>>          * If neither jdk.tls.server.maxInboundCertificateChainLength nor
>>          * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior
>>          * depends on the setting of jdk.tls.maxCertificateChainLength. If
>>          * jdk.tls.maxCertificateChainLength is set, it falls back to that
>>          * value; otherwise, it defaults to 8 for
>>          * jdk.tls.server.maxInboundCertificateChainLength
> 
> Previously, the jdk.tls.maxCertificateChainLength default value is 10.  Now it is changed to 8.  This is a behavior change, please document it in release note, or just use 10 in the implementation.
> 
> 
>>          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
>>          * Usesrs can independently set either
>>          * jdk.tls.server.maxInboundCertificateChainLength or
>>          * jdk.tls.client.maxInboundCertificateChainLength.
>>          */ 
>> ```

I don't see a behavior change that conflicts with the CSR. I think it is a wording issue, let me suggest some improvements in another comment. There is no longer a default value for `jdk.tls.maxCertificateChainLength`. Where is it set to 8 in the code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1378814738


From weijun at openjdk.org  Wed Nov  1 14:01:20 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Nov 2023 14:01:20 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
Message-ID: <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>

On Wed, 1 Nov 2023 13:38:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sorry, I did not get time to review this behavior update.
>> 
>>> This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!
>>> 
>>> ```
>>>         /*
>>>          * If either jdk.tls.server.maxInboundCertificateChainLength or
>>>          * jdk.tls.client.maxInboundCertificateChainLength is set, it will
>>>          * override jdk.tls.maxCertificateChainLength, regardless of whether
>>>          * jdk.tls.maxCertificateChainLength is set or not.
>> I'm not sure the statement is clear enough.  I think there are two points that need to clarify.  The 1st one is that there is a default value of  jdk.tls.maxCertificateChainLength, which is 10.  The 2nd one is that  jdk.tls.maxCertificateChainLength works for both client and server mode.  jdk.tls.server.maxInboundCertificateChainLength works on server mode, and it does not work for client mode, and therefore it cannot override client mode behavior for jdk.tls.maxCertificateChainLength.  The same for jdk.tls.client.maxInboundCertificateChainLength.
>> 
>> To be clear, the release note or the comment might be placed in different code block like:
>> 
>> 
>> /* If jdk.tls.server.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for server side.
>>  */
>> 
>> Integer inboundClientLen = ...
>> 
>> /* If jdk.tls.client.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for client side.
>>  */
>>  Integer inboundServerLen = GetIntegerAction.privilegedGetProperty(
>> 
>> 
>> 
>>>          * If neither jdk.tls.server.maxInboundCertificateChainLength nor
>>>          * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior
>>>          * depends on the setting of jdk.tls.maxCertificateChainLength. If
>>>          * jdk.tls.maxCertificateChainLength is set, it falls back to that
>>>          * value; otherwise, it defaults to 8 for
>>>          * jdk.tls.server.maxInboundCertificateChainLength
>> 
>> Previously, the jdk.tls.maxCertificateChainLength default value is 10.  Now it is changed to 8.  This is a behavior change, please document it in release note, or just use 10 in the implementation.
>> 
>> 
>>>          * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
>>>          * Usesrs can independently set either
>>>          * jdk.tls.server.maxInboundCertificateChainLength or
>>>          * jdk.tls.client.maxInboundCertificateChainLength.
>>>        ...
>
> I don't see a behavior change that conflicts with the CSR. I think it is a wording issue, let me suggest some improvements in another comment. There is no longer a default value for `jdk.tls.maxCertificateChainLength`. Where is it set to 8 in the code?

When no system property is set, previously max inbound length is 10, now it's 8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1378838176


From weijun at openjdk.org  Wed Nov  1 14:11:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Nov 2023 14:11:36 GMT
Subject: RFR: 8319213: Compatibility.java reads both stdout and stderr of
 JdkUtils
Message-ID: <r8IyeACdxxA3b8pJgvYemuyKDZSksIkst_dy6XWqLa8=.887318b2-a9bf-4e65-8c87-737d8d3dd4e8@github.com>

There might be more warnings from the java launcher. Better ignore them now.

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

Commit messages:
 - the fix

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

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


From mullan at openjdk.org  Wed Nov  1 14:16:16 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 1 Nov 2023 14:16:16 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
Message-ID: <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>

On Wed, 1 Nov 2023 13:58:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't see a behavior change that conflicts with the CSR. I think it is a wording issue, let me suggest some improvements in another comment. There is no longer a default value for `jdk.tls.maxCertificateChainLength`. Where is it set to 8 in the code?
>
> When no system property is set, previously max inbound length is 10, now it's 8.

I think the wording of the comment is somewhat confusing because it is trying to explain the behavior of both properties together and the words "either" and "neither" may be hard to parse. I recommend separate comment blocks for each property. Here is a suggestion for the server side setting:


/* 
 * maxInboundClientCertChainLen is the maximum length of a client certificate
 * chain accepted by a server. It is determined as follows:
 *  - If the jdk.tls.server.maxInboundCertificateChainLength system property
 *    is set and its value >= 0, it uses that value.
 *  - Otherwise, if the jdk.tls.maxCertificateChainLength system property is
 *    set and its value >= 0, it uses that value.
 *  - Otherwise it is set to a default value of 8.
 */


The client side setting would be similar.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1378856511


From rhalade at openjdk.org  Wed Nov  1 16:18:52 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 1 Nov 2023 16:18:52 GMT
Subject: RFR: 8317374: Add Let's Encrypt ISRG Root X2
Message-ID: <oCqMVJjWP3iBOZp4XUUaX5nVYlPScRey42Xs6LKGHw8=.dde1e25b-d06a-4277-94e0-f9a08c6a5dad@github.com>

This PR is to add new TLS root certificates from Let's Encrypt. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.


The release-note is at [JDK-8318618](https://bugs.openjdk.org/browse/JDK-8318618)

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

Commit messages:
 - 8317374: Add Let's Encrypt ISRG Root X2

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

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


From duke at openjdk.org  Wed Nov  1 16:53:14 2023
From: duke at openjdk.org (Ben Perez)
Date: Wed, 1 Nov 2023 16:53:14 GMT
Subject: Integrated: 8311546: Certificate name constraints improperly validated
 with leading period
In-Reply-To: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
References: <Mti4tG_RpnuWPCdVr-QNp9A44XUl-5LC2DUY9zEaUSw=.f7e35bfc-2742-40bb-b796-4dfc03da5e99@github.com>
Message-ID: <cotCzAf-CK4ZAPoctEFWhjfLHI28mlOkzs_YKVrol5o=.56d1548c-34bd-4a1c-b91f-62b7ccdb3115@github.com>

On Fri, 20 Oct 2023 20:52:13 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated the `constrains` method in `DNSName.java` to accept certificates with a leading period.

This pull request has now been integrated.

Changeset: bfaf5704
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfaf5704e7e71f968b716b5f448860e9cda721b4
Stats:     309 lines in 8 files changed: 300 ins; 6 del; 3 mod

8311546: Certificate name constraints improperly validated with leading period

Reviewed-by: mullan

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

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


From jwaters at openjdk.org  Thu Nov  2 03:25:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 03:25:02 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
Message-ID: <vViv-G1z9MYGMyonPLut75PveXau9uHR-y5WFr9Vp9E=.dc96f555-7fa2-40df-8835-35e14b30835f@github.com>

On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use split declaration and assignment in sspi.cpp

Don't, I'm holding off from integrating until I can get AWT permissive- safe as well

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

PR Comment: https://git.openjdk.org/jdk/pull/15996#issuecomment-1790002686


From jwaters at openjdk.org  Thu Nov  2 10:56:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 10:56:14 GMT
Subject: RFR: 8317332: Prepare security for permissive- [v3]
In-Reply-To: <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
 <EQbDTOE1yGOLm6Js82fRgFm27dn6NJdsHeLDkFmmB6Q=.1e28e4b7-6515-4709-b714-2d0dae384530@github.com>
Message-ID: <oReQxr9IQvolF6T4M7TC_QzVqvJ7wYbHNpTa_MUDvsY=.26859cf7-5865-492b-9002-8a632d614ec8@github.com>

On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Prepares java.security.jgss for the permissive- compiler switch by
>> 
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use split declaration and assignment in sspi.cpp

Nevermind, looks like I have to integrate this now so I can test permissive- with AWT without this intefering

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

PR Comment: https://git.openjdk.org/jdk/pull/15996#issuecomment-1790500712


From jwaters at openjdk.org  Thu Nov  2 10:56:16 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 10:56:16 GMT
Subject: Integrated: 8317332: Prepare security for permissive-
In-Reply-To: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
References: <QGta-Ufa9ZLCWZCw_FSLyP85qhOI_vV2f68YNI0_lU4=.490f7f4e-9224-4582-961a-b5bba350c584@github.com>
Message-ID: <lT-TgrYje_tANxf6bKkOBOIJuY3qq3z1Ucnw7q6kfqU=.b7a6a371-1315-4641-94b9-c3cc715b8bdd@github.com>

On Sat, 30 Sep 2023 06:26:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Prepares java.security.jgss for the permissive- compiler switch by
> 
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static

This pull request has now been integrated.

Changeset: 64f8253b
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64f8253b7d9d382b18003c647a3941733f191329
Stats:     11 lines in 2 files changed: 6 ins; 0 del; 5 mod

8317332: Prepare security for permissive-

Reviewed-by: djelinski, weijun, valeriep

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

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


From mullan at openjdk.org  Thu Nov  2 12:43:00 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Nov 2023 12:43:00 GMT
Subject: RFR: 8317374: Add Let's Encrypt ISRG Root X2
In-Reply-To: <oCqMVJjWP3iBOZp4XUUaX5nVYlPScRey42Xs6LKGHw8=.dde1e25b-d06a-4277-94e0-f9a08c6a5dad@github.com>
References: <oCqMVJjWP3iBOZp4XUUaX5nVYlPScRey42Xs6LKGHw8=.dde1e25b-d06a-4277-94e0-f9a08c6a5dad@github.com>
Message-ID: <CHeIQ6VkmfVPdlBHnHlmPkrXMn0v1outIXGoGOLf78g=.c3833b7d-634d-450c-a77f-10f2ffc6c1fb@github.com>

On Wed, 1 Nov 2023 16:10:23 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add new TLS root certificates from Let's Encrypt. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8318618](https://bugs.openjdk.org/browse/JDK-8318618)

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16455#pullrequestreview-1710144171


From rhalade at openjdk.org  Thu Nov  2 16:41:23 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 2 Nov 2023 16:41:23 GMT
Subject: Integrated: 8317374: Add Let's Encrypt ISRG Root X2
In-Reply-To: <oCqMVJjWP3iBOZp4XUUaX5nVYlPScRey42Xs6LKGHw8=.dde1e25b-d06a-4277-94e0-f9a08c6a5dad@github.com>
References: <oCqMVJjWP3iBOZp4XUUaX5nVYlPScRey42Xs6LKGHw8=.dde1e25b-d06a-4277-94e0-f9a08c6a5dad@github.com>
Message-ID: <Fno6oPFSOY-ubAhC0udtpblK1V31N67jIz4Uvm1qGmI=.d80d6e48-2e5b-44e3-bd23-09671f02f544@github.com>

On Wed, 1 Nov 2023 16:10:23 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add new TLS root certificates from Let's Encrypt. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8318618](https://bugs.openjdk.org/browse/JDK-8318618)

This pull request has now been integrated.

Changeset: e6f46a43
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6f46a43268808d0cbbb3bb93c73aa8e4cbfad83
Stats:     39 lines in 3 files changed: 35 ins; 0 del; 4 mod

8317374: Add Let's Encrypt ISRG Root X2

Reviewed-by: mullan

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

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


From rhalade at openjdk.org  Thu Nov  2 17:38:03 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 2 Nov 2023 17:38:03 GMT
Subject: RFR: 8319213: Compatibility.java reads both stdout and stderr of
 JdkUtils
In-Reply-To: <r8IyeACdxxA3b8pJgvYemuyKDZSksIkst_dy6XWqLa8=.887318b2-a9bf-4e65-8c87-737d8d3dd4e8@github.com>
References: <r8IyeACdxxA3b8pJgvYemuyKDZSksIkst_dy6XWqLa8=.887318b2-a9bf-4e65-8c87-737d8d3dd4e8@github.com>
Message-ID: <jEleFDgKhJAlun5dhILjos3_YLc7D3Ju1n-i7G1hkTk=.b6971660-8608-426f-8d85-e22a8e5bbb3b@github.com>

On Wed, 1 Nov 2023 14:03:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There might be more warnings from the java launcher. Better ignore them now.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16450#pullrequestreview-1710918172


From weijun at openjdk.org  Thu Nov  2 17:42:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Nov 2023 17:42:14 GMT
Subject: Integrated: 8319213: Compatibility.java reads both stdout and stderr
 of JdkUtils
In-Reply-To: <r8IyeACdxxA3b8pJgvYemuyKDZSksIkst_dy6XWqLa8=.887318b2-a9bf-4e65-8c87-737d8d3dd4e8@github.com>
References: <r8IyeACdxxA3b8pJgvYemuyKDZSksIkst_dy6XWqLa8=.887318b2-a9bf-4e65-8c87-737d8d3dd4e8@github.com>
Message-ID: <37pqg0d_sEyMeqDMwQicf9p4tIm2znmCKIX5_oPc4Ew=.5c2ea19a-b03a-4653-af09-1acfcc9ae4a2@github.com>

On Wed, 1 Nov 2023 14:03:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There might be more warnings from the java launcher. Better ignore them now.

This pull request has now been integrated.

Changeset: 84f4f747
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84f4f7477c4e1b7ecc4c7fead2ded21242efddd7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8319213: Compatibility.java reads both stdout and stderr of JdkUtils

Reviewed-by: rhalade

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

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


From kdriver at openjdk.org  Thu Nov  2 18:43:19 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 2 Nov 2023 18:43:19 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v11]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <hRmoAtnbC90CnrdpKS9o20URVz_STR41cUnQKB4T72c=.ccdeece0-34a1-4ae5-83c8-9050732e8643@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

  code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/a35fa4cf..59aaba72

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

  Stats: 23 lines in 3 files changed: 0 ins; 10 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16159/head:pull/16159

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


From fferrari at openjdk.org  Thu Nov  2 19:56:20 2023
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 2 Nov 2023 19:56:20 GMT
Subject: RFR: 8319332: Security properties files inclusion
Message-ID: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>

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. If the URL has a local path underneath, `loadFromPath` is preferred to do the job. Otherwise, the load starts without a base assigned to `currentPath`. The absence of a base implies that any relative path _include_ definition will fail. For example, the extra properties file loaded when passing `-Djava.security.properties=https://example.com/some/path/java.config` to the JVM cannot contain a relative _include_. However, this same file can contain an absolute _include_ which, in turn, can contain a relative one.

## Loading included files (`loadInclude` method)

In order to handle the new _include_ property according to the defined semantics, the `java.util.Properties` class was extended and the method `put` overwritten. When the property key is _include_, the method `loadInclude` is called and the entry is not added to the map.

The method `loadInclude` expands system properties in the _include_ property value and tries to interpret it as a path. If successful and the property value is a relative path, the current base (`currentPath`) is used for resolution to an absolute path. Once an absolute path is obtained, the aforementioned `loadFromPath` method is called to do the rest of the work. An error while handling an included file is considered fatal.

## System properties expansion

System properties between `${` and `}` characters in _include_ property values are expanded. If a property is not defined (e.g. its value is `null`), expansion is to an empty string. This expansion mode is called non-strict, and implemented in the method `expandNonStrict` of the `sun.security.util.PropertyExpander` class.

## Testing

 * An existing test (`ConfigFileTest.java`) was refactored and extended to cover file inclusion scenarios.
   * This test has been run on _Windows_ and _Linux_ platforms.

 * No regressions have been observed in the following test categories:
   * JDK tier-1
   * `test/jdk/java/security/Security`
   * `test/jdk/javax/net/ssl/compatibility`
   * Other tests using `java.security.properties`
     * `test/jdk/java/security/Provider/SecurityProviderModularTest.java`
     * `test/jdk/javax/crypto/CryptoPermissions/CryptoPolicyFallback.java`

This contribution is co-authored by Francisco Ferrari and Martin Balao.

---

[JDK-8319332]: https://bugs.openjdk.org/browse/JDK-8319332
[JDK-8319333]: https://bugs.openjdk.org/browse/JDK-8319333

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

Commit messages:
 - 8319332: Implement security properties 'include'
 - 8319332: Refactor security properties file test
 - 8319332: Refactor properties file loading code

Changes: https://git.openjdk.org/jdk/pull/16483/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16483&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319332
  Stats: 1126 lines in 7 files changed: 901 ins; 161 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/16483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483

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


From alanb at openjdk.org  Thu Nov  2 20:10:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Nov 2023 20:10:03 GMT
Subject: RFR: 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: <h8hqCxv1mLcScmJxQ6apwRIc2_yJiptM5La3OdpAdVI=.03a89c7f-8c81-45a1-adca-68d6b2e627c2@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. ...

src/java.base/share/classes/java/security/Security.java line 243:

> 241:             if (connection instanceof FileURLConnection fileConnection) {
> 242:                 // A local file URL can be interpreted as a Path
> 243:                 loadFromPath(fileConnection.getFile().toPath(), mode);

Ugh, shouldn't be direct lying using FileURLConnection here. Instead I think you should check if the url scheme is "file" (equalsIgnoreCase). If it is then use `Path.of(url.toURI())`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1380715579


From weijun at openjdk.org  Thu Nov  2 20:14:05 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Nov 2023 20:14:05 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v11]
In-Reply-To: <hRmoAtnbC90CnrdpKS9o20URVz_STR41cUnQKB4T72c=.ccdeece0-34a1-4ae5-83c8-9050732e8643@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
 <hRmoAtnbC90CnrdpKS9o20URVz_STR41cUnQKB4T72c=.ccdeece0-34a1-4ae5-83c8-9050732e8643@github.com>
Message-ID: <TYo8T4wCRxpmct6NhHJb0rYK8AJ6R1X-9N2XCBIapXw=.104d9f22-a9dd-47ee-8dc1-ae363fa24dea@github.com>

On Thu, 2 Nov 2023 18:43:19 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

Looks good to me.

BTW, have you considered making `truststore` a password-less pkcs12 file? Then there is no need to provide a password for it. You can create one with `-J-Dkeystore.pkcs12.certProtectionAlgorithm=NONE -J-Dkeystore.pkcs12.macAlgorithm=NONE` when calling the `keytool -importkeystore` command.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16159#pullrequestreview-1711150221


From mbalao at openjdk.org  Thu Nov  2 22:23:04 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 2 Nov 2023 22:23:04 GMT
Subject: RFR: 8319332: Security properties files inclusion
In-Reply-To: <h8hqCxv1mLcScmJxQ6apwRIc2_yJiptM5La3OdpAdVI=.03a89c7f-8c81-45a1-adca-68d6b2e627c2@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <h8hqCxv1mLcScmJxQ6apwRIc2_yJiptM5La3OdpAdVI=.03a89c7f-8c81-45a1-adca-68d6b2e627c2@github.com>
Message-ID: <mtXyNoN3_KlZGaaiEMeqy5VqoafkHd7wnstRWxXHeZw=.f176435b-788c-487a-9a0c-d2a073807c8b@github.com>

On Thu, 2 Nov 2023 20:07:28 GMT, Alan Bateman <alanb 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 properti...
>
> src/java.base/share/classes/java/security/Security.java line 243:
> 
>> 241:             if (connection instanceof FileURLConnection fileConnection) {
>> 242:                 // A local file URL can be interpreted as a Path
>> 243:                 loadFromPath(fileConnection.getFile().toPath(), mode);
> 
> Ugh, shouldn't be direct using FileURLConnection here. Instead I think you should check if the url scheme is "file" (equalsIgnoreCase). If it is then use `Path.of(url.toURI())`.

Checking for _file_ in the URL scheme is not conclusive evidence that there is a local file path behind. I'll give a couple of examples. In Unix/Linux platforms, an URL of the form `file://example.com/path/to/some/file.txt` is processed with a remote FTP request (see Unix `sun.net.www.protocol.file.Handler`). In Windows, file URLs may be interpreted as UNCs but, if not possible, there is an FTP fallback (see Windows `sun.net.www.protocol.file.Handler`). While checking the host name in the URL is possible, there are three types of drawbacks: 1) a DNS query during the Security class initialization process should be avoided, 2) looking for hardcoded host names such as _localhost_ might lead to false negatives (i.e. a host is considered remote when it is not), and 3) there will be platform-specific and duplicated logic to deal with UNC file URLs. In addition, OpenJDK supports ill-formed relative path file URLs such as `file:some/relative/path`. In these cases, there is not a host name bu
 t there is a local file path underneath (relative to the current working directory). We did not find normative elements in [RFC 8089](https://www.rfc-editor.org/rfc/rfc8089) for all previously described behaviors, that would have been helpful for a URL-based check. Misinterpreting a file URL as remote will unnecessarily block the possibility of relative path includes.

We think that `FileURLConnection` is the most accurate indicator of a local file path because it includes the decision logic that is specific to OpenJDK and varies depending on the platform.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1380842630


From alanb at openjdk.org  Fri Nov  3 05:46:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Nov 2023 05:46:01 GMT
Subject: RFR: 8319332: Security properties files inclusion
In-Reply-To: <mtXyNoN3_KlZGaaiEMeqy5VqoafkHd7wnstRWxXHeZw=.f176435b-788c-487a-9a0c-d2a073807c8b@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <h8hqCxv1mLcScmJxQ6apwRIc2_yJiptM5La3OdpAdVI=.03a89c7f-8c81-45a1-adca-68d6b2e627c2@github.com>
 <mtXyNoN3_KlZGaaiEMeqy5VqoafkHd7wnstRWxXHeZw=.f176435b-788c-487a-9a0c-d2a073807c8b@github.com>
Message-ID: <Vt-BcVFHDeSXp9EdE9ogwMf3WlOwcfZRFNoMvEb13z0=.20dc2094-e915-40e6-821d-10f7549f70b0@github.com>

On Thu, 2 Nov 2023 22:20:02 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 243:
>> 
>>> 241:             if (connection instanceof FileURLConnection fileConnection) {
>>> 242:                 // A local file URL can be interpreted as a Path
>>> 243:                 loadFromPath(fileConnection.getFile().toPath(), mode);
>> 
>> Ugh, shouldn't be direct using FileURLConnection here. Instead I think you should check if the url scheme is "file" (equalsIgnoreCase). If it is then use `Path.of(url.toURI())`.
>
> Checking for _file_ in the URL scheme is not conclusive evidence that there is a local file path behind. I'll give a couple of examples. In Unix/Linux platforms, an URL of the form `file://example.com/path/to/some/file.txt` is processed with a remote FTP request (see Unix `sun.net.www.protocol.file.Handler`). In Windows, file URLs may be interpreted as UNCs but, if not possible, there is an FTP fallback (see Windows `sun.net.www.protocol.file.Handler`). While checking the host name in the URL is possible, there are three types of drawbacks: 1) a DNS query during the Security class initialization process should be avoided, 2) looking for hardcoded host names such as _localhost_ might lead to false negatives (i.e. a host is considered remote when it is not), and 3) there will be platform-specific and duplicated logic to deal with UNC file URLs. In addition, OpenJDK supports ill-formed relative path file URLs such as `file:some/relative/path`. In these cases, there is not a host name 
 but there is a local file path underneath (relative to the current working directory). We did not find normative elements in [RFC 8089](https://www.rfc-editor.org/rfc/rfc8089) for all previously described behaviors, that would have been helpful for a URL-based check. Misinterpreting a file URL as remote will unnecessarily block the possibility of relative path includes.
> 
> We think that `FileURLConnection` is the most accurate indicator of a local file path because it includes the decision logic that is specific to OpenJDK and varies depending on the platform.

> Checking for file in the URL scheme is not conclusive evidence that there is a local file path behind. I'll give a couple of examples.

With NFS and other other remote file systems then you can never tell either. Some of us have been wanting the ftp fallback go away, it comes up every few years.

My concern is creating dependency on a protocol handler implementation, we should make sure that all other options are explored before going there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1381179403


From duke at openjdk.org  Fri Nov  3 18:35:11 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Fri, 3 Nov 2023 18:35:11 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related
 APIs
Message-ID: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>

The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
- Cache of JAR files in JarURLConnection class
- Cache of JAR/ZIP files in JarFile and ZipFile classes
- Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
- Directories and filenames with the same name considered to be the same in ZipFile class
- Possible issues when local and central headers conflict in ZipInputStream class

Related JBS report:
https://bugs.openjdk.org/browse/JDK-8319122

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

Commit messages:
 - document patch for JDK-8319122

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

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


From simonis at openjdk.org  Fri Nov  3 18:35:12 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 3 Nov 2023 18:35:12 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <4Qn3IP1g-qcRgpk0l-bPN1-MIaMf-Zct6Fzg1AvzPQQ=.6646b6c2-197e-4cdd-bc18-05beb1da004f@github.com>

On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

@robilad, Yakov Shafranovich is covered by Amazon's comany-wide OCA. Can you please approve his OCA status?

Thank you and best regards,
Volker

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

PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1785759972


From erikj at openjdk.org  Fri Nov  3 18:35:12 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 3 Nov 2023 18:35:12 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <4Qn3IP1g-qcRgpk0l-bPN1-MIaMf-Zct6Fzg1AvzPQQ=.6646b6c2-197e-4cdd-bc18-05beb1da004f@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <4Qn3IP1g-qcRgpk0l-bPN1-MIaMf-Zct6Fzg1AvzPQQ=.6646b6c2-197e-4cdd-bc18-05beb1da004f@github.com>
Message-ID: <MjE3j-_1v2NrqcmhLt639Sv7YEilkcVNt6eITo9rR0g=.6729c97a-6439-4e7c-9cd1-11dd53360ea5@github.com>

On Mon, 30 Oct 2023 17:54:13 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> @robilad, Yakov Shafranovich is covered by Amazon's comany-wide OCA. Can you please approve his OCA status?
> 
> Thank you and best regards,
> Volker

@simonis Only the author of a PR can issue oca related commands.

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

PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1791377895


From kdriver at openjdk.org  Fri Nov  3 18:41:26 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 3 Nov 2023 18:41:26 GMT
Subject: RFR: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12 [v12]
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <zJ3XFdyVeDuugG4fufZNpMNzpSEhRN8THIElAUFeELo=.b5b62d2c-139c-4bba-b16b-4fa3ee29912f@github.com>

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

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

 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - code review comments
 - fix indenting and wildcard imports
 - change getInstance to not require keystore type
 - revert files
 - Security Manager won't let you explicitly set the type here for some
   reason
 - additional updates to explicitly use PKCS12
 - Merge branch 'master' of github.com:openjdk/jdk into 8308453
 - update keystore/truststore type for more dependent tests
 - password for the keystore wasn't being set automatically by the test harness; set it explicitly
 - ... and 9 more: https://git.openjdk.org/jdk/compare/832533c6...a3856ce9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16159/files
  - new: https://git.openjdk.org/jdk/pull/16159/files/59aaba72..a3856ce9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16159&range=10-11

  Stats: 35943 lines in 1369 files changed: 18268 ins; 6706 del; 10969 mod
  Patch: https://git.openjdk.org/jdk/pull/16159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16159/head:pull/16159

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


From mbalao at openjdk.org  Fri Nov  3 19:11:02 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 3 Nov 2023 19:11:02 GMT
Subject: RFR: 8319332: Security properties files inclusion
In-Reply-To: <Vt-BcVFHDeSXp9EdE9ogwMf3WlOwcfZRFNoMvEb13z0=.20dc2094-e915-40e6-821d-10f7549f70b0@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <h8hqCxv1mLcScmJxQ6apwRIc2_yJiptM5La3OdpAdVI=.03a89c7f-8c81-45a1-adca-68d6b2e627c2@github.com>
 <mtXyNoN3_KlZGaaiEMeqy5VqoafkHd7wnstRWxXHeZw=.f176435b-788c-487a-9a0c-d2a073807c8b@github.com>
 <Vt-BcVFHDeSXp9EdE9ogwMf3WlOwcfZRFNoMvEb13z0=.20dc2094-e915-40e6-821d-10f7549f70b0@github.com>
Message-ID: <e7hbxWl321L1xEFVwpsKkM3j00FbMLGkTekCow8jiE0=.52735084-d0df-4100-bea4-cbbd1f4b4594@github.com>

On Fri, 3 Nov 2023 05:42:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Checking for _file_ in the URL scheme is not conclusive evidence that there is a local file path behind. I'll give a couple of examples. In Unix/Linux platforms, an URL of the form `file://example.com/path/to/some/file.txt` is processed with a remote FTP request (see Unix `sun.net.www.protocol.file.Handler`). In Windows, file URLs may be interpreted as UNCs but, if not possible, there is an FTP fallback (see Windows `sun.net.www.protocol.file.Handler`). While checking the host name in the URL is possible, there are three types of drawbacks: 1) a DNS query during the Security class initialization process should be avoided, 2) looking for hardcoded host names such as _localhost_ might lead to false negatives (i.e. a host is considered remote when it is not), and 3) there will be platform-specific and duplicated logic to deal with UNC file URLs. In addition, OpenJDK supports ill-formed relative path file URLs such as `file:some/relative/path`. In these cases, there is not a host name
  but there is a local file path underneath (relative to the current working directory). We did not find normative elements in [RFC 8089](https://www.rfc-editor.org/rfc/rfc8089) for all previously described behaviors, that would have been helpful for a URL-based check. Misinterpreting a file URL as remote will unnecessarily block the possibility of relative path includes.
>> 
>> We think that `FileURLConnection` is the most accurate indicator of a local file path because it includes the decision logic that is specific to OpenJDK and varies depending on the platform.
>
>> Checking for file in the URL scheme is not conclusive evidence that there is a local file path behind. I'll give a couple of examples.
> 
> With NFS and other other remote file systems then you can never tell either. Some of us have been wanting the ftp fallback go away, it comes up every few years.
> 
> My concern is creating dependency on a protocol handler implementation, we should make sure that all other options are explored before going there.

Retrieving a remote file while initializing the Security class is not ideal in terms of latency, but it's a user decision in the end. In fact, UNC paths may be remote and we handle them. The same is true for NFS, as you said. Our concern is not files being remote per-se but the fact that resolving a relative path to a base has to be well defined, which is possible when the base is also a Path. Incidentally, URLs with schemes such as _https_ are also confusing because the security properties used for the TLS connection would depend on where you include the file.

With that said, we also see the benefits of removing the dependency on FileURLConnection. We will make the change, just wanted to note that Path.of(URI.create(...)) will be sub-optimal in terms of what could be seen as a Path and, thus, in relative includes support. In concrete, we identified the following cases:

1) File URLs such as `file://localhost/absolute/path`
 1.1) In Linux, Path.of(URI.create(...)) throws an IllegalArgumentException. 
 1.2) In Windows, Path.of(URI.create(...)) is handled as an UNC path when, per RFC 8089, should have been a local one.
2) Non-conformant file URLs such as `file:///C|/Users/User` (Windows), `file:////?/C:/Users/User` (Windows), or `file://~/absolute/path` (Windows, Linux).
3) Non-conformant file URLs such as `file:relative/path`.
4) Non-conformant file URLs that have a query part, such as `file:///absolute/path?param=value`.

Notice that URL.openConnection() handles all of the previous cases, and returns a FileURLConnection with an underlying local File. For <span>#</span>1 we think that these could be issues in RFC 8089 conformance ?particularly in Linux? that are worth exploring at some point (see sun.nio.fs.UnixUriUtils::fromUri and sun.nio.fs.WindowsUriSupport::fromUri). For <span>#</span>2, <span>#</span>3 and <span>#</span>4 we can add an extra check and do some massaging but, as these are non-conformant file URLs, it is not a big deal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1382111155


From fferrari at openjdk.org  Fri Nov  3 22:18:22 2023
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 3 Nov 2023 22:18:22 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
Message-ID: <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>

> 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. ...

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

  8319332: use Path::of(URI) to deal with file URLs
  
  Instead of the previously introduced FileURLConnection::getFile(), use
  Path::of(URI), leaving some file URL corner-cases without relative
  imports support.
  
  Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
  
  Co-authored-by: Martin Balao <mbalao at redhat.com>
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16483/files
  - new: https://git.openjdk.org/jdk/pull/16483/files/d309b83d..2a4112e4

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

  Stats: 66 lines in 2 files changed: 31 ins; 19 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483

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


From alanb at openjdk.org  Sat Nov  4 07:29:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 4 Nov 2023 07:29:07 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <zi7HzWw7KyrZcXbbkG0kxvdJWdk8JPCHd8a3PSHYFc0=.ce634205-6efa-4d67-ace0-c7c92f1785bf@github.com>

On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

@yakovsh I think this one will take a lot of effort from Reviewers. From a quick look, I think almost all of it is going to require significant editing/re-work. There are a few things that may require input from the security areas. There are issues with terminology and formatting too but they are easier to fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1793369837


From simonis at openjdk.org  Mon Nov  6 13:29:10 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 6 Nov 2023 13:29:10 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <2cmj66SGApybxAzgif834DGMbICt1PPMs42Prf8XWIQ=.9ce00433-ce48-4446-bf0b-2f874bbb3d89@github.com>

On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

I will create the CSR once there's agreement on the exact wording of the proposed API-doc changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1794822606


From kdriver at openjdk.org  Mon Nov  6 15:10:28 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 6 Nov 2023 15:10:28 GMT
Subject: Integrated: 8308453: Convert JKS test keystores in
 test/jdk/javax/net/ssl/etc to PKCS12
In-Reply-To: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
References: <Qrr-ps_5OKv2lwJTDZNvHppAWuPpN_gI5FqwNmPvuNU=.9329b63d-99c2-4c38-8a95-55d5a94b9057@github.com>
Message-ID: <EduJPr3HDTnZcBR7TlQ74lURuuFR5dt7jDXi-X11wTI=.ec41360d-924f-4388-b529-11f685664606@github.com>

On Wed, 11 Oct 2023 21:24:30 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> JDK-8308453: JSSE regression test keystore migration from JKS to PKCS12

This pull request has now been integrated.

Changeset: 1696603c
Author:    Kevin Driver <kdriver at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1696603ccd43a279efa35d9f6617ce664bfdf504
Stats:     101 lines in 23 files changed: 7 ins; 33 del; 61 mod

8308453: Convert JKS test keystores in test/jdk/javax/net/ssl/etc to PKCS12

Reviewed-by: weijun

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

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


From egahlin at openjdk.org  Mon Nov  6 15:30:33 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 6 Nov 2023 15:30:33 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
Message-ID: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>

Could I have a review of a PR that removes the bytecode instrumentation for the exception events.

Testing: jdk/jdk/jfr + tier1 + tier2

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

Commit messages:
 - Remove Throwable and Error from instrumentation list
 - Initial

Changes: https://git.openjdk.org/jdk/pull/16493/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16493&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319374
  Stats: 560 lines in 19 files changed: 268 ins; 281 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16493/head:pull/16493

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


From alanb at openjdk.org  Mon Nov  6 15:52:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Nov 2023 15:52:11 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
In-Reply-To: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
Message-ID: <N_kD6Q8Gqkg5fLyF1OP_UQ8f7gIx2K-uLKo1YdKiN4E=.a90d68b8-1d7d-403f-92a0-18fbe72a28ff@github.com>

On Fri, 3 Nov 2023 12:19:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2

src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 37:

> 35:     private static final AtomicLong numThrowables = new AtomicLong();
> 36: 
> 37:     public static void enable() throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException {

SecurityException and IllegaArgumentException are unchecked so don't need them in the throws declaration.

src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44:

> 42: 
> 43:     public static void traceError(Class<?> clazz, String message) {
> 44:         if (OutOfMemoryError.class.isAssignableFrom(clazz)) {

StackOverflowError is likely problematic too, maybe it should be VirtualMachineError.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1383552825
PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1383552352


From hchao at openjdk.org  Mon Nov  6 20:51:40 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 6 Nov 2023 20:51:40 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
Message-ID: <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>

On Wed, 1 Nov 2023 14:13:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> When no system property is set, previously max inbound length is 10, now it's 8.
>
> I think the wording of the comment is somewhat confusing because it is trying to explain the behavior of both properties together and the words "either" and "neither" may be hard to parse. I recommend separate comment blocks for each property. Here is a suggestion for the server side setting:
> 
> 
> /* 
>  * maxInboundClientCertChainLen is the maximum length of a client certificate
>  * chain accepted by a server. It is determined as follows:
>  *  - If the jdk.tls.server.maxInboundCertificateChainLength system property
>  *    is set and its value >= 0, it uses that value.
>  *  - Otherwise, if the jdk.tls.maxCertificateChainLength system property is
>  *    set and its value >= 0, it uses that value.
>  *  - Otherwise it is set to a default value of 8.
>  */
> 
> 
> The client side setting would be similar.

Yes, I can place the comments in the code blocks for the server-side setting and client-side setting, respectively.
@XueleiFan Any feedback before I'm making this comment change?
I will also update the release note accordingly. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1383967102


From bpb at openjdk.org  Mon Nov  6 22:36:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 6 Nov 2023 22:36:50 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v6]
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <ltM3EKuxILNdhVNpzHdc26xP5MB1W7XcjUD2k3qkI94=.3d5ba36d-0305-4d8b-b596-e91f74e9aaf6@github.com>

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

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

 - Merge
 - Merge
 - 6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native
 - 6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy
 - 6478546: Decrease malloc limit to 1.5 MB
 - 6478546: Minor refactoring
 - 6478546: Prevent short read
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/3a016a72..408e2df6

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

  Stats: 69129 lines in 2383 files changed: 38779 ins; 14073 del; 16277 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

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


From egahlin at openjdk.org  Mon Nov  6 22:44:30 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 6 Nov 2023 22:44:30 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
In-Reply-To: <N_kD6Q8Gqkg5fLyF1OP_UQ8f7gIx2K-uLKo1YdKiN4E=.a90d68b8-1d7d-403f-92a0-18fbe72a28ff@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <N_kD6Q8Gqkg5fLyF1OP_UQ8f7gIx2K-uLKo1YdKiN4E=.a90d68b8-1d7d-403f-92a0-18fbe72a28ff@github.com>
Message-ID: <Qo-S8rzCUWTYYZv9lXoy-UXT7sZ8IAvTM9y-UfGoMD4=.ba4babf3-b937-4a54-b94e-2f2132105194@github.com>

On Mon, 6 Nov 2023 15:49:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 37:
> 
>> 35:     private static final AtomicLong numThrowables = new AtomicLong();
>> 36: 
>> 37:     public static void enable() throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException {
> 
> SecurityException and IllegaArgumentException are unchecked so don't need them in the throws declaration.

Will fix.

> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44:
> 
>> 42: 
>> 43:     public static void traceError(Class<?> clazz, String message) {
>> 44:         if (OutOfMemoryError.class.isAssignableFrom(clazz)) {
> 
> StackOverflowError is likely problematic too, maybe it should be VirtualMachineError.

I remember asking the same question ten years ago, when Nils did the original implementation, but I think it was only needed for OOM, because it creates an infinite loop when the event object was allocated, which resulted in a StackOverflowError instead OOM.

Some OOM tests failed with JFR enabled.

The event object allocation has been removed, but I think we can run into the allocation recursion by other means. I looked into it a few years ago, but I don't remember exactly why it failed.

If a SOE happens, I think we are fine. There is something that prevents infinite recursion when the SOE object is created. Perhaps it is preallocated? I prefer to not change the behavior, at least not in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384124648
PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384124213


From egahlin at openjdk.org  Mon Nov  6 22:52:50 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 6 Nov 2023 22:52:50 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v2]
In-Reply-To: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
Message-ID: <NUlbDKtisXFxaRkYHFTa7OALWYMFUYCqj3gnEHc-1A8=.f65b5419-9fde-45a3-b4e8-51bdcb462169@github.com>

> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2

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

  Remove SecurityException and IllegalArgumentException from throws clause

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16493/files
  - new: https://git.openjdk.org/jdk/pull/16493/files/95a54349..23a07a18

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

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

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


From egahlin at openjdk.org  Tue Nov  7 02:16:30 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 7 Nov 2023 02:16:30 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v2]
In-Reply-To: <Qo-S8rzCUWTYYZv9lXoy-UXT7sZ8IAvTM9y-UfGoMD4=.ba4babf3-b937-4a54-b94e-2f2132105194@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <N_kD6Q8Gqkg5fLyF1OP_UQ8f7gIx2K-uLKo1YdKiN4E=.a90d68b8-1d7d-403f-92a0-18fbe72a28ff@github.com>
 <Qo-S8rzCUWTYYZv9lXoy-UXT7sZ8IAvTM9y-UfGoMD4=.ba4babf3-b937-4a54-b94e-2f2132105194@github.com>
Message-ID: <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com>

On Mon, 6 Nov 2023 22:41:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44:
>> 
>>> 42: 
>>> 43:     public static void traceError(Class<?> clazz, String message) {
>>> 44:         if (OutOfMemoryError.class.isAssignableFrom(clazz)) {
>> 
>> StackOverflowError is likely problematic too, maybe it should be VirtualMachineError.
>
> I remember asking the same question ten years ago, when Nils did the original implementation, but I think it was only needed for OOM, because it creates an infinite loop when the event object was allocated, which resulted in a StackOverflowError instead OOM.
> 
> Some OOM tests failed with JFR enabled.
> 
> The event object allocation has been removed, but I think we can run into the allocation recursion by other means. I looked into it a few years ago, but I don't remember exactly why it failed.
> 
> If a SOE happens, I think we are fine. There is something that prevents infinite recursion when the SOE object is created. Perhaps it is preallocated? I prefer to not change the behavior, at least not in this PR.

I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now.
https://bugs.openjdk.org/browse/JDK-8319579

Regardless of outcome, It would be good to document the results of the investigation in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384263589


From xuelei at openjdk.org  Tue Nov  7 07:43:42 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 7 Nov 2023 07:43:42 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
 <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
Message-ID: <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjkSA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>

On Mon, 6 Nov 2023 20:48:59 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> I think the wording of the comment is somewhat confusing because it is trying to explain the behavior of both properties together and the words "either" and "neither" may be hard to parse. I recommend separate comment blocks for each property. Here is a suggestion for the server side setting:
>> 
>> 
>> /* 
>>  * maxInboundClientCertChainLen is the maximum length of a client certificate
>>  * chain accepted by a server. It is determined as follows:
>>  *  - If the jdk.tls.server.maxInboundCertificateChainLength system property
>>  *    is set and its value >= 0, it uses that value.
>>  *  - Otherwise, if the jdk.tls.maxCertificateChainLength system property is
>>  *    set and its value >= 0, it uses that value.
>>  *  - Otherwise it is set to a default value of 8.
>>  */
>> 
>> 
>> The client side setting would be similar.
>
> Yes, I can place the comments in the code blocks for the server-side setting and client-side setting, respectively.
> @XueleiFan Any feedback before I'm making this comment change?
> I will also update the release note accordingly. Thanks!

I'm not sure if there is a clear reason to change the default value from 10 to 8.  I'm fine if you want to keep to use value 10 for less compatibility issues. Otherwise, I have no more comment.  Thanks!

> Yes, I can place the comments in the code blocks for the server-side setting and client-side setting, respectively. @XueleiFan Any feedback before I'm making this comment change? I will also update the release note accordingly. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1384494328


From alanb at openjdk.org  Tue Nov  7 09:27:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Nov 2023 09:27:30 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v2]
In-Reply-To: <NUlbDKtisXFxaRkYHFTa7OALWYMFUYCqj3gnEHc-1A8=.f65b5419-9fde-45a3-b4e8-51bdcb462169@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <NUlbDKtisXFxaRkYHFTa7OALWYMFUYCqj3gnEHc-1A8=.f65b5419-9fde-45a3-b4e8-51bdcb462169@github.com>
Message-ID: <UrvMPQqCJM0Fq24r2lSOiQywRugl2r1UaOhu5PKCWtU=.35c2d6d6-7b4a-4e06-830d-c22b097950c7@github.com>

On Mon, 6 Nov 2023 22:52:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SecurityException and IllegalArgumentException from throws clause

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

> 123:      * Flag that determines if exceptions should be traced by JFR
> 124:      */
> 125:     static volatile boolean tracing;

The use-sites in Error check Throwable.tracing so not  immediately obvious that it's JFR tracing. Maybe it should be renamed to jfrTracing or an accessor of that name added so it's a bit clearer at the use-sites.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384612334


From alanb at openjdk.org  Tue Nov  7 09:30:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Nov 2023 09:30:29 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v2]
In-Reply-To: <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <N_kD6Q8Gqkg5fLyF1OP_UQ8f7gIx2K-uLKo1YdKiN4E=.a90d68b8-1d7d-403f-92a0-18fbe72a28ff@github.com>
 <Qo-S8rzCUWTYYZv9lXoy-UXT7sZ8IAvTM9y-UfGoMD4=.ba4babf3-b937-4a54-b94e-2f2132105194@github.com>
 <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com>
Message-ID: <9wSlgTqUQBzVaZgyIwvGe4KOikMoE7GxaS0KqDiEXTA=.2c4be523-1786-4880-8146-b9a476ab25a7@github.com>

On Tue, 7 Nov 2023 02:10:29 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. https://bugs.openjdk.org/browse/JDK-8319579
> 
> Regardless of outcome, It would be good to document the results of the investigation in the code.

Okay, the scenario I was wondering about is where traceError fails with SOE and whether that could trigger a loop too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384617053


From egahlin at openjdk.org  Tue Nov  7 10:39:31 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 7 Nov 2023 10:39:31 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v2]
In-Reply-To: <UrvMPQqCJM0Fq24r2lSOiQywRugl2r1UaOhu5PKCWtU=.35c2d6d6-7b4a-4e06-830d-c22b097950c7@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <NUlbDKtisXFxaRkYHFTa7OALWYMFUYCqj3gnEHc-1A8=.f65b5419-9fde-45a3-b4e8-51bdcb462169@github.com>
 <UrvMPQqCJM0Fq24r2lSOiQywRugl2r1UaOhu5PKCWtU=.35c2d6d6-7b4a-4e06-830d-c22b097950c7@github.com>
Message-ID: <Bi9cKjwMMuZYfE1xFvdP-l_f1XYWl682mQD8f7cN5iM=.6b557d45-7bf7-4a49-b953-fa9fa7ded385@github.com>

On Tue, 7 Nov 2023 09:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove SecurityException and IllegalArgumentException from throws clause
>
> src/java.base/share/classes/java/lang/Throwable.java line 125:
> 
>> 123:      * Flag that determines if exceptions should be traced by JFR
>> 124:      */
>> 125:     static volatile boolean tracing;
> 
> The use-sites in Error check Throwable.tracing so not  immediately obvious that it's JFR tracing. Maybe it should be renamed to jfrTracing or an accessor of that name added so it's a bit clearer at the use-sites.

Will change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384714812


From egahlin at openjdk.org  Tue Nov  7 10:39:33 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 7 Nov 2023 10:39:33 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v2]
In-Reply-To: <9wSlgTqUQBzVaZgyIwvGe4KOikMoE7GxaS0KqDiEXTA=.2c4be523-1786-4880-8146-b9a476ab25a7@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <N_kD6Q8Gqkg5fLyF1OP_UQ8f7gIx2K-uLKo1YdKiN4E=.a90d68b8-1d7d-403f-92a0-18fbe72a28ff@github.com>
 <Qo-S8rzCUWTYYZv9lXoy-UXT7sZ8IAvTM9y-UfGoMD4=.ba4babf3-b937-4a54-b94e-2f2132105194@github.com>
 <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com>
 <9wSlgTqUQBzVaZgyIwvGe4KOikMoE7GxaS0KqDiEXTA=.2c4be523-1786-4880-8146-b9a476ab25a7@github.com>
Message-ID: <0afwCsl4VMJkrRhqtR9Hzf16bVjKK08V7eoHFhSwYys=.19a98d83-bee6-4aed-b9e4-188e62dd879b@github.com>

On Tue, 7 Nov 2023 09:27:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now.
>> https://bugs.openjdk.org/browse/JDK-8319579
>> 
>> Regardless of outcome, It would be good to document the results of the investigation in the code.
>
>> I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. https://bugs.openjdk.org/browse/JDK-8319579
>> 
>> Regardless of outcome, It would be good to document the results of the investigation in the code.
> 
> Okay, the scenario I was wondering about is where traceError fails with SOE and whether that could trigger a loop too.

I understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384714404


From egahlin at openjdk.org  Tue Nov  7 11:11:31 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 7 Nov 2023 11:11:31 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
Message-ID: <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>

> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2

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

  Rename field from tracing to jfrTracing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16493/files
  - new: https://git.openjdk.org/jdk/pull/16493/files/23a07a18..195c1086

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

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

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


From mgronlun at openjdk.org  Tue Nov  7 13:28:31 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 7 Nov 2023 13:28:31 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
Message-ID: <o8WaNOKh4gjfX6xbeJRpiOpMLb8vXlBA4yXl_Irdm4c=.44ea5c56-948e-458d-8b8a-3a21efaa52f4@github.com>

On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename field from tracing to jfrTracing

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16493#pullrequestreview-1717679195


From alanb at openjdk.org  Tue Nov  7 15:23:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Nov 2023 15:23:32 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
Message-ID: <gkzZUu7dVKEl-zhsuMCLeU8Aaku3YzJLnT96fNHnt48=.04ee0ae8-e0d9-4a97-96d8-6d36cb404da0@github.com>

On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename field from tracing to jfrTracing

The changes looks okay and will track the follow-on issue to look at SOE.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16493#pullrequestreview-1717977940


From mdonovan at openjdk.org  Tue Nov  7 20:11:06 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 7 Nov 2023 20:11:06 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
Message-ID: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>

In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.

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

Commit messages:
 - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

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

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


From mullan at openjdk.org  Tue Nov  7 20:30:10 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Nov 2023 20:30:10 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjkSA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
 <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
 <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjk
 SA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>
Message-ID: <2Ofw53W_fxl3heGu4DBipfeuagynox2dfYrMaBqFun0=.b714ad70-9528-4987-950c-1a39ad5ec9a2@github.com>

On Tue, 7 Nov 2023 07:40:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Yes, I can place the comments in the code blocks for the server-side setting and client-side setting, respectively.
>> @XueleiFan Any feedback before I'm making this comment change?
>> I will also update the release note accordingly. Thanks!
>
> I'm not sure if there is a clear reason to change the default value from 10 to 8.  I'm fine if you want to keep to use value 10 for less compatibility issues. Otherwise, I have no more comment.  Thanks!
> 
>> Yes, I can place the comments in the code blocks for the server-side setting and client-side setting, respectively. @XueleiFan Any feedback before I'm making this comment change? I will also update the release note accordingly. Thanks!

The choice of 8 for the client is mostly based on different processing requirements and use cases for TLS client vs server certificate chains. If we see evidence that 8 is too low, we can always consider adjusting it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1385524607


From duke at openjdk.org  Tue Nov  7 23:32:04 2023
From: duke at openjdk.org (duke)
Date: Tue, 7 Nov 2023 23:32:04 GMT
Subject: Withdrawn: 8316057:
 javax/crypto/CryptoPermissions/InconsistentEntries.java fails on read-only JDK
In-Reply-To: <aIRI5nftp6dRGxxeB_bWD3KWTBtizX_um5H5u3vSZj8=.1e2951ee-6840-4987-9746-067692099f01@github.com>
References: <aIRI5nftp6dRGxxeB_bWD3KWTBtizX_um5H5u3vSZj8=.1e2951ee-6840-4987-9746-067692099f01@github.com>
Message-ID: <fJN_UKwYg-53uHWTfXjEcVX4xiJLP0HDPLDuIdPqLRw=.282a5a54-80e4-4994-9855-504d93f83e55@github.com>

On Mon, 11 Sep 2023 23:20:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am not sure that it is a good thing to modify the JDK when many tests are executed in parallel. But for now, I updated the test, it will be skipped if the setup stage fails.

This pull request has been closed without being integrated.

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

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


From xuelei at openjdk.org  Wed Nov  8 04:21:06 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 8 Nov 2023 04:21:06 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <2Ofw53W_fxl3heGu4DBipfeuagynox2dfYrMaBqFun0=.b714ad70-9528-4987-950c-1a39ad5ec9a2@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
 <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
 <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjk
 SA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>
 <2Ofw53W_fxl3heGu4DBipfeuagynox2dfYrMaBqFun0=.b714ad70-9528-4987-950c-1a39ad5ec9a2@github.com>
Message-ID: <cH8zLTQEcXTcdp47d0zgzoP_8TJSOE_WX062acQ9skw=.6f3d04a0-789c-4d0c-b9c7-ca41e265dae2@github.com>

On Tue, 7 Nov 2023 20:27:06 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I'm not sure if there is a clear reason to change the default value from 10 to 8.  I'm fine if you want to keep to use value 10 for less compatibility issues. Otherwise, I have no more comment.  Thanks!
>> 
>>> Yes, I can place the comments in the code blocks for the server-side setting and client-side setting, respectively. @XueleiFan Any feedback before I'm making this comment change? I will also update the release note accordingly. Thanks!
>
> The choice of 8 for the client is mostly based on different processing requirements and use cases for TLS client vs server certificate chains. If we see evidence that 8 is too low, we can always consider adjusting it.

I'm not sure if the number 8 or 10 really make a good difference in practice.  No matter 8 or 10,  if customers need lower value, they can always consider adjusting it.  My concern is mainly about compatibility issues.  If you want to keep the behavior changes, as there is potential compatibility issue, please feel free to describe the behavior change in release note and CSR if you would like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1385958137


From dholmes at openjdk.org  Wed Nov  8 05:15:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Nov 2023 05:15:57 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
Message-ID: <Y_8SS4nYBYeHwB_9XF5H5jQqdOc075eYPW8wkxGKDOw=.a9a71fc9-a785-4ec2-a531-33cf7735b551@github.com>

On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename field from tracing to jfrTracing

src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62:

> 60:         if (ExceptionThrownEvent.enabled()) {
> 61:             long timestamp = ExceptionThrownEvent.timestamp();
> 62:             ExceptionThrownEvent.commit(timestamp, message, clazz);

Just a drive-by observation, but now you get the timestamp from the event it seems strange to pull it out and then pass it back to commit, instead of having a version of commit that automatically uses the internal timestamp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1385990281


From egahlin at openjdk.org  Wed Nov  8 05:38:58 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Nov 2023 05:38:58 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <Y_8SS4nYBYeHwB_9XF5H5jQqdOc075eYPW8wkxGKDOw=.a9a71fc9-a785-4ec2-a531-33cf7735b551@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
 <Y_8SS4nYBYeHwB_9XF5H5jQqdOc075eYPW8wkxGKDOw=.a9a71fc9-a785-4ec2-a531-33cf7735b551@github.com>
Message-ID: <OGZW7a_jgIb1BFra7Qo2LV_gsDOjTb4eVLo-KVH0-Ug=.f3a9375a-d1e8-41fc-892c-cb14717dcd38@github.com>

On Wed, 8 Nov 2023 05:13:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename field from tracing to jfrTracing
>
> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62:
> 
>> 60:         if (ExceptionThrownEvent.enabled()) {
>> 61:             long timestamp = ExceptionThrownEvent.timestamp();
>> 62:             ExceptionThrownEvent.commit(timestamp, message, clazz);
> 
> Just a drive-by observation, but now you get the timestamp from the event it seems strange to pull it out and then pass it back to commit, instead of having a version of commit that automatically uses the internal timestamp.

I agree, and I have looked into it, but I think it's better to do that refactorization separately as it will impact other events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1386016878


From egahlin at openjdk.org  Wed Nov  8 13:25:07 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Nov 2023 13:25:07 GMT
Subject: Integrated: 8319374: JFR: Remove instrumentation for exception events
In-Reply-To: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
Message-ID: <EqL9QaOZYgQhXoxCWiXFIGxHby2orkJVwWTErM7rl2g=.ac1f4677-d048-499c-81fc-4c4109288d6e@github.com>

On Fri, 3 Nov 2023 12:19:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes the bytecode instrumentation for the exception events.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2

This pull request has now been integrated.

Changeset: e8418972
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8418972474d41c6cc1985df5c650461ded34313
Stats:     560 lines in 19 files changed: 268 ins; 281 del; 11 mod

8319374: JFR: Remove instrumentation for exception events

Reviewed-by: mgronlun, alanb

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

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


From dfuchs at openjdk.org  Wed Nov  8 13:42:11 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 8 Nov 2023 13:42:11 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <OGZW7a_jgIb1BFra7Qo2LV_gsDOjTb4eVLo-KVH0-Ug=.f3a9375a-d1e8-41fc-892c-cb14717dcd38@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
 <Y_8SS4nYBYeHwB_9XF5H5jQqdOc075eYPW8wkxGKDOw=.a9a71fc9-a785-4ec2-a531-33cf7735b551@github.com>
 <OGZW7a_jgIb1BFra7Qo2LV_gsDOjTb4eVLo-KVH0-Ug=.f3a9375a-d1e8-41fc-892c-cb14717dcd38@github.com>
Message-ID: <9as_D0HLvxVsIssfobrgL071tvNTWR5voqCOwaP00AU=.3999d6ec-5d00-4c53-aa74-22853c9a0265@github.com>

On Wed, 8 Nov 2023 05:34:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62:
>> 
>>> 60:         if (ExceptionThrownEvent.enabled()) {
>>> 61:             long timestamp = ExceptionThrownEvent.timestamp();
>>> 62:             ExceptionThrownEvent.commit(timestamp, message, clazz);
>> 
>> Just a drive-by observation, but now you get the timestamp from the event it seems strange to pull it out and then pass it back to commit, instead of having a version of commit that automatically uses the internal timestamp.
>
> I agree, and I have looked into it, but I think it's better to do that refactorization separately as it will impact other events.

Just for my own understanding: in this particular case the time stamp is meaningless because the duration is expected to be 0 (or close to it) since nothing happens between the time the timestamp is taken and the time the event is committed. Is that correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1386635624


From egahlin at openjdk.org  Wed Nov  8 15:13:12 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Nov 2023 15:13:12 GMT
Subject: RFR: 8319374: JFR: Remove instrumentation for exception events
 [v3]
In-Reply-To: <9as_D0HLvxVsIssfobrgL071tvNTWR5voqCOwaP00AU=.3999d6ec-5d00-4c53-aa74-22853c9a0265@github.com>
References: <hPqvb7y2QgLltGpXqDNZckbzyMCA3kZqYpXf2b2rFNo=.c2b428c0-9287-4674-87f9-6f458f60ec3c@github.com>
 <hvCFuFzqIb_sJH9Y0qkOeO0Yj5Gqka89HSz9KwVv43Y=.d9a8d8e8-eea9-4f07-8d68-6b1a4a34bb5b@github.com>
 <Y_8SS4nYBYeHwB_9XF5H5jQqdOc075eYPW8wkxGKDOw=.a9a71fc9-a785-4ec2-a531-33cf7735b551@github.com>
 <OGZW7a_jgIb1BFra7Qo2LV_gsDOjTb4eVLo-KVH0-Ug=.f3a9375a-d1e8-41fc-892c-cb14717dcd38@github.com>
 <9as_D0HLvxVsIssfobrgL071tvNTWR5voqCOwaP00AU=.3999d6ec-5d00-4c53-aa74-22853c9a0265@github.com>
Message-ID: <GQ7AYzs8jsOVjVq9qn8pGvvMHqVF2To7r32VX9aG1Nc=.fcb1b97f-8308-4344-8b7b-d853185d7181@github.com>

On Wed, 8 Nov 2023 13:39:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I agree, and I have looked into it, but I think it's better to do that refactorization separately as it will impact other events.
>
> Just for my own understanding: in this particular case the time stamp is meaningless because the duration is expected to be 0 (or close to it) since nothing happens between the time the timestamp is taken and the time the event is committed. Is that correct?

Yes, the event has no duration.

Before https://bugs.openjdk.org/browse/JDK-8239508 we wrote timestamp and duration for all Java events. For exception events, we wrote duration = 0. Now we can differentiate between durational and instant events, which means bytecode can be generated to take the timestamp in the commit method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1386777042


From sean.mullan at oracle.com  Wed Nov  8 21:33:47 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Nov 2023 21:33:47 +0000
Subject: RFR: 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: <FFFA7F60-531A-403B-8A6C-BFCB67467478@oracle.com>

Hi Martin and Francisco,

Thank you for your work on proposing this feature. This is a significant change to the JCA/JCE provider mechanism and consists of (roughly) over a thousand lines of code changes. Based on that and after spending some time understanding and reviewing the proposal, we feel that a JEP is required for this feature [1, 2]. A JEP will give it more visibility, broader review, and provide more time to ensure that the design is sound and open issues have been considered and adequately resolved.

This likely means that it won?t make JDK 22 but I think that is fine as I don?t see any critical urgency in getting this into the next release of the JDK.

I can help with the JEP process should you have questions.

Thanks,
Sean

[1] https://openjdk.org/jeps/1
[2] https://cr.openjdk.org/~mr/jep/jep-2.0-02.html

> On Sep 1, 2023, at 11:20 AM, 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 service matches it. Otherwise, the filter moves to the next rule in the sequence.
> 
> Rules are made of 3 regular expressions, derived from a filter pattern: provider, service type and algorithm or alias. A service matches a rule when its provider, service type and algorithm or alias matches the corresponding regular expressions in the rule. When a rule is matched by a service, it casts a decision (represented by the ProvidersFilter::FilterDecision class) that has two values: an allow or deny result and a priority that depends on how early (or left, in filter string terms) the rule is positioned in relative terms. Priorities are used for services that have aliases, as a mechanism to disambiguate contradictory decision results depending on which alias or algorithm is evaluated.
> 
> When a service with aliases is passed through a filter, independent evaluations are made for the algorithm and each alias. The decision with highest priority (lowest in absolute numbers) is finally effective.
> 
> ### Filter decisions cache
> 
> To accomplish the goal of maximizing performance, most services are passed through the Providers filter at registration time, when added with the java.security.Provider::putService or java.security.Provider::put APIs. While uncommon, providers may override java.security.Provider::getService or java.security.Provider::getServices APIs and return services that were never registered. In these cases, the service is evaluated against the Providers filter the first time used.
> 
> Once a service is evaluated against the filter, the decision is stored in the private isAllowed Provider.Service class field. When authorizing further uses of the service, the value from this cache is read, instead of performing a new filter evaluation. If the service does not experience any change, such as gaining or losing an alias (only possible with the legacy API), the cached value remains valid. Otherwise, a new filter evaluation has to take place. For example, a service could have been not allowed but a new alias matches an authorization rule in the filter that flips the previous decision.
> 
> The method Provider.Service::computeIsAllowed (that internally invokes ProvidersFilter::computeIsAllowed) can be used to force the recomputation of an authorization cached decision. The method ProvidersFilter::isAllowed, when filtering capabilities are enabled, tries to get the service authorization from the Provider.Service isAllowed field, and triggers a computation if not initialized. For this mechanism to work, the Provider.Service::getIsAllowed private method is exposed through SharedSecrets and accessed from ProvidersFilter.
> 
> ### Filter checking idiom
> 
> At every point in the JDK where any of Provider::getService or Provider::getServices APIs are invoked, a Providers filter check must be applied by calling ProvidersFilter.isAllowed(serviceInstance). It's assumed that serviceInstance is not null. The returned value indicates if the serviceInstance service is allowed or not. When a service is not allowed, the caller must discard it. The reason why we need to apply this checking pattern is because Provider::getService or Provider::getServices APIs may be overwritten by a provider to return unregistered services that were not evaluated against the filter before. If these APIs were not overwritten, the implementation will only return allowed services.
> 
> ### Debugging the filter
> 
> There are 3 mechanisms to debug a filter:
> 
> 1 - Set the "java.security.debug" System property to "jca" and find filter-related messages prefixed by "ProvidersFilter". This debug output includes information about the filter construction (parsing) as well as evaluations of services against the filter. Note: the application has to trigger the ProvidersFilter class static initialization for this output to be generated, for example by invoking java.security.Security::getProviders.
> 
> Example:
> 
> java -Djava.security.debug=jca -Djdk.security.providers.filter="SunJCE.Cipher.AES" Main
> 
> Filter construction messages:
> 
> ProvidersFilter: Parsing: SunJCE.Cipher.AES
> ProvidersFilter: --------------------
> ProvidersFilter: Rule parsed: SunJCE.Cipher.AES
> ProvidersFilter:  * Provider: SunJCE (regexp: \QSunJCE\E)
> ProvidersFilter:  * Service type: Cipher (regexp: \QCipher\E)
> ProvidersFilter:  * Algorithm: AES (regexp: \QAES\E)
> ProvidersFilter:  * Decision: ALLOW - priority: 0
> ProvidersFilter: Filter: SunJCE.Cipher.AES; !* (DEFAULT)
> ProvidersFilter: --------------------
> 
> Filter evaluation messages:
> 
> ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: AES)
> ProvidersFilter:  * Decision: ALLOW - priority: 0
> ProvidersFilter:  * Made by: SunJCE.Cipher.AES
> ProvidersFilter: --------------------
> ProvidersFilter: The queried service has aliases. Checking them for a final decision...
> ProvidersFilter: --------------------
> ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: OID.2.16.840.1.101.3.4.1)
> ProvidersFilter:  * Decision: DENY - priority: 1
> ProvidersFilter:  * Made by: !* (DEFAULT)
> ProvidersFilter: --------------------
> ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: 2.16.840.1.101.3.4.1)
> ProvidersFilter:  * Decision: DENY - priority: 1
> ProvidersFilter:  * Made by: !* (DEFAULT)
> ProvidersFilter: --------------------
> ProvidersFilter: Final decision based on AES algorithm: ALLOW - priority: 0
> 
> 
> 2 - Pass the -XshowSettings:security:providers JVM argument and check, for each statically installed security provider, which services are allowed and not allowed by the filter.
> 
> Example:
> 
> 
> java -XshowSettings:security:providers -Djdk.security.providers.filter="SunJCE.Cipher.AES" -version
> 
> 
> Security provider static configuration: (in order of preference)
>        ...
>        ----------------------------------------
>   Provider name: SunJCE
>   ...
>   Provider services allowed: (type : algorithm)
>            Cipher.AES
>              aliases: [2.16.840.1.101.3.4.1, OID.2.16.840.1.101.3.4.1]
>   Provider services NOT allowed: (type : algorithm)
>            AlgorithmParameterGenerator.DiffieHellman
>              aliases: [1.2.840.113549.1.3.1, DH, OID.1.2.840.113549.1.3.1]
>            ...
>   ----------------------------------------
>   ...
> 
> 
> 3 - When a filter cannot be constructed, the ProvidersFilter.ParserException exception includes the state of the filter at the time when the error occurred, and indicates which pattern could not be parsed.
> 
> Example:
> 
> java -XshowSettings:security:providers -Djdk.security.providers.filter="SunJCE.Cipher.AES; My Provider"
> 
> 
> Caused by: sun.security.jca.ProvidersFilter$Filter$ParserException: Only whitespace characters are valid after a pattern. Whitespaces that are part of a provider name, service type or algorithm must be escaped.
> * State: POST_PATTERN
> * Filter string: SunJCE.Cipher.AES; My Provider
>                                     ---^---
> 
> 
> ## ServicesMap
> 
> Existing Provider::getService and Provider.getServices APIs were changed to return services that are allowed by the Providers filter only. In addition, a new Provider::getServicesNotAllowed method (exposed through the SharedSecrets mechanism) was introduced to obtain services that are not allowed by the Providers filter, for informational purposes only (see -XshowSettings:security:providers). These changes motivated an analysis of how services are stored internally in a Provider instance, and lead to the refactoring that will be explained in this section.
> 
> ### Existing bugs and inconsistencies
> 
> While analyzing the existing services map implementation, we categorized bugs found in 3 sets: 1) Concurrency bugs, 2) Serialization consistency bugs, and 3) Other bugs. While many of these bugs are related to corner cases that are unlikely to be triggered in real providers, others can potentially happen in highly concurrent scenarios and would be difficult to reproduce.
> 
> #### 1 - Concurrency bugs
> 
> 1.1 - A concurrent Provider::getServices call may remove services that are temporarily considered invalid because they are in the midst of an update. I.e. a provider added an alias but not the class name still, and a reader removes the service in between:
> 
> Thread-1 (writer): Provider::put("Alg.Alias.MessageDigest.alias1", "alg1") ---> An invalid service is implicitly created
> Thread-2 (reader): Provider::getServices() ---> The invalid service is removed
> Thread-1 (writer): Provider::put("MessageDigest.alg1", "class1") ---> While the service is added again (valid, now), it won't have alias1.
> 
> While the situation sounds unlikely for a regular service registration, it is possible when deserializing Providers as the order in which Property map entries are visited is not guaranteed.
> 
> This scenario was not possible before JDK-8276660 because readers only removed invalid entries from legacyMap, but not from legacyStrings. As a result, invalid services could land in legacyMap without losing data after they become valid. See a reference to the JDK-8276660 removal here [1]. We have developed the ServicesConsistency::testInvalidGetServicesRemoval test to reflect this case.
> 
> Notice that the fact that legacyMap is a ConcurrentHashMap instance does not prevent this bug from happening, as the problem is between non-atomic and non-synchronized writes.
> 
> 1.2 - This bug is similar to 1.1 but occurs in Provider::getService [2], and is reflected in the test ServicesConsistency::testInvalidGetServiceRemoval.
> 
> 1.3 - When signaling legacyChanged = false after recomputing the services set here [3], a concurrent legacyMap update that right before set legacyChanged = true [4] [5] would be missed. This was introduced by JDK-8276660 because, previously, legacyChanged = false was done in ensureLegacyParsed and this method was called in a synchronized getService block. Notice here that making legacyChanged volatile did not prevent this issue, as the problem is that publishing the new computed set and resetting the legacyChanged variable is not an atomic operation and a new update could have happened in between. We think that this type of problem can be solved in a lock-free way with a pattern such as the one proposed in ServicesMap::getServicesSet, that includes a double compare and exchange with a placeholder while computing the set.
> 
> 1.4 - In operations such as Provider::implReplaceAll, there is a window in which all services look gone for readers [6] and this may cause spurious NoSuchAlgorithmException exceptions. Before JDK-8276660 the operation was seen as atomic by readers. The replaceAll change in the Properties map was made on legacyStrings by writers but only visible after readers impacted changes under a synchronized block. We think that replaceAll and putAll should be atomic for readers. In particular, putAll would be the legacy API mechanism to ensure that readers see services only when they have all their attributes added, and there is no risk of obtaining a service with half of them. See a test that checks an atomic replaceAll behavior in ServicesConsistency::testReplaceAllIsAtomic and a test that checks a putAll atomic behavior in ServicesConsistency::testPutAllIsAtomic.
> 
> 1.5 - When a reader obtains a service from the legacyMap, Service::newInstance or Service::supportsParameter may be invoked and cached values such as classCache, constructorCache, hasKeyAttributes, supportedFormats and supportedClasses set. If there are further changes to the service (i.e.: new attributes added), cached values are never invalidated and there is a single service instance. As a result, the service information becomes inconsistent and the new attributes are missed, even for new readers. This did not happen before JDK-8276660 because ensureLegacyParsed started with a clear legacyMap and new Service instances (with uninitialized cache fields) were added. This bug is reflected in ServicesConsistency::testInvalidCachedClass, ServicesConsistency::testInvalidCachedHasKeyAttributes and ServicesConsistency::testInvalidCachedSupportedKeyFormats tests.
> 
> #### 2 - Serialization consistency bugs
> 
> This type of bugs make a deserialized Provider to have different services (class names, aliases and attributes) than the original instance. What they have in common is one or more of the following traits: 1) lack of synchronization between the Properties map and the actual inner services map, 2) an incorrect assumption that the Properties map is visited, while deserializing, in the same order in which entries were originally added, or 3) an inconsistent collision behavior between the Provider::put and Provider::putService APIs.
> 
> We will show some examples that, while unrealistic, serve for the purpose of illustrating the aforementioned inconsistencies:
> 
> 2.1 - Case-sensitive entries
> 
> Ordered list of actions:
> 
> put("MessageDigest.alg", "class1")
> put("MessageDigest.ALG", "class2")
> 
> The previous list of actions creates a single Service instance that has "class2" as its class name. In the Properties map, however, both entries are present.
> 
> List of actions in the order that they are executed while deserializing the provider:
> 
> put("MessageDigest.ALG", "class2")
> put("MessageDigest.alg", "class1")
> 
> The created Service instance, after deserialization, has "class1" as its class name.
> 
> This case is reflected in the ServicesConsistency::testSerializationClassnameConsistency test.
> 
> 2.2 - Entries by alias
> 
> Ordered list of actions:
> 
> put("MessageDigest.alg", "class1")
> put("Alg.Alias.MessageDigest.alias", "alg")
> put("Alg.Alias.MessageDigest.alias2", "alias")
> 
> The previous list of actions creates a single Service instance that has "alg" as its algorithm, and "alias" and "alias2" as its aliases.
> 
> List of actions in the order that they are executed while deserializing the provider:
> 
> put("Alg.Alias.MessageDigest.alias2", "alias")
> put("Alg.Alias.MessageDigest.alias", "alg")
> put("MessageDigest.alg", "class1")
> 
> After deserialization there will be two Service instances: one has "alias" as its algorithm and "alias2" as its alias, and the other has "alg" as its algorithm and "alias" as its alias. The former instance is invalid and reachable by "alias2" only, and the latter is valid and reachable by "alg" or "alias".
> 
> 2.3 - Algorithm case-insensitive collision between Provider::putService and Provider::put
> 
> Ordered list of actions:
> 
> put("MessageDigest.ALG", "class1")
> putService(new Service(provider, "MessageDigest", "alg", "class2", null, null))
> 
> The previous list of actions creates two Service instances, from which the one using "class2" as its class name is visible. However, the Properties map has entries for both services.
> 
> List of actions in the order that they are executed while deserializing the provider:
> 
> put("MessageDigest.alg", "class2")
> put("MessageDigest.ALG", "class1")
> 
> After deserialization, only the Service instance that has "class1" as its class name is available.
> 
> This case is related to the ServicesConsistency::testCurrentAPIServicesOverride test.
> 
> 2.4 - Alias collision between Provider::putService and Provider::put
> 
> putService(new Service(provider, "MessageDigest", "alg1", "class1", List.of("alias"), null))
> put("MessageDigest.alg2", "class2")
> put("Alg.Alias.MessageDigest.alias", "alg2")
> 
> The previous list of actions creates two service instances, from which the one using "class1" as its class name is visible by "alias". However, the Properties map has the entry "Alg.Alias.MessageDigest.alias" associated with the service instance using "class2" as its class name.
> 
> List of actions executed while deserializing the provider (in any order):
> 
> put("MessageDigest.alg1", "class1")
> put("MessageDigest.alg2", "class2")
> put("Alg.Alias.MessageDigest.alias", "alg2")
> 
> After deserialization, the Service instance using "class2" as its class name is the one identified by the alias "alias".
> 
> This same inconsistency may occur with the algorithm instead of the alias.
> 
> This case is related to the ServicesConsistency::legacyAPIServicesOverride test.
> 
> 2.5 - Overwrites of algorithms with aliases
> 
> Ordered list of actions:
> 
> put("MessageDigest.alg1", "class1")
> put("Alg.Alias.MessageDigest.alias1", "alg1")
> put("MessageDigest.alg2", "class2")
> put("Alg.Alias.MessageDigest.alg1", "alg2")
> 
> The previous list of actions creates two service instances, one that has "alg1" as its algorithm, "class1" as its class name and "alias1" as its alias, and the other that has "alg2" as its algorithm, "class2" as its class name and "alg1" as its alias.
> 
> List of actions in the order that they are executed while deserializing the provider:
> 
> put("MessageDigest.alg2", "class2")
> put("Alg.Alias.MessageDigest.alg1", "alg2")
> put("MessageDigest.alg1", "class1")
> put("Alg.Alias.MessageDigest.alias1", "alg1")
> 
> After deserialization, a single Service instance is created. This instance has "alg2" as its algorithm, "class1" as its class name, and "alg1" and "alias1" as its aliases.
> 
> This case is related to the ServicesConsistency::testLegacyAPIAliasCannotBeAlgorithm test.
> 
> #### 3 - Other bugs
> 
> 3.1 - Invalid services (without a class name) can be returned in Provider::getService, even when they are removed from the legacyMap [7]. This case is reflected in the ServicesConsistency::testInvalidServiceNotReturned test.
> 
> 3.2 - Methods Provider::implMerge and Provider::implCompute pass a "null" value as the 2nd parameter to Provider::parseLegacy and a remove action [8]. In the case of an alias, Provider::parseLegacy will throw a NullPointerException here [9]. This issue has been introduced by JDK-8276660, and is reflected in the tests ServicesConsistency::testComputeDoesNotThrowNPE and ServicesConsistency::testMergeDoesNotThrowNPE.
> 
> Note: we might be overlooking more bugs, as we decided to go with a new implementation at this point.
> 
> ### Proposal
> 
> We replaced the mechanism through which Service instances are organized inside a Provider, while maintaining the existing APIs to store and fetch services. These APIs are internally called Legacy and Current. The solution was designed to follow the principles of avoiding bottlenecks for service map readers (lock-free, thread-safe), ensuring consistency after Providers deserialization, ensuring consistency between the Provider's properties map and the actual services, enforcing consistency between the Legacy and Current APIs, and maintaining previous behavior to the maximum extent possible.
> 
> What follows is a description of the most relevant design choices:
> 
> 1 - Properties map synchronization: what you see on the Properties map is what you get from the internal services map
> 
> Adding, modifying or removing a service has a direct or indirect impact on the Properties map to enforce consistency. For example, adding an uppercase entry may overwrite a previous lowercase one. While this behavior is different from a regular Properties structure, having both entries would break synchronization with the internal services map (which is case insensitive) and is problematic for serialization. Other cases, such as adding entries by aliases, are also handled and canonicalized.
> 
> 2 - The Current API (Provider::putService) has preference over the Legacy API (Provider::put).
> 
> We kept the preference of Provider::getService and Provider::getServices methods for Current API services over Legacy API counterparts. However, the internal map is now unified and Legacy services may be overwritten ?notice that the opposite is not possible?. This was redesigned considering that there is a single Properties map, and we aim to keep it aligned to the internal services map. For expected behavior between the Legacy and Current APIs, we suggest looking at the ServicesConsistency::testLegacyAPIServicesOverride and ServicesConsistency::testCurrentAPIServicesOverride tests.
> 
> 3 - Copy-on-write strategy for Legacy API service changes
> 
> We implemented a copy-on-write strategy that reminds of the one before JDK-8276660 but has a key difference: the new implementation is lock-free and faster from a service readers point of view. This strategy makes it possible to have service consistency in multi-threaded scenarios, and fix many of the concurrency bugs previously described. In terms of time consistency, we do not enforce that constraint between different services obtained from Provider::getServices. In other words, the Set<Service> returned may have an old version of service A and a new version of service B, even when the change to service A was applied first. We consider that it is not worth paying a synchronization cost for this type of consistency. Notice that Current API services do not require this approach because they are immutable: once added, they cannot be changed.
> 
> 4 - Lock-free Provider::getServices
> 
> The Provider::getServices method is optimized for service readers with a cached set and a lock-free implementation.
> 
> ## SunNativeProvider
> 
> Changes were introduced to make the SunNativeProvider security provider use the Provider::putService API to register services, instead of the legacy Provider::putAll. This was the only security provider in OpenJDK using a non-Provider::putService API. While this change does not have any observable implications, it is in the interest of a better code ?and sets a better example? to align it with the other OpenJDK security providers. In our assessment, these are the OpenJDK providers using the Providers::putService API: SunJCE, SunPKCS11, SunRsaSign, SunEC, SUN, SunJSSE, SunMSCAPI, XMLDSigRI, JdkLDAP, JdkSASL, SunJGSS, SunPCSC, Apple and SunJarVerification.
> 
> ## Testing
> 
> As part of our testing, we observed no regressions in the following test categories:
> 
>  * jdk:tier1
>  * jdk/java/security
>  * jdk/sun/security
> 
> Additionally, we introduced the following new regression tests:
> 
>  * jdk/sun/security/provider/ProvidersFilterTest.java
>  * jdk/java/security/Provider/ServicesConsistency.java
> 
> Finally, we extended the following tests:
> 
>  * jdk/tools/launcher/Settings.java
> 
> 
> This contribution is co-authored by Francisco Ferrari and Martin Balao.
> 
> --
> [1] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1332
> [2] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1289
> [3] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1340
> [4] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1145
> [5] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1181
> [6] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L976
> [7] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1285-L1301
> [8] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L999-L1016
> [9] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1146
> 
> -------------
> 
> Commit messages:
> - 8315487: Security Providers Filter
> 
> Changes: https://git.openjdk.org/jdk/pull/15539/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8315487
>  Stats: 4600 lines in 24 files changed: 4029 ins; 323 del; 248 mod
>  Patch: https://git.openjdk.org/jdk/pull/15539.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539
> 
> PR: https://git.openjdk.org/jdk/pull/15539


From rhalade at openjdk.org  Wed Nov  8 22:47:21 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 8 Nov 2023 22:47:21 GMT
Subject: RFR: 8318759: Add four DigiCert root certificates
Message-ID: <3dYap7SRuxGyo7B8f8kXuq_2GJ4RvfPsmEZtavYwKGk=.2ed017bb-df9e-4744-98f9-a32147bb3a55@github.com>

This PR is to add 4 new TLS root certificates from Digicert, Inc. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.


The release-note is at [JDK-8319243](https://bugs.openjdk.org/browse/JDK-8319243)

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

Commit messages:
 - 8318759: Add four DigiCert root certificates

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

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


From hchao at openjdk.org  Thu Nov  9 01:02:16 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 9 Nov 2023 01:02:16 GMT
Subject: RFR: 8319670: Improve comments describing system properties for TLS
 server and client for max chain length
Message-ID: <J_mQE3PqkPrfyesKWQLmrC0ZP8dfRfJAVH-GT04u67s=.b2572470-b300-42ad-96fb-7c950ceb50a2@github.com>

Please review the comment change in SSLConfiguration class that describes TLS related system properties used to enforce certificate chain length. Thanks.

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

Commit messages:
 - Improve comments describing system properties for TLS server and client for max chain length

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

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


From mullan at openjdk.org  Thu Nov  9 19:06:09 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Nov 2023 19:06:09 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <cH8zLTQEcXTcdp47d0zgzoP_8TJSOE_WX062acQ9skw=.6f3d04a0-789c-4d0c-b9c7-ca41e265dae2@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
 <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
 <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjk
 SA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>
 <2Ofw53W_fxl3heGu4DBipfeuagynox2dfYrMaBqFun0=.b714ad70-9528-4987-950c-1a39ad5ec9a2@github.com>
 <cH8zLTQEcXTcdp47d0zgzoP_8TJSOE_WX062acQ9skw=.6f3d04a0-789c-4d0c-b9c7-ca41e265dae2@github.com>
Message-ID: <sw9RlcRimHKfwAV3Z5OBRlcCzGWbosbHNuzXmS1-TWk=.ce4fe1b7-7d34-4c26-864f-c6fc2918d16b@github.com>

On Wed, 8 Nov 2023 04:18:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The choice of 8 for the client is mostly based on different processing requirements and use cases for TLS client vs server certificate chains. If we see evidence that 8 is too low, we can always consider adjusting it.
>
> I'm not sure if the number 8 or 10 really make a good difference in practice.  No matter 8 or 10,  if customers need lower value, they can always consider adjusting it.  My concern is mainly about compatibility issues.  If you want to keep the behavior changes, as there is potential compatibility issue, please feel free to describe the behavior change in release note and CSR if you would like.

Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length [is 5 non-self-issued intermediate CA certificates](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/cert/PKIXBuilderParameters.html#setMaxPathLength(int)), so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server might accept, which sometimes happens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1388466148


From mullan at openjdk.org  Thu Nov  9 19:37:56 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Nov 2023 19:37:56 GMT
Subject: RFR: 8318479: [jmh] the test security.CacheBench  failed for
 multiple threads run
In-Reply-To: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
References: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
Message-ID: <JbDAyIvwl_snpjYq6QuK97bmkAwWJznMj5XMN8DZ96g=.29df8667-6c20-4c56-9e0d-5d24bde70d68@github.com>

On Mon, 23 Oct 2023 16:23:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove the hardcoded maximum heap size.
> 
> Verified that the benchmark now passes with 100 threads given sufficient heap:
> 
> make test TEST=micro:CacheBench MICRO="OPTIONS=-t 100;JAVA_OPTIONS=-Xmx16g"

Looks ok to me but I would request a review from @cl4es since he introduced the limit in https://github.com/openjdk/jdk/pull/9189.

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

PR Comment: https://git.openjdk.org/jdk/pull/16315#issuecomment-1804504375


From mullan at openjdk.org  Thu Nov  9 20:11:59 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Nov 2023 20:11:59 GMT
Subject: RFR: 8319670: Improve comments describing system properties for
 TLS server and client for max chain length
In-Reply-To: <J_mQE3PqkPrfyesKWQLmrC0ZP8dfRfJAVH-GT04u67s=.b2572470-b300-42ad-96fb-7c950ceb50a2@github.com>
References: <J_mQE3PqkPrfyesKWQLmrC0ZP8dfRfJAVH-GT04u67s=.b2572470-b300-42ad-96fb-7c950ceb50a2@github.com>
Message-ID: <YgPGQHO_NfqWoUy7cbTLmwCemmWizMRtieZDbUdCfDI=.c04f3c53-6da8-4a9e-8b74-5f06d5d67c01@github.com>

On Wed, 8 Nov 2023 23:34:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the comment change in SSLConfiguration class that describes TLS related system properties used to enforce certificate chain length. Thanks.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16576#pullrequestreview-1723413400


From hchao at openjdk.org  Thu Nov  9 20:24:05 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 9 Nov 2023 20:24:05 GMT
Subject: RFR: 8319670: Improve comments describing system properties for
 TLS server and client for max chain length
In-Reply-To: <YgPGQHO_NfqWoUy7cbTLmwCemmWizMRtieZDbUdCfDI=.c04f3c53-6da8-4a9e-8b74-5f06d5d67c01@github.com>
References: <J_mQE3PqkPrfyesKWQLmrC0ZP8dfRfJAVH-GT04u67s=.b2572470-b300-42ad-96fb-7c950ceb50a2@github.com>
 <YgPGQHO_NfqWoUy7cbTLmwCemmWizMRtieZDbUdCfDI=.c04f3c53-6da8-4a9e-8b74-5f06d5d67c01@github.com>
Message-ID: <rXkLKcikOz7JlgbpGDQMvQbx9Ql7y0fnbpF40q-Hh1Q=.a6168646-496e-49ad-9a20-95bc349367ef@github.com>

On Thu, 9 Nov 2023 20:09:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review the comment change in SSLConfiguration class that describes TLS related system properties used to enforce certificate chain length. Thanks.
>
> Marked as reviewed by mullan (Reviewer).

@seanjmullan Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/16576#issuecomment-1804616132


From hchao at openjdk.org  Thu Nov  9 20:24:06 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 9 Nov 2023 20:24:06 GMT
Subject: Integrated: 8319670: Improve comments describing system properties for
 TLS server and client for max chain length
In-Reply-To: <J_mQE3PqkPrfyesKWQLmrC0ZP8dfRfJAVH-GT04u67s=.b2572470-b300-42ad-96fb-7c950ceb50a2@github.com>
References: <J_mQE3PqkPrfyesKWQLmrC0ZP8dfRfJAVH-GT04u67s=.b2572470-b300-42ad-96fb-7c950ceb50a2@github.com>
Message-ID: <o_hrsq3-FWSZtWCyi6aKVUc3IqIqVgemoIEjIqR7R8g=.4b88db32-c8d7-4ec7-a1c9-4be6c3a8bd95@github.com>

On Wed, 8 Nov 2023 23:34:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the comment change in SSLConfiguration class that describes TLS related system properties used to enforce certificate chain length. Thanks.

This pull request has now been integrated.

Changeset: a95062b3
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a95062b39a431b4937ab6e9e73de4d2b8ea1ac49
Stats:     29 lines in 1 file changed: 14 ins; 5 del; 10 mod

8319670: Improve comments describing system properties for TLS server and client for max chain length

Reviewed-by: mullan

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

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


From kdriver at openjdk.org  Thu Nov  9 20:42:59 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Nov 2023 20:42:59 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
Message-ID: <t1kezS1X40h3V4g0XaSOZ_K4CGo5XGg8yB7QpiUF7Zo=.3ab26105-bdd6-44e7-ba89-a302cdd97000@github.com>

On Tue, 7 Nov 2023 20:04:11 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.

test/jdk/ProblemList.txt line 632:

> 630: sun/security/pkcs11/KeyStore/Basic.java                         8295343 generic-all
> 631: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java            8316183 linux-ppc64le
> 632: sun/security/pkcs11/Provider/MultipleLogins.sh                  8319128 linux-aarch64

At least for me, I'm not familiar enough with this test previously to know why it was a shell script before. Can you elaborate a little? I also assume this is an "active" problem list from which you're removing this line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1388559042


From kdriver at openjdk.org  Thu Nov  9 20:47:02 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Nov 2023 20:47:02 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>

On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

Marked as reviewed by kdriver (Committer).

src/java.base/share/classes/java/net/JarURLConnection.java line 129:

> 127:  * JAR files retrieved by this class might get cached for performance reasons which can result
> 128:  * in unexpected behavior if the JAR files are modified while being read using this class.
> 129:  * If such behavior is undesirable, please use the {@link URLConnection#setUseCaches(boolean)} method to disable caching.

consider a manual line wrap here, or is this ~80 chars?

src/java.base/share/classes/java/util/zip/ZipFile.java line 104:

> 102:  * being returned due to internal caching.
> 103:  *
> 104:  * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/")

consider a manual line wrap in these as well, or is this ~80 chars?

src/jdk.zipfs/share/classes/module-info.java line 303:

> 301:  * may occur such as metadata or content from the later entry being returned due to internal caching.
> 302:  *
> 303:  * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/")

consider a manual line wrap in these as well, or is this ~80 chars?

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

PR Review: https://git.openjdk.org/jdk/pull/16424#pullrequestreview-1723465685
PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1388560373
PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1388561727
PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1388562238


From kdriver at openjdk.org  Thu Nov  9 20:48:59 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Nov 2023 20:48:59 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
Message-ID: <bw4MrtoVF_lFCmaQqaePl8HYRHJB7QLLI9fRba31bis=.07760f36-4f0b-424e-8c85-0081c3929621@github.com>

On Fri, 3 Nov 2023 22:18:22 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 properti...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319332: use Path::of(URI) to deal with file URLs
>   
>   Instead of the previously introduced FileURLConnection::getFile(), use
>   Path::of(URI), leaving some file URL corner-cases without relative
>   imports support.
>   
>   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>   
>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

src/java.base/share/classes/java/security/Security.java line 34:

> 32: import java.nio.file.InvalidPathException;
> 33: import java.nio.file.Path;
> 34: import java.util.*;

Wildcard import may be undesirable; include individual classes? I know this is just moving lines, but I thought I'd mention it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1388564926


From kdriver at openjdk.org  Thu Nov  9 20:53:58 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 9 Nov 2023 20:53:58 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
Message-ID: <Fg0O-BL3tYg7h2ICLCsKhgXYeTZbfh-OJIdKa2x3ivc=.0c8b1783-091e-44b7-91be-c8befee2080c@github.com>

On Fri, 3 Nov 2023 22:18:22 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 properti...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319332: use Path::of(URI) to deal with file URLs
>   
>   Instead of the previously introduced FileURLConnection::getFile(), use
>   Path::of(URI), leaving some file URL corner-cases without relative
>   imports support.
>   
>   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>   
>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

Marked as reviewed by kdriver (Committer).

see above

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

PR Review: https://git.openjdk.org/jdk/pull/16483#pullrequestreview-1723471542
PR Review: https://git.openjdk.org/jdk/pull/16483#pullrequestreview-1723474008


From fferrari at openjdk.org  Thu Nov  9 21:25:00 2023
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 9 Nov 2023 21:25:00 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <bw4MrtoVF_lFCmaQqaePl8HYRHJB7QLLI9fRba31bis=.07760f36-4f0b-424e-8c85-0081c3929621@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
 <bw4MrtoVF_lFCmaQqaePl8HYRHJB7QLLI9fRba31bis=.07760f36-4f0b-424e-8c85-0081c3929621@github.com>
Message-ID: <9pIfoX5c6r0zZiRdWiTidKZt-2OSsw6od_hYHx-vznY=.d04b3324-71d2-4e78-9d01-0a0d36e18394@github.com>

On Thu, 9 Nov 2023 20:46:31 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8319332: use Path::of(URI) to deal with file URLs
>>   
>>   Instead of the previously introduced FileURLConnection::getFile(), use
>>   Path::of(URI), leaving some file URL corner-cases without relative
>>   imports support.
>>   
>>   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>>   
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>
> src/java.base/share/classes/java/security/Security.java line 34:
> 
>> 32: import java.nio.file.InvalidPathException;
>> 33: import java.nio.file.Path;
>> 34: import java.util.*;
> 
> Wildcard import may be undesirable; include individual classes? I know this is just moving lines, but I thought I'd mention it.

@driverkt: personally, I also prefer avoiding wildcard imports, but please note that by removing them, we would end up with 12 for `java.util.*`, 3 for `java.io.*`, and 3 for `sun.security.jca.*`:

import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;
import java.net.URI;
import java.net.URL;
import java.nio.file.Files;
import java.nio.file.InvalidPathException;
import java.nio.file.Path;
import java.util.Arrays;
import java.util.Collections;
import java.util.Enumeration;
import java.util.HashSet;
import java.util.Hashtable;
import java.util.LinkedList;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import java.util.Properties;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;

import jdk.internal.access.JavaSecurityPropertiesAccess;
import jdk.internal.access.SharedSecrets;
import jdk.internal.event.EventHelper;
import jdk.internal.event.SecurityPropertyModificationEvent;
import jdk.internal.util.StaticProperty;
import sun.security.jca.GetInstance;
import sun.security.jca.ProviderList;
import sun.security.jca.Providers;
import sun.security.util.Debug;
import sun.security.util.PropertyExpander;


If no further concerns are raised, I will make this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1388597897


From weijun at openjdk.org  Thu Nov  9 21:38:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Nov 2023 21:38:57 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
Message-ID: <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>

On Fri, 3 Nov 2023 22:18:22 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 properti...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319332: use Path::of(URI) to deal with file URLs
>   
>   Instead of the previously introduced FileURLConnection::getFile(), use
>   Path::of(URI), leaving some file URL corner-cases without relative
>   imports support.
>   
>   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>   
>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

My major concern is that this does not look like a properties file anymore, that the same key have multiple values and you use an undocumented (?) format "key value". That said, this is a clever hack and I wonder why we hadn't used it for `security.provider`s.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1804721609


From redestad at openjdk.org  Thu Nov  9 22:22:56 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Nov 2023 22:22:56 GMT
Subject: RFR: 8318479: [jmh] the test security.CacheBench  failed for
 multiple threads run
In-Reply-To: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
References: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
Message-ID: <OW1gLMjExgIx2PpM_uoT7US5vG1oCGXV-p-vdg0Vpg4=.17a679e1-ddf5-42bc-9bea-6a2a9e120ece@github.com>

On Mon, 23 Oct 2023 16:23:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove the hardcoded maximum heap size.
> 
> Verified that the benchmark now passes with 100 threads given sufficient heap:
> 
> make test TEST=micro:CacheBench MICRO="OPTIONS=-t 100;JAVA_OPTIONS=-Xmx16g"

Marked as reviewed by redestad (Reviewer).

> Looks ok to me but I would request a review from @cl4es since he introduced the limit in #9189.

The `-Xmx1g` was there before #9189 (I only modified the line to add `value = 3` to reduce number of forks).

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

PR Review: https://git.openjdk.org/jdk/pull/16315#pullrequestreview-1723600080
PR Comment: https://git.openjdk.org/jdk/pull/16315#issuecomment-1804774258


From xuelei at openjdk.org  Fri Nov 10 06:52:12 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 10 Nov 2023 06:52:12 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <sw9RlcRimHKfwAV3Z5OBRlcCzGWbosbHNuzXmS1-TWk=.ce4fe1b7-7d34-4c26-864f-c6fc2918d16b@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
 <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
 <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjk
 SA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>
 <2Ofw53W_fxl3heGu4DBipfeuagynox2dfYrMaBqFun0=.b714ad70-9528-4987-950c-1a39ad5ec9a2@github.com>
 <cH8zLTQEcXTcdp47d0zgzoP_8TJSOE_WX062acQ9skw=.6f3d04a0-789c-4d0c-b9c7-ca41e265dae2@github.com>
 <sw9RlcRimHKfwAV3Z5OBRlcCzGWbosbHNuzXmS1-TWk=.ce4fe1b7-7d34-4c26-864f-c6fc2918d16b@github.com>
Message-ID: <r5oLaJgLh2N3EMnnJr8gbDapdtopbjDvQnjkl0EgXVE=.6115d427-1148-4471-aa7b-076789061940@github.com>

On Thu, 9 Nov 2023 19:03:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I'm not sure if the number 8 or 10 really make a good difference in practice.  No matter 8 or 10,  if customers need lower value, they can always consider adjusting it.  My concern is mainly about compatibility issues.  If you want to keep the behavior changes, as there is potential compatibility issue, please feel free to describe the behavior change in release note and CSR if you would like.
>
> Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length [is 5 non-self-issued intermediate CA certificates](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/cert/PKIXBuilderParameters.html#setMaxPathLength(int)), so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server or client might accept, which sometimes happens.

Good point about the setMaxPathLength() limitation.  It looks like there might be an issue when the interactivities of setMaxPathLength(and its default value) and the properties defined here are not considered.  For example, what if the property is set to 8, while the setMaxPathLength is of value 5?  For the "PKIX" trust manager, per your description, if the property is set to 8, but 5 is the limit actually.  It looks like a weird behavior to me.  If I remember correctly, the "SunX509" trust manager does not use PKIXBuilderParameters, while the "PKIX" trust manager does.  It might be not the behavior we'd like to have that property 8 work for "SunX509" but not for "PKIX" trust manager.

Anyway, it might be better to look into the interactive behaviors among the properties and setMaxPathLength/default value.

> Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length [is 5 non-self-issued intermediate CA certificates](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/cert/PKIXBuilderParameters.html#setMaxPathLength(int)), so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server or client might accept, which sometimes happens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1388988092


From fferrari at openjdk.org  Fri Nov 10 11:29:02 2023
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 10 Nov 2023 11:29:02 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
 <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
Message-ID: <vLM7PEq95m6phjVynkA_xp5hWxmDPG5PRZ1L1BhQDJY=.08fe1fae-ef95-4cd9-8e0c-b04bdbf81b1c@github.com>

On Thu, 9 Nov 2023 21:36:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8319332: use Path::of(URI) to deal with file URLs
>>   
>>   Instead of the previously introduced FileURLConnection::getFile(), use
>>   Path::of(URI), leaving some file URL corner-cases without relative
>>   imports support.
>>   
>>   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>>   
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>
> My major concern is that this does not look like a properties file anymore, that the same key have multiple values and you use an undocumented (?) format "key value". That said, this is a clever hack and I wonder why we hadn't used it for `security.provider`s.

Hi @wangweij,

----

> My major concern is that this does not look like a properties file anymore, that the same key have multiple values and [?]

We understand your concern. While the existing syntax has not changed, the special semantics assigned to _include_ properties set them intentionally apart. Perhaps we should refer to them as directives, instead of special properties. More than having multiple values, it's that they have effect at properties processing time and over properties themselves. In any case, we agree that users who take advantage of this feature will need to read about this behavior.

We considered the following to make it more intuitive:

1. By making a purposeful distinction between `'='` and `' '` throughout the documentation of this feature, we can stress the difference and gain some clarity. For example:

   ```properties
   key1=value1
   key2=value2

   include other/file.properties

   key3=value3
   ```

2. The word "include" is suggestive of action and, as it does not carry any security related meaning, looks orthogonal to the security domain. If users relate this word to a metaproperty, its special semantics and effect would be within expected. Having a recognizable path as a value for this property should be congruent with including something external.

3. There are several examples of software that use this concept of including an external source into a configuration file, and most of them use a variation of the word "include". To name a few: [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include). For users with software development experience, "include" might sound familiar to the C preprocessor and macros.

----

> [?] you use an undocumented (?) format "key value". [?]

While this is probably not the most extended syntax in use, it is documented in [`java.util.Properties::load(Reader)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29):
> _The key contains all of the characters in the line starting with the first non-whitespace character and up to, but not including, the first unescaped '=', ':', **or white space character** other than a line terminator. All of these key termination characters may be included in the key by escaping them with a preceding backslash character;_

----

> [?] That said, this is a clever hack and I wonder why we hadn't used it for `security.provider`s.

Do you mean something like the following?


key1=value1

register.security.provider SUN
register.security.provider SunRsaSign
register.security.provider SunEC
register.security.provider SunJSSE
register.security.provider SunJCE
register.security.provider SunJGSS
register.security.provider SunSASL
register.security.provider XMLDSig
register.security.provider SunPCSC
register.security.provider JdkLDAP
register.security.provider JdkSASL

key2=value2

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1805553323


From djelinski at openjdk.org  Fri Nov 10 12:51:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 Nov 2023 12:51:56 GMT
Subject: RFR: 8318479: [jmh] the test security.CacheBench  failed for
 multiple threads run
In-Reply-To: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
References: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
Message-ID: <Ycd6zUOVw6M97OUXbZeOxABL0_7uFI5ayFV1Am4vs1c=.00326a36-fea9-4078-893a-d79a2462fb0c@github.com>

On Mon, 23 Oct 2023 16:23:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove the hardcoded maximum heap size.
> 
> Verified that the benchmark now passes with 100 threads given sufficient heap:
> 
> make test TEST=micro:CacheBench MICRO="OPTIONS=-t 100;JAVA_OPTIONS=-Xmx16g"

I introduced the limit originally; I think I needed it because the default limit on my machine was too low to run the benchmark with the largest cache size.

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

PR Comment: https://git.openjdk.org/jdk/pull/16315#issuecomment-1805675721


From duke at openjdk.org  Fri Nov 10 15:32:00 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Fri, 10 Nov 2023 15:32:00 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>
Message-ID: <tIUSPTDLkR4mMnIM8gnisbeFtukw07Bp9QbQMfMY8Bo=.fde22211-0808-4198-b24b-f53db7a18eb1@github.com>

On Thu, 9 Nov 2023 20:41:22 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> src/java.base/share/classes/java/net/JarURLConnection.java line 129:
> 
>> 127:  * JAR files retrieved by this class might get cached for performance reasons which can result
>> 128:  * in unexpected behavior if the JAR files are modified while being read using this class.
>> 129:  * If such behavior is undesirable, please use the {@link URLConnection#setUseCaches(boolean)} method to disable caching.
> 
> consider a manual line wrap here, or is this ~80 chars?

will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1389545818


From duke at openjdk.org  Fri Nov 10 15:36:02 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Fri, 10 Nov 2023 15:36:02 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>
Message-ID: <PnpvCBIfmDb8SFgkLB606Tcj8SJCDl7cpktww9489bE=.085af6b1-72ef-4224-8e7f-b00a03bd3dac@github.com>

On Thu, 9 Nov 2023 20:42:52 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 104:
> 
>> 102:  * being returned due to internal caching.
>> 103:  *
>> 104:  * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/")
> 
> consider a manual line wrap in these as well, or is this ~80 chars?

will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1389551613


From duke at openjdk.org  Fri Nov 10 15:44:19 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Fri, 10 Nov 2023 15:44:19 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed more line breaks
 - fixed line breaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16424/files
  - new: https://git.openjdk.org/jdk/pull/16424/files/8ee093c0..919666a0

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

  Stats: 46 lines in 5 files changed: 15 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/16424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16424/head:pull/16424

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


From duke at openjdk.org  Fri Nov 10 15:44:20 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Fri, 10 Nov 2023 15:44:20 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <HPK7Z0KnOSEH4GjxFwmMty8TqR9A-chEGRU3qyp6sIA=.d688a5c1-0661-4a90-bd75-fd881f636333@github.com>
Message-ID: <lEYfsqaWWWiLEPBo5mUTSVswxvwhrH8niTRb4JNnJ9E=.41e40050-2289-4357-8368-50d6fb1a33a7@github.com>

On Thu, 9 Nov 2023 20:43:25 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed more line breaks
>>  - fixed line breaks
>
> src/jdk.zipfs/share/classes/module-info.java line 303:
> 
>> 301:  * may occur such as metadata or content from the later entry being returned due to internal caching.
>> 302:  *
>> 303:  * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/")
> 
> consider a manual line wrap in these as well, or is this ~80 chars?

will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1389556168


From andrew at openjdk.org  Fri Nov 10 16:42:58 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 10 Nov 2023 16:42:58 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
Message-ID: <F2_U4U1_xoRxp039irV-25jrvLfq4FfpmdHYAmeuAKg=.238970b2-bc1e-421e-9d8d-621cb6b8ef3b@github.com>

On Fri, 3 Nov 2023 22:18:22 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 properti...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8319332: use Path::of(URI) to deal with file URLs
>   
>   Instead of the previously introduced FileURLConnection::getFile(), use
>   Path::of(URI), leaving some file URL corner-cases without relative
>   imports support.
>   
>   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>   
>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

My main concern is with the test case, especially as the output it produces in the logs is pretty much restricted to processes stopping and starting.  That's not new to this change, but the greater weight placed on the test by this change does exacerbate this problem. I'm not sure how one would go about debugging a problem from that output.

The code itself is very sparse in comments. In the case of the test, it would help if at least each method could state what it was intending to test.  In particular, I don't see a test of how properties from one test file override those from another, and how the ordering affects this.

For example, with an external property file `extra.properties` containing `a=c`, the end result of the following:

~~~
a=b
include extra.properties
~~~
would be `a=c`, whereas:
~~~
include extra.properties
a=b
~~~
would be `a=b`. 

I don't see any test here that confirms that a property ends up set to an expected value, though I may be missing this because the structure of the test is quite hard to follow.

Also, is `handeRequest` deliberate or a typo of `handleRequest`?

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

PR Review: https://git.openjdk.org/jdk/pull/16483#pullrequestreview-1725169855


From andrew at openjdk.org  Fri Nov 10 16:49:00 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 10 Nov 2023 16:49:00 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
 <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
Message-ID: <AtTyN5QY45UnBaNB5IuA7DfeeXcPCgvn6LqTxVxJLEU=.1ba97f9d-a710-4e94-8338-549a5018ae22@github.com>

On Thu, 9 Nov 2023 21:36:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> My major concern is that this does not look like a properties file anymore, that the same key have multiple values and you use an undocumented (?) format "key value". That said, this is a clever hack and I wonder why we hadn't used it for `security.provider`s.

This surprised me too when I first read the patch, and I had to go back to the specification of the `Properties` file. Although the convention tends to be `key=value`, it seems the specification allows for `key:value` and `key value` as well.

By "the same key has multiple values", I assume you mean the key "import"? The implementation overrides `put` and swallows these `include` lines so they are never actually added as keys and values. Were they to be added, each subsequent one would just override the one before, as is the intended behaviour of the existing `-Djava.security.properties` extra file which can be used to override `java.security` properties on the command line.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1806069303


From prappo at openjdk.org  Fri Nov 10 16:49:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 Nov 2023 16:49:05 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v8]
In-Reply-To: <KDDFjGNV-Nlx1zJrkJraLZSvcDr2P_rfrwH7B1Ww4MY=.f29b24f6-1e3a-49cf-a44b-f74be434fd97@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <KDDFjGNV-Nlx1zJrkJraLZSvcDr2P_rfrwH7B1Ww4MY=.f29b24f6-1e3a-49cf-a44b-f74be434fd97@github.com>
Message-ID: <RupaKdeBSaeoAVQCYrIoaWQvgSgjiCrgWG31Kb6GaAo=.a53e1532-4e7a-4eaf-95b4-2acda9034bc2@github.com>

On Tue, 7 Nov 2023 07:58:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8ac67427...155fedba

Here's a benchmark which was performed after the most recent merge (155fedb) with openjdk/jdk master. Factor it in your review.

In addition to the new benchmarks, I included some benchmarks from the security area, which might be affected by this PR. If security-dev (cc'ed earlier) thinks I should benchmark anything else, please let me know.

To reduce horizontal scrolling and make the table easier on the eyes, leading `openjdk.bench.java.` was removed from the name of each benchmark; then leading `math` and `security` were replaced with `m` and `s` respectively.

|Benchmark                                                                                  |  Linux aarch64|  Linux x64|  MacOSX aarch64|  MacOSX x64|  Windows x64|
|:------------------------------------------------------------------------------------------|--------------:|----------:|---------------:|-----------:|------------:|
|m.BigIntegerCompareTo.testCompareTo-group:L                                                |         25.59%|     41.63%|          31.77%|      29.87%|       41.60%|
|m.BigIntegerCompareTo.testCompareTo-group:M                                                |          1.67%|     -2.14%|          11.55%|      -8.86%|       -2.08%|
|m.BigIntegerCompareTo.testCompareTo-group:S                                                |         -9.48%|      1.85%|          -7.39%|      -1.13%|        2.47%|
|m.BigIntegerEquals.testEquals-group:L                                                      |          8.41%|     15.42%|          17.44%|      -6.24%|        4.32%|
|m.BigIntegerEquals.testEquals-group:M                                                      |         -0.59%|    -17.27%|           3.43%|     -25.37%|      -30.70%|
|m.BigIntegerEquals.testEquals-group:S                                                      |          5.62%|    -36.56%|          11.45%|     -29.62%|      -26.71%|
|m.BigIntegerHashCode.testHashCode-group:L                                                  |          0.01%|     78.80%|           0.01%|      70.25%|       78.70%|
|m.BigIntegerHashCode.testHashCode-group:M                                                  |          0.00%|     30.25%|          -0.03%|      20.46%|       27.40%|
|m.BigIntegerHashCode.testHashCode-group:S                                                  |          1.18%|     38.16%|           1.80%|      24.49%|       38.92%|
|m.BigIntegerParallelMultiply.multiply-n:1000000                                            |         -1.74%|      0.89%|           2.76%|       0.16%|        0.55%|
|m.BigIntegerParallelMultiply.multiply-n:10000000                                           |          0.22%|     -0.13%|           0.85%|      -1.90%|       -0.47%|
|m.BigIntegerParallelMultiply.multiply-n:100000000                                          |         -0.01%|     -2.28%|           0.31%|       2.51%|       -0.71%|
|m.BigIntegerParallelMultiply.parallelMultiply-n:1000000                                    |         -6.10%|      0.32%|           0.83%|       2.58%|        2.27%|
|m.BigIntegerParallelMultiply.parallelMultiply-n:10000000                                   |         -4.23%|     -2.49%|           1.54%|       0.94%|       -1.53%|
|m.BigIntegerParallelMultiply.parallelMultiply-n:100000000                                  |          0.07%|     -0.80%|           0.53%|       0.86%|        0.41%|
|m.BigIntegers.SmallShifts.testLeftShift-maxNumbits:128                                     |          2.83%|     -1.87%|          -0.49%|      -0.81%|       -0.13%|
|m.BigIntegers.SmallShifts.testLeftShift-maxNumbits:256                                     |         -1.38%|     -0.32%|          -0.48%|       0.07%|        0.25%|
|m.BigIntegers.SmallShifts.testLeftShift-maxNumbits:32                                      |          0.14%|      0.01%|           2.77%|       0.30%|       -0.81%|
|m.BigIntegers.SmallShifts.testRightShift-maxNumbits:128                                    |         -2.91%|      0.20%|          -2.99%|      -0.72%|        0.46%|
|m.BigIntegers.SmallShifts.testRightShift-maxNumbits:256                                    |         -2.35%|      0.02%|           1.56%|       0.54%|        3.65%|
|m.BigIntegers.SmallShifts.testRightShift-maxNumbits:32                                     |         -0.12%|     -0.70%|          -2.96%|       0.22%|       -0.89%|
|m.BigIntegers.testAdd                                                                      |         -0.05%|      1.36%|          -1.20%|       0.15%|        1.58%|
|m.BigIntegers.testGcd                                                                      |         -0.08%|      0.44%|           0.05%|      -0.08%|        0.12%|
|m.BigIntegers.testHugeToString                                                             |         -0.30%|     -0.58%|          -0.10%|      -0.47%|        1.25%|
|m.BigIntegers.testLargeToString                                                            |         -2.30%|     -0.36%|           0.01%|      -0.06%|        1.98%|
|m.BigIntegers.testLeftShift                                                                |          0.53%|      0.94%|          -0.12%|      12.72%|        0.09%|
|m.BigIntegers.testMultiply                                                                 |         -0.03%|      0.01%|          -0.37%|       0.19%|       -0.07%|
|m.BigIntegers.testRightShift                                                               |          0.45%|      0.17%|           0.13%|       0.06%|        0.62%|
|m.BigIntegers.testSmallToString                                                            |         -0.22%|     -3.08%|          10.58%|      -0.11%|       -0.14%|
|s.AlgorithmConstraintsPermits.permits-algorithm:DES                                        |          0.09%|     -0.03%|           0.00%|      -0.05%|        0.00%|
|s.AlgorithmConstraintsPermits.permits-algorithm:NULL                                       |          3.46%|     -0.00%|          -0.09%|      -0.25%|        0.05%|
|s.AlgorithmConstraintsPermits.permits-algorithm:SSLv3                                      |          0.18%|      0.00%|          -0.07%|       0.05%|       -0.78%|
|s.AlgorithmConstraintsPermits.permits-algorithm:TLS1_3                                     |         -3.55%|      0.01%|           0.19%|      -0.06%|        0.28%|
|s.CacheBench.get-size:20480-timeout:0                                                      |         -0.75%|      2.24%|           0.37%|      -0.06%|       -1.10%|
|s.CacheBench.get-size:20480-timeout:86400                                                  |         -0.28%|      0.11%|          -0.18%|       1.03%|        0.99%|
|s.CacheBench.get-size:204800-timeout:0                                                     |         -0.62%|     -1.72%|          -2.97%|      -0.50%|       -0.43%|
|s.CacheBench.get-size:204800-timeout:86400                                                 |          1.42%|     -0.73%|           0.17%|      -0.29%|        0.08%|
|s.CacheBench.get-size:5120000-timeout:0                                                    |          3.95%|      4.65%|           1.70%|      -1.18%|        3.32%|
|s.CacheBench.get-size:5120000-timeout:86400                                                |         -0.62%|      1.36%|          -0.12%|       0.78%|       -3.43%|
|s.CacheBench.put-size:20480-timeout:0                                                      |         -0.24%|      2.44%|          -0.55%|      -1.15%|        2.81%|
|s.CacheBench.put-size:20480-timeout:86400                                                  |         -0.25%|      1.56%|          -0.13%|      -0.21%|       -0.19%|
|s.CacheBench.put-size:204800-timeout:0                                                     |         -0.71%|     -1.07%|           0.19%|       0.12%|        0.42%|
|s.CacheBench.put-size:204800-timeout:86400                                                 |         -0.16%|      1.15%|           0.08%|      -0.17%|        0.85%|
|s.CacheBench.put-size:5120000-timeout:0                                                    |          0.67%|      2.10%|           2.44%|       1.80%|       -2.10%|
|s.CacheBench.put-size:5120000-timeout:86400                                                |          0.35%|      0.56%|          -1.37%|       0.17%|        1.14%|
|s.CacheBench.remove-size:20480-timeout:0                                                   |          3.87%|      0.52%|           0.92%|       0.35%|       -0.74%|
|s.CacheBench.remove-size:20480-timeout:86400                                               |          1.00%|      0.61%|           0.08%|       0.32%|       -1.49%|
|s.CacheBench.remove-size:204800-timeout:0                                                  |          3.90%|      0.86%|           1.37%|      -1.25%|       -0.62%|
|s.CacheBench.remove-size:204800-timeout:86400                                              |         -3.40%|      0.73%|          -0.11%|       0.10%|       -2.99%|
|s.CacheBench.remove-size:5120000-timeout:0                                                 |         -2.43%|     -3.88%|          -0.51%|       0.46%|        0.12%|
|s.CacheBench.remove-size:5120000-timeout:86400                                             |          3.82%|     -0.07%|          -0.36%|      -2.73%|       -1.58%|
|s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_AES_256_GCM_SHA384                 |         -0.19%|     -1.17%|           0.33%|      -5.94%|        2.67%|
|s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_DHE_DSS_WITH_AES_128_CBC_SHA256    |         -2.48%|      2.27%|           0.50%|      -1.16%|       -0.61%|
|s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_DHE_RSA_WITH_AES_256_CBC_SHA       |         -0.21%|     -1.97%|          -0.47%|      -0.20%|        0.00%|
|s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384|          1.30%|      1.64%|          -0.12%|      -3.01%|       -3.36%|
|s.DoPrivileged.test                                                                        |          0.34%|      0.02%|          -0.11%|       0.07%|       -4.00%|
|s.DoPrivileged.testInline                                                                  |         -0.34%|     -0.01%|          -0.04%|      14.05%|       -9.02%|
|s.GetContext.Deep.testNonPrivRecurse-depth:2                                               |         -0.19%|     -1.48%|          -1.63%|      -0.35%|        0.66%|
|s.GetContext.Deep.testNonPrivRecurse-depth:50                                              |          5.26%|     -0.67%|          -1.27%|       1.48%|       -0.64%|
|s.GetContext.Deep.testPrivInline-depth:2                                                   |         -5.64%|      1.09%|           0.36%|      -0.14%|       -0.43%|
|s.GetContext.Deep.testPrivInline-depth:50                                                  |          1.33%|     -2.29%|          -0.44%|       0.76%|       -1.06%|
|s.GetContext.Top.testNonPriv                                                               |          1.80%|      1.45%|          -0.85%|       0.44%|       -0.07%|
|s.GetContext.Top.testPriv                                                                  |         -4.01%|      1.43%|           0.38%|      -1.05%|       -0.31%|
|s.GetMessageDigest.cloneInstance-digesterName:SHA_1                                        |          2.12%|      0.49%|          -0.28%|      -0.07%|       -3.90%|
|s.GetMessageDigest.cloneInstance-digesterName:SHA_256                                      |          0.73%|     -0.40%|           0.25%|       0.73%|       -0.89%|
|s.GetMessageDigest.cloneInstance-digesterName:md5                                          |          0.53%|     -1.36%|           0.13%|      -0.13%|       -2.36%|
|s.GetMessageDigest.getInstance-digesterName:SHA_1                                          |         -2.08%|      1.18%|          -0.24%|      -2.59%|        0.30%|
|s.GetMessageDigest.getInstance-digesterName:SHA_256                                        |          1.58%|      0.86%|           0.18%|       0.56%|        3.53%|
|s.GetMessageDigest.getInstance-digesterName:md5                                            |         -1.74%|     -3.66%|          -0.20%|       0.01%|        7.36%|
|s.GetMessageDigest.getInstanceWithProvider-digesterName:SHA_1                              |          0.83%|     -0.51%|           0.11%|      -0.32%|        0.12%|
|s.GetMessageDigest.getInstanceWithProvider-digesterName:SHA_256                            |          0.90%|      1.06%|           0.14%|       2.48%|       -1.64%|
|s.GetMessageDigest.getInstanceWithProvider-digesterName:md5                                |         -0.05%|      1.61%|          -0.11%|      -0.13%|       -0.06%|
|s.HSS.test01.verify-test:RFC 8554 1                                                        |          1.00%|      0.45%|          -1.15%|      -0.03%|        0.57%|
|s.HSS.test02.verify-test:RFC 8554 2                                                        |         -0.18%|      0.33%|           0.76%|      -0.26%|        0.45%|
|s.HSS.test03.verify-test: h15_w8                                                           |         -0.09%|     -0.00%|          -0.23%|      -0.10%|       -0.73%|
|s.HSS.test04.verify-test: h20_w8                                                           |         -0.83%|     -0.02%|          -0.49%|       0.23%|        0.17%|
|s.HSS.test05.verify-test: h15_w4                                                           |          0.15%|      0.25%|           0.54%|       0.05%|       -0.21%|
|s.HSS.test06.verify-test: h20_w4                                                           |          0.00%|      0.33%|           2.65%|      -0.47%|        1.04%|
|s.HSS.test07.verify-test:h15_w4_h10_w4                                                     |          0.14%|      0.19%|           0.17%|      -0.48%|       -0.04%|
|s.HSS.test08.verify-test:h15_w4_h15_w4                                                     |          0.10%|      0.51%|          -0.38%|       0.12%|        0.59%|
|s.HSS.test09.verify-test:h20_w4_h10_w4                                                     |         -0.01%|      0.82%|          -0.12%|       0.37%|       -0.79%|
|s.HSS.test10.verify-test:h20_w4_h15_w4                                                     |         -0.12%|     -1.20%|          -0.09%|       0.04%|        1.02%|
|s.HSS.verify-test:noop                                                                     |         -1.78%|     -4.47%|          -3.98%|      -1.69%|       -5.32%|
|s.MessageDigests.digest-digesterName:SHA3_256-length:16384-provider:DEFAULT                |          0.00%|      0.02%|           0.02%|       0.04%|        0.36%|
|s.MessageDigests.digest-digesterName:SHA3_256-length:64-provider:DEFAULT                   |          0.08%|     -0.10%|           0.03%|      -0.37%|       -0.52%|
|s.MessageDigests.digest-digesterName:SHA3_512-length:16384-provider:DEFAULT                |          0.02%|      0.01%|           0.02%|       0.11%|        0.03%|
|s.MessageDigests.digest-digesterName:SHA3_512-length:64-provider:DEFAULT                   |         -0.22%|      0.03%|           0.03%|      -0.04%|        0.17%|
|s.MessageDigests.digest-digesterName:SHA_1-length:16384-provider:DEFAULT                   |         -0.01%|     -0.02%|           0.05%|       0.19%|       -0.03%|
|s.MessageDigests.digest-digesterName:SHA_1-length:64-provider:DEFAULT                      |          0.55%|     -0.70%|          -5.04%|      -0.02%|       -0.44%|
|s.MessageDigests.digest-digesterName:SHA_224-length:16384-provider:DEFAULT                 |          0.00%|     -0.01%|           0.08%|      -0.13%|        0.02%|
|s.MessageDigests.digest-digesterName:SHA_224-length:64-provider:DEFAULT                    |          1.11%|      0.06%|           0.97%|      -0.24%|        1.81%|
|s.MessageDigests.digest-digesterName:SHA_256-length:16384-provider:DEFAULT                 |          0.00%|     -0.01%|           0.03%|      -0.10%|        0.05%|
|s.MessageDigests.digest-digesterName:SHA_256-length:64-provider:DEFAULT                    |          0.31%|      0.05%|          -0.96%|      -0.60%|       -0.39%|
|s.MessageDigests.digest-digesterName:SHA_384-length:16384-provider:DEFAULT                 |         -0.01%|     -0.03%|           0.01%|      -0.08%|        0.08%|
|s.MessageDigests.digest-digesterName:SHA_384-length:64-provider:DEFAULT                    |          0.09%|     -0.46%|           2.90%|      -0.18%|       -0.27%|
|s.MessageDigests.digest-digesterName:SHA_512-length:16384-provider:DEFAULT                 |         -0.00%|     -0.02%|          -0.00%|       0.01%|        0.03%|
|s.MessageDigests.digest-digesterName:SHA_512-length:64-provider:DEFAULT                    |         -0.05%|     -0.76%|          -1.10%|       0.18%|        0.42%|
|s.MessageDigests.digest-digesterName:md5-length:16384-provider:DEFAULT                     |         -0.00%|     -0.01%|          -0.00%|       0.11%|       -0.00%|
|s.MessageDigests.digest-digesterName:md5-length:64-provider:DEFAULT                        |         -0.02%|      0.03%|           2.25%|      -1.43%|       -0.21%|
|s.MessageDigests.getAndDigest-digesterName:SHA3_256-length:16384-provider:DEFAULT          |          0.01%|      0.14%|           0.01%|       0.42%|       -0.13%|
|s.MessageDigests.getAndDigest-digesterName:SHA3_256-length:64-provider:DEFAULT             |          0.13%|      0.09%|           0.10%|      -0.00%|       -0.33%|
|s.MessageDigests.getAndDigest-digesterName:SHA3_512-length:16384-provider:DEFAULT          |         -0.04%|     -0.07%|          -0.05%|      -0.04%|        0.30%|
|s.MessageDigests.getAndDigest-digesterName:SHA3_512-length:64-provider:DEFAULT             |         -0.10%|     -0.15%|          -0.01%|      -0.59%|        0.27%|
|s.MessageDigests.getAndDigest-digesterName:SHA_1-length:16384-provider:DEFAULT             |         -0.02%|      0.02%|          -0.09%|      -0.01%|        0.06%|
|s.MessageDigests.getAndDigest-digesterName:SHA_1-length:64-provider:DEFAULT                |         -0.05%|      1.05%|           2.55%|       0.02%|       -0.01%|
|s.MessageDigests.getAndDigest-digesterName:SHA_224-length:16384-provider:DEFAULT           |         -0.15%|     -0.09%|          -0.14%|      -0.20%|        0.07%|
|s.MessageDigests.getAndDigest-digesterName:SHA_224-length:64-provider:DEFAULT              |          0.12%|      0.29%|           5.47%|      -0.02%|       -0.06%|
|s.MessageDigests.getAndDigest-digesterName:SHA_256-length:16384-provider:DEFAULT           |          0.00%|      0.00%|          -0.00%|       0.12%|       -0.14%|
|s.MessageDigests.getAndDigest-digesterName:SHA_256-length:64-provider:DEFAULT              |         -0.60%|     -0.10%|           0.60%|       0.21%|        0.24%|
|s.MessageDigests.getAndDigest-digesterName:SHA_384-length:16384-provider:DEFAULT           |         -0.01%|     -0.03%|           0.00%|       0.13%|        0.09%|
|s.MessageDigests.getAndDigest-digesterName:SHA_384-length:64-provider:DEFAULT              |         -0.74%|     -0.42%|           0.23%|      -0.63%|       -0.38%|
|s.MessageDigests.getAndDigest-digesterName:SHA_512-length:16384-provider:DEFAULT           |         -0.01%|      0.03%|          -0.06%|       0.11%|        0.15%|
|s.MessageDigests.getAndDigest-digesterName:SHA_512-length:64-provider:DEFAULT              |         -0.78%|      0.48%|          -0.16%|       0.58%|       -0.75%|
|s.MessageDigests.getAndDigest-digesterName:md5-length:16384-provider:DEFAULT               |         -0.04%|     -0.01%|          -0.01%|       0.00%|       -0.00%|
|s.MessageDigests.getAndDigest-digesterName:md5-length:64-provider:DEFAULT                  |          0.17%|      0.23%|           1.53%|      -0.56%|        0.37%|
|s.PKCS12KeyStores.instrong10000_New                                                        |          1.49%|     -1.52%|           0.01%|       1.80%|        0.79%|
|s.PKCS12KeyStores.instrong2048                                                             |          0.34%|     -1.44%|          -1.84%|       1.20%|       -0.02%|
|s.PKCS12KeyStores.instrong50000                                                            |         -1.35%|     -0.10%|          -6.56%|       0.66%|       -0.01%|
|s.PKCS12KeyStores.inweak2048                                                               |          1.48%|     -0.08%|          -1.12%|       0.49%|       -0.55%|
|s.PKCS12KeyStores.inweak50000_Old                                                          |          0.75%|      0.32%|          -0.38%|      -0.86%|        0.48%|
|s.PKCS12KeyStores.outstrong10000_New                                                       |          0.03%|      2.20%|          -0.33%|      -0.52%|        2.87%|
|s.PKCS12KeyStores.outstrong2048                                                            |          0.09%|     -1.31%|          -2.58%|       0.58%|       -1.58%|
|s.PKCS12KeyStores.outstrong50000                                                           |          0.12%|     -3.98%|          -1.03%|      -1.77%|        0.15%|
|s.PKCS12KeyStores.outweak2048                                                              |          0.10%|      0.82%|          -0.18%|       2.40%|       -2.75%|
|s.PKCS12KeyStores.outweak50000_Old                                                         |          0.47%|      0.01%|          -0.52%|      -0.54%|       -3.71%|
|s.PermissionsImplies.withPermission                                                        |         -0.18%|      0.00%|           0.01%|      -0.01%|       -0.71%|
|s.PermissionsImplies.withUnresolvedPermission                                              |         -4.60%|     -0.08%|           0.01%|       0.03%|        3.59%|
|s.PermissionsImplies.withoutPermission                                                     |          0.01%|     -1.29%|          -0.23%|       0.25%|        0.07%|
|s.ProtectionDomainBench.noSecurityManager-numberOfClasses:100-numberOfCodeSources:10       |         -0.01%|      1.10%|           0.27%|       0.55%|       -0.39%|
|s.ProtectionDomainBench.withSecurityManager-numberOfClasses:100-numberOfCodeSources:10     |         -1.70%|     -1.36%|          -0.36%|      -2.10%|        1.59%|
|s.SSLHandshake.doHandshake-resume:false-tlsVersion:TLS                                     |         -0.35%|      0.51%|           0.00%|      -0.08%|       -0.36%|
|s.SSLHandshake.doHandshake-resume:false-tlsVersion:TLSv1_2                                 |         -0.12%|      0.37%|          -0.09%|       0.32%|       -0.10%|
|s.SSLHandshake.doHandshake-resume:true-tlsVersion:TLS                                      |          0.27%|      0.35%|           0.24%|      -0.17%|       -0.78%|
|s.SSLHandshake.doHandshake-resume:true-tlsVersion:TLSv1_2                                  |         -1.20%|     -0.36%|          -0.06%|      -1.43%|        0.29%|
|s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:16384                          |          0.03%|     -0.03%|           0.01%|       0.16%|       -0.03%|
|s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:2048                           |         -0.02%|     -0.01%|          -0.00%|       0.19%|        0.06%|
|s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:512                            |         -0.03%|     -0.06%|           0.01%|       0.28%|       -0.14%|
|s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:64                             |         -0.05%|     -0.04%|           0.01%|       0.13%|        0.04%|
|s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:16384                          |         -0.02%|      0.05%|          -0.02%|      -0.12%|       -0.42%|
|s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:2048                           |          0.01%|      0.01%|          -0.00%|      -0.31%|       -0.01%|
|s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:512                            |         -0.02%|     -0.04%|          -0.01%|       0.60%|       -0.02%|
|s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:64                             |         -0.03%|     -0.04%|          -0.06%|      -0.09%|       -0.06%|
|s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:16384                          |          0.01%|     -0.03%|           0.02%|       0.13%|       -0.03%|
|s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:2048                           |         -0.00%|      0.03%|           0.04%|       0.07%|       -0.05%|
|s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:512                            |         -0.00%|      0.02%|          -0.01%|      -0.13%|        0.02%|
|s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:64                             |         -0.04%|     -0.06%|          -0.03%|      -0.37%|       -0.03%|
|s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:16384                              |         -0.03%|     -0.84%|          -0.05%|       0.07%|        0.18%|
|s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:2048                               |         -0.02%|      0.11%|           0.03%|      -0.06%|       -0.62%|
|s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:512                                |         -0.06%|      1.11%|           0.09%|       0.62%|       -1.25%|
|s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:64                                 |         -0.01%|     -1.12%|          -0.00%|      -0.43%|       -0.31%|
|s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:16384                                |         -0.03%|      1.01%|          -0.03%|       0.01%|        0.58%|
|s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:2048                                 |          0.05%|      0.27%|          -0.04%|      -0.18%|        1.90%|
|s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:512                                  |         -0.08%|      0.42%|          -0.19%|      -0.12%|        0.01%|
|s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:64                                   |          0.03%|     -0.62%|           0.12%|      -0.43%|        3.17%|
|s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:16384                          |          0.02%|     -0.37%|           0.32%|      -0.11%|       -0.09%|
|s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:2048                           |          0.03%|     -0.23%|          -0.06%|       0.02%|        0.21%|
|s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:512                            |         -0.10%|      0.07%|           0.34%|      -0.01%|       -0.29%|
|s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:64                             |          0.19%|      0.28%|          -0.25%|       0.07%|        0.07%|
|s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:16384                          |          0.04%|     -0.10%|          -0.14%|       0.42%|        0.36%|
|s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:2048                           |          0.04%|     -0.00%|          -0.20%|       0.00%|        0.82%|
|s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:512                            |         -0.03%|     -0.23%|           0.04%|       0.09%|       -0.11%|
|s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:64                             |         -0.13%|     -0.11%|           0.08%|       0.70%|        0.24%|
|s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:16384                          |          0.11%|      0.04%|           0.04%|       0.11%|        0.05%|
|s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:2048                           |         -0.05%|      0.21%|           0.04%|       0.20%|        0.27%|
|s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:512                            |         -0.00%|      0.01%|          -0.04%|       0.11%|       -0.03%|
|s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:64                             |          0.01%|     -0.48%|           0.11%|       0.22%|        0.02%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:16384                           |          0.15%|      0.07%|          -0.19%|      -0.26%|       -0.02%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:2048                            |          0.17%|     -0.01%|          -0.22%|      -0.63%|       -0.19%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:512                             |         -0.32%|     -0.15%|          -0.06%|      -0.01%|        0.22%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:64                              |          0.00%|     -0.05%|           0.08%|       0.06%|        0.01%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:16384                           |         -0.03%|      0.05%|          -0.06%|       0.68%|        0.21%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:2048                            |          0.01%|     -0.10%|           0.04%|       0.10%|        0.15%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:512                             |         -0.01%|     -0.06%|           0.02%|      -0.49%|        0.58%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:64                              |          0.11%|     -0.24%|          -0.07%|       0.24%|       -0.13%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:16384                           |         -0.02%|     -0.17%|           0.05%|       0.06%|        0.07%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:2048                            |         -0.08%|     -0.06%|           0.15%|       0.09%|       -0.10%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:512                             |         -0.04%|      0.00%|           0.24%|       0.08%|        0.03%|
|s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:64                              |          0.05%|      0.07%|          -0.16%|       0.21%|        0.09%|
|s.Signatures.sign-algorithm:secp256r1-messageLength:16384                                  |          0.11%|      0.25%|          -0.83%|      -0.35%|        0.68%|
|s.Signatures.sign-algorithm:secp256r1-messageLength:2048                                   |          0.07%|      1.17%|           0.50%|      -0.14%|       -0.38%|
|s.Signatures.sign-algorithm:secp256r1-messageLength:512                                    |         -0.01%|      3.95%|          -0.22%|      -0.37%|       -0.45%|
|s.Signatures.sign-algorithm:secp256r1-messageLength:64                                     |          0.00%|      3.77%|          -0.19%|      -0.21%|       -0.38%|
|s.Signatures.sign-algorithm:secp384r1-messageLength:16384                                  |         -0.03%|      0.44%|           0.09%|      -0.22%|        0.21%|
|s.Signatures.sign-algorithm:secp384r1-messageLength:2048                                   |         -0.05%|      0.88%|          -0.53%|      -0.09%|        0.53%|
|s.Signatures.sign-algorithm:secp384r1-messageLength:512                                    |         -0.00%|      0.36%|           0.03%|      -0.23%|        0.27%|
|s.Signatures.sign-algorithm:secp384r1-messageLength:64                                     |         -0.00%|     -0.36%|           0.31%|       0.31%|        0.12%|
|s.Signatures.sign-algorithm:secp521r1-messageLength:16384                                  |         -0.01%|      0.51%|          -0.01%|      -0.03%|        0.58%|
|s.Signatures.sign-algorithm:secp521r1-messageLength:2048                                   |         -0.01%|      0.07%|           0.04%|      -0.17%|        0.51%|
|s.Signatures.sign-algorithm:secp521r1-messageLength:512                                    |          0.00%|     -0.14%|          -0.05%|      -0.18%|       -1.12%|
|s.Signatures.sign-algorithm:secp521r1-messageLength:64                                     |         -0.01%|     -0.27%|           0.03%|      -0.24%|        0.62%|

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

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1806069239


From weijun at openjdk.org  Fri Nov 10 17:35:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 10 Nov 2023 17:35:58 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <AtTyN5QY45UnBaNB5IuA7DfeeXcPCgvn6LqTxVxJLEU=.1ba97f9d-a710-4e94-8338-549a5018ae22@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
 <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
 <AtTyN5QY45UnBaNB5IuA7DfeeXcPCgvn6LqTxVxJLEU=.1ba97f9d-a710-4e94-8338-549a5018ae22@github.com>
Message-ID: <VS8xSszA0wBJL0cMNN52jF3REyVWaCOntmnE7w9_S9M=.e8233c67-5d5c-4cb4-bc70-9b9359864168@github.com>

On Fri, 10 Nov 2023 16:46:15 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> By "the same key has multiple values", I assume you mean the key "import"? The implementation overrides `put` and swallows these `include` lines so they are never actually added as keys and values.

Yes, I understand this, and this makes `java.security` no longer a real properties file. If you are able to convince core-libs to adopt this new "directive" for all properties files, I'm all OK to make use of it in `java.security`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1806145708


From andrew at openjdk.org  Fri Nov 10 19:24:04 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 10 Nov 2023 19:24:04 GMT
Subject: RFR: 8309330: Allow java.security to be extended via a properties
 directory [v3]
In-Reply-To: <d9p22lwx_Vt3BbSnrFoVpUD-T4RQorRkibR_mteCw58=.36d41e37-ad84-4f33-9367-8f2d0fc70842@github.com>
References: <dkwAA8O3Tvr5RPC7OSjq3Y2jQW5QHg5gBxyAcAgokoU=.75c53221-56f0-494c-a4fc-c8c09952093c@github.com>
 <d9p22lwx_Vt3BbSnrFoVpUD-T4RQorRkibR_mteCw58=.36d41e37-ad84-4f33-9367-8f2d0fc70842@github.com>
Message-ID: <IvGCx0lf6xev_xZc6DohwvWtM7rQ3FX60H_N7DzodT8=.585dad70-4f39-4ddc-87df-2f9f59feacc4@github.com>

On Tue, 29 Aug 2023 21:59:37 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties.
>> 
>> There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required.
>> 
>> This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`.
>> 
>> As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK.
>> 
>> The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true.
>> 
>> A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream.
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into secdir
>  - Sort the returned list of property files and exclude hidden files.
>  - 8309330: Allow java.security to be extended via a properties directory

Please keep open for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/14277#issuecomment-1806311803


From mbalao at openjdk.org  Fri Nov 10 21:35:58 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 10 Nov 2023 21:35:58 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <VS8xSszA0wBJL0cMNN52jF3REyVWaCOntmnE7w9_S9M=.e8233c67-5d5c-4cb4-bc70-9b9359864168@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
 <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
 <AtTyN5QY45UnBaNB5IuA7DfeeXcPCgvn6LqTxVxJLEU=.1ba97f9d-a710-4e94-8338-549a5018ae22@github.com>
 <VS8xSszA0wBJL0cMNN52jF3REyVWaCOntmnE7w9_S9M=.e8233c67-5d5c-4cb4-bc70-9b9359864168@github.com>
Message-ID: <hyrbIgcX-miHK8QpGSY5z-Eb7aqynzGt9Ea0jlsRilU=.45451a26-41d8-4ba9-8623-0cfa3f6333b8@github.com>

On Fri, 10 Nov 2023 17:33:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > By "the same key has multiple values", I assume you mean the key "import"? The implementation overrides `put` and swallows these `include` lines so they are never actually added as keys and values.
> 
> Yes, I understand this, and this makes `java.security` no longer a real properties file. If you are able to convince core-libs to adopt this new "directive" for all properties files, I'm all OK to make use of it in `java.security`.

`java.util.Properties` instances are not necessarily backed by a filesystem file. Its APIs refer to more generic Readers, Writers and InputStreams. In that context, an "include" directive with the semantics that we assigned in this proposal could be undefined, or not in the right place.

We originally looked at this as a specialization for the purposes of security configurations in OpenJDK. But even in that narrow space we had to consider served extra properties files (e.g. `-Djava.security.properties=http://...`) and reject their relative-path includes. Java applications can specialize `java.util.Properties` to define their own semantics, and do not need to be limited by ours. For example, they may allow URLs to get remote resources ?something that we shouldn't do for security or network configurations. At some point we thought that this idea could be extended to other file-based configurations in OpenJDK such as network, but we didn't see a need at the moment that justifies a broader scope.

My point is that `Properties` do not necessarily need to look and behave in the same way, because this is a public and (intentionally) open API already. Another example of customized behavior has been `java.security.Provider`. We proposed a documented instance of it for the purposes of security configurations, that allows some extra flexibility.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1806461459


From duke at openjdk.org  Sat Nov 11 08:36:12 2023
From: duke at openjdk.org (Paolo Di Tommaso)
Date: Sat, 11 Nov 2023 08:36:12 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <gNXhP2XkaqHuNtiz2rEdxGOWBzysxCTtrYAb1apKXPw=.057059e6-ac3a-4d43-b877-51970a9a01a0@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

It turns out this is a serious issue in the Java HttpClient. Any chance to re-open this?

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

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1806749188


From jpai at openjdk.org  Sat Nov 11 09:21:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 11 Nov 2023 09:21:12 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <gNXhP2XkaqHuNtiz2rEdxGOWBzysxCTtrYAb1apKXPw=.057059e6-ac3a-4d43-b877-51970a9a01a0@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
 <gNXhP2XkaqHuNtiz2rEdxGOWBzysxCTtrYAb1apKXPw=.057059e6-ac3a-4d43-b877-51970a9a01a0@github.com>
Message-ID: <z_My0lXbc3rTtwIFkSZNCEpAazEucKJ_t_NZvWB1bCY=.a1da70b1-20fd-4c15-a759-b4a7f74cda00@github.com>

On Sat, 11 Nov 2023 08:28:14 GMT, Paolo Di Tommaso <duke at openjdk.org> wrote:

>> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
>> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.
>
> It turns out this is a serious issue in the Java HttpClient. Any chance to re-open this?

Hello @pditommaso, I've the necessary test changes ready and I will be opening a PR this coming week.

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

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1806760629


From duke at openjdk.org  Sat Nov 11 09:45:16 2023
From: duke at openjdk.org (Paolo Di Tommaso)
Date: Sat, 11 Nov 2023 09:45:16 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <myns4VSWvqSo5AVIBuXpM27xNHRnSQ_MQ1kGjKLUhFk=.95ac5bb6-e7e0-464f-8667-c237d243ba5c@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

Thanks a lot! Very appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1806766442


From alanb at openjdk.org  Sat Nov 11 14:06:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 Nov 2023 14:06:58 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
Message-ID: <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com>

On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed more line breaks
>  - fixed line breaks

src/jdk.zipfs/share/classes/module-info.java line 310:

> 308:  * considered duplicates, which can result in unexpected behavior such as wrong
> 309:  * metadata or content being returned when parsing archives containing
> 310:  * duplicate names.

The jdk.zipfs module is the JDK's ZIP file system provider, it allows the contents of a ZIP or JAR file be treated as a file system. I think what is missing from this module description is the mapping of file system concepts to ZIP files. If we added a section to the documentation for that then it would be a place to document the file separator, normalization, how directories and file tree are synthesized, and the limitation that a file system cannot be constructed when it leads to have several entries in a directory having equal names. There's a lot more that could be added but hopefully you can see that an implNote and warnings just doesn't work as a way to present the mapping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1390232094


From mdonovan at openjdk.org  Mon Nov 13 14:10:00 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 13 Nov 2023 14:10:00 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
In-Reply-To: <t1kezS1X40h3V4g0XaSOZ_K4CGo5XGg8yB7QpiUF7Zo=.3ab26105-bdd6-44e7-ba89-a302cdd97000@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <t1kezS1X40h3V4g0XaSOZ_K4CGo5XGg8yB7QpiUF7Zo=.3ab26105-bdd6-44e7-ba89-a302cdd97000@github.com>
Message-ID: <7VwigJo8cji0-xojg0Au2GcyM5BOdGNOEisYqM0m4wk=.f46dc1d8-1bec-4e66-a6c6-512d39c45c21@github.com>

On Thu, 9 Nov 2023 20:39:54 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.
>
> test/jdk/ProblemList.txt line 632:
> 
>> 630: sun/security/pkcs11/KeyStore/Basic.java                         8295343 generic-all
>> 631: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java            8316183 linux-ppc64le
>> 632: sun/security/pkcs11/Provider/MultipleLogins.sh                  8319128 linux-aarch64
> 
> At least for me, I'm not familiar enough with this test previously to know why it was a shell script before. Can you elaborate a little? I also assume this is an "active" problem list from which you're removing this line?

The shell scripts compiles Java files with additional flags and does some additional set up before executing the test.  I put the script on the ProblemList because the pkcs11 tests were failing on aarch64 and throwing a SkippedException from MultipleLogins.java would cause the test to fail. Ultimately, I could have made the change that is part of this PR (catching the SkippedException in the java file) but I didn't see it at the time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1391162805


From mullan at openjdk.org  Mon Nov 13 15:14:15 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 13 Nov 2023 15:14:15 GMT
Subject: RFR: 8311596: Add separate system properties for TLS server and
 client for maximum chain length [v8]
In-Reply-To: <r5oLaJgLh2N3EMnnJr8gbDapdtopbjDvQnjkl0EgXVE=.6115d427-1148-4471-aa7b-076789061940@github.com>
References: <xxnAZZdnD_m-OJz65Vi-l9j9YWoi00UazIY_vMPdcrg=.c2351987-2213-4891-a6a0-65ab221a18ff@github.com>
 <gmVKVenXLiqk8jzRXgi9NG3w06Vwol_HdeyKPhCAq9k=.d2e17cf7-f93e-4fad-9190-2471b875a962@github.com>
 <NFd9WpfUoegsboSznfwKkEMxgyrqfNGwKmj0y7SrR8M=.9142c82d-0fa3-49ce-8806-d7448d4a5d1c@github.com>
 <8uDb7KdUkBdaSz-uoC1OLS9WdIhH9NIDWJciBTXII00=.15673ec6-4c35-447b-a36d-4c9d4d2f0152@github.com>
 <RUukwwTcnoLObzIy1M9P2VyOFlhbDgFveSY7TF84hvs=.b815eb1f-a0f3-479f-8991-7b1b39348999@github.com>
 <Koz22YtOsNU1UssdX_7OkWV2Cr4XuqAPq4KO-4Soaow=.4d61efe7-f374-413d-8253-b1e326382b82@github.com>
 <10_wuDt6dHMbcfIQOZmoF-mMkBfaimXKjgaCbiqqEk4=.51abc990-d6e6-4eae-966c-b0416d56ed9a@github.com>
 <AGDg747a5wErWX0xsqFfWBubqMh7tCON4m2C-CdkLSE=.d5b8be12-3447-4a36-b64e-784d145756ff@github.com>
 <lf5BdLFecLZ0w472rAnzFaDqWJaPgXVXw5c96xJiiU4=.b595a6d7-aa69-49ba-a373-3be66a3a3614@github.com>
 <4JGlJtPUt6_bj-TF4VZfvTW4jqn8BrxB-Z7Wv-jl5jM=.dab911b1-6598-4cd6-b399-b37d7c437020@github.com>
 <3FYmdzSaiNoQ15o7JcOfA-bnUqDDDmSiAjk
 SA0QzcCA=.acb553e6-1307-44b8-b881-b361cd3ec8b6@github.com>
 <2Ofw53W_fxl3heGu4DBipfeuagynox2dfYrMaBqFun0=.b714ad70-9528-4987-950c-1a39ad5ec9a2@github.com>
 <cH8zLTQEcXTcdp47d0zgzoP_8TJSOE_WX062acQ9skw=.6f3d04a0-789c-4d0c-b9c7-ca41e265dae2@github.com>
 <sw9RlcRimHKfwAV3Z5OBRlcCzGWbosbHNuzXmS1-TWk=.ce4fe1b7-7d34-4c26-864f-c6fc2918d16b@github.com>
 <r5oLaJgLh2N3EMnnJr8gbDapdtopbjDvQnjkl0EgXVE=.6115d427-1148-4471-aa7b-076789061940@github.com>
Message-ID: <l4E9UIwy0DUEBH0wHLpNtxOMnHyDrj2-HvNi3ckQcm0=.e60bae70-fc68-42bd-9552-df0e31bca1a6@github.com>

On Fri, 10 Nov 2023 06:49:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length [is 5 non-self-issued intermediate CA certificates](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/cert/PKIXBuilderParameters.html#setMaxPathLength(int)), so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server or client might accept, which sometimes happens.
>
> Good point about the setMaxPathLength() limitation.  It looks like there might be an issue when the interactivities of setMaxPathLength(and its default value) and the properties defined here are not considered.  For example, what if the property is set to 8, while the setMaxPathLength is of value 5?  For the "PKIX" trust manager, per your description, if the property is set to 8, but 5 is the limit actually.  It looks like a weird behavior to me.  If I remember correctly, the "SunX509" trust manager does not use PKIXBuilderParameters, while the "PKIX" trust manager does.  It might be not the behavior we'd like to have that property 8 work for "SunX509" but not for "PKIX" trust manager.
> 
> Anyway, it might be better to look into the interactive behaviors among the properties and setMaxPathLength/default value.
> 
>> Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length [is 5 non-self-issued intermediate CA certificates](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/cert/PKIXBuilderParameters.html#setMaxPathLength(int)), so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server or client might accept, which sometimes happens.

PKIX has been the default SunJSSE TrustManager since JDK 5 and AFAIK we have not had any reports of compatibility issues. This leads me to believe that valid TLS chains longer than 6 certificates are extremely rare.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1391249509


From duke at openjdk.org  Mon Nov 13 16:03:08 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Mon, 13 Nov 2023 16:03:08 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com>
Message-ID: <xRCA93VnAm2A587CHpU0tndPVAccgRHcSFeA_7XUmYg=.b4742d67-73f1-4cc3-91dd-48bbfbbbb64c@github.com>

On Sat, 11 Nov 2023 14:04:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed more line breaks
>>  - fixed line breaks
>
> src/jdk.zipfs/share/classes/module-info.java line 310:
> 
>> 308:  * considered duplicates, which can result in unexpected behavior such as wrong
>> 309:  * metadata or content being returned when parsing archives containing
>> 310:  * duplicate names.
> 
> The jdk.zipfs module is the JDK's ZIP file system provider, it allows the contents of a ZIP or JAR file be treated as a file system. I think what is missing from this module description is the mapping of file system concepts to ZIP files. If we added a section to the documentation for that then it would be a place to document the file separator, normalization, how directories and file tree are synthesized, and the limitation that a file system cannot be constructed when it leads to have several entries in a directory having equal names. There's a lot more that could be added but hopefully you can see that an implNote and warnings just doesn't work as a way to present the mapping.

That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1391317278


From alanb at openjdk.org  Mon Nov 13 18:13:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Nov 2023 18:13:59 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <xRCA93VnAm2A587CHpU0tndPVAccgRHcSFeA_7XUmYg=.b4742d67-73f1-4cc3-91dd-48bbfbbbb64c@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com>
 <xRCA93VnAm2A587CHpU0tndPVAccgRHcSFeA_7XUmYg=.b4742d67-73f1-4cc3-91dd-48bbfbbbb64c@github.com>
Message-ID: <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com>

On Mon, 13 Nov 2023 16:00:05 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking?

Yes, I think it should be separated, and it would be nice to drop the changes to jdk.zipfs from this PR. If/when this documentation is written then it describe the "/" character and the synthesized links that are "." and "..", which can lead to documentation that a zip file that contain contains with  "." or ".." elements cannot be opened as a file system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1391493510


From fferrari at openjdk.org  Mon Nov 13 21:01:46 2023
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 13 Nov 2023 21:01:46 GMT
Subject: RFR: 8319332: Security properties files inclusion [v3]
In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
Message-ID: <KFwUcmW91YYSoRNnk4AT9d01aJv18mTX0W-l9DkPaKE=.0b19f799-616d-4e86-b9ed-a34b634dfd39@github.com>

> 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. ...

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

  8319332: Remove wildcard imports, adjust test case
  
  Test case adjustments: add missing check in PropsFile::assertApplied(),
  and fix typo in FilesManager::handleRequest() method name.
  
  Also, add clarifying comments to Executor::assertSuccess() explaining
  how we use the special properties to make the assertion. Make 'lastFile'
  assignation latter, so it's separated from the first group of asserts.
  
  Co-authored-by: Martin Balao <mbalao at redhat.com>
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16483/files
  - new: https://git.openjdk.org/jdk/pull/16483/files/2a4112e4..faf7b7fd

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

  Stats: 63 lines in 2 files changed: 51 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483

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


From fferrari at openjdk.org  Mon Nov 13 21:01:47 2023
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 13 Nov 2023 21:01:47 GMT
Subject: RFR: 8319332: Security properties files inclusion [v2]
In-Reply-To: <AtTyN5QY45UnBaNB5IuA7DfeeXcPCgvn6LqTxVxJLEU=.1ba97f9d-a710-4e94-8338-549a5018ae22@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <kVzvNhJf7AkdqsrP2rhyWcro9LqUCp-X06TBw5prYaA=.ba29e264-c83e-4811-8ccd-d3f63d61e09a@github.com>
 <Cs2JQNiqCs37rKVD7gGlskYhM2pdSGYG9ypQDN81jCo=.a0a38a64-706e-4402-abe7-aaa42504e372@github.com>
 <AtTyN5QY45UnBaNB5IuA7DfeeXcPCgvn6LqTxVxJLEU=.1ba97f9d-a710-4e94-8338-549a5018ae22@github.com>
Message-ID: <dc5xvamPLEEXAoq89_2lEjBURI2zJTvspLB4d3DSHCE=.f382577b-5800-4230-80d2-a02b977d8cab@github.com>

On Fri, 10 Nov 2023 16:46:15 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> My major concern is that this does not look like a properties file anymore, that the same key have multiple values and you use an undocumented (?) format "key value". That said, this is a clever hack and I wonder why we hadn't used it for `security.provider`s.
>
>> My major concern is that this does not look like a properties file anymore, that the same key have multiple values and you use an undocumented (?) format "key value". That said, this is a clever hack and I wonder why we hadn't used it for `security.provider`s.
> 
> This surprised me too when I first read the patch, and I had to go back to the specification of the `Properties` file. Although the convention tends to be `key=value`, it seems the specification allows for `key:value` and `key value` as well.
> 
> By "the same key has multiple values", I assume you mean the key "import"? The implementation overrides `put` and swallows these `include` lines so they are never actually added as keys and values. Were they to be added, each subsequent one would just override the one before, as is the intended behaviour of the existing `-Djava.security.properties` extra file which can be used to override `java.security` properties on the command line.

Hi @gnu-andrew,

> My main concern is with the test case, especially as the output it produces in the logs is pretty much restricted to processes stopping and starting. That's not new to this change, but the greater weight placed on the test by this change does exacerbate this problem. I'm not sure how one would go about debugging a problem from that output.

The test log is much more detailed in case of failure, because `jdk.test.lib.process.OutputAnalyzer` assertion methods invoke [`OutputAnalyzer::reportDiagnosticSummary()`](https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/lib/jdk/test/lib/process/OutputAnalyzer.java#L532-L547) before throwing the error, and because [`FilesManager::reportCreatedFiles()`](https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/jdk/java/security/Security/ConfigFileTest.java#L619-L638) is also invoked whenever an error is found.

Please see the appendix for a failure sample, showing the full output.


> The code itself is very sparse in comments. In the case of the test, it would help if at least each method could state what it was intending to test. In particular, I don't see a test of how properties from one test file override those from another, and how the ordering affects this.
>
> For example, with an external property file `extra.properties` containing `a=c`, the end result of the following:
>
> ```
> a=b
> include extra.properties
> ```
>
> would be `a=c`, whereas:
>
> ```
> include extra.properties
> a=b
> ```
>
> would be `a=b`.
>
> I don't see any test here that confirms that a property ends up set to an expected value, though I may be missing this because the structure of the test is quite hard to follow.

One of our goals for the test was to provide easy setup primitives, where complex scenarios can be created in a few lines, and writing new tests is as straightforward as possible. For this reason we think that adding comments to statements such as `ExtraPropsFile extraFile = filesMgr.newExtraFile()` or `extraFile.addRelativeInclude(file2)` would be redundant.

On the other hand, the downside of this approach is that assertions are done automatically, so the assertion logic becomes a bit hidden. If we write your first example in the test case idiom, it would look like this:


    static void testSimpleOverride(Executor ex, FilesManager filesMgr)
            throws Exception {
        PropsFile masterFile = filesMgr.newMasterFile();
        PropsFile file0 = filesMgr.newFile("file0.properties");

        masterFile.addRelativeInclude(file0);

        ex.setMasterFile(masterFile);
        ex.assertSuccess();
    }


Please note that I named `file0` the included file to avoid confusion with the "extra properties file", passed with the `-Djava.security.properties` system property.

`FilesManager` performs the following actions:

* For `masterFile`, uses the system `java.security` as a template, and adds the following content
    * `java.security=applied`
    * `last-file=java.security` (this plays the role of `a=b` in your first example)
    * `include .../file0.properties`
* For `file0`, creates a new file with the following content
    * `file0.properties=applied`
    * `last-file=file0.properties` (this plays the role of `a=c` in your first example)

To avoid invalid tests, file name uniqueness is checked [here](https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/jdk/java/security/Security/ConfigFileTest.java#L578-L582). After execution, `PropsFile::assertApplied()` will check that both files were loaded, by expecting the following stderr lines:


properties: Initial security property: java.security=applied
properties: Initial security property: file0.properties=applied


Then, `Executor::assertSuccess()` asks the `FilesManager` to compute the last included file by traversing the includes tree either from `java.security` or the extra properties file as appropriate. In this case, there's no extra properties file, so the `java.security` includes are traversed [here](https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/jdk/java/security/Security/ConfigFileTest.java#L450-L453). Once the last file is determined, the test checks that the `last-file` property has the overwrote value, by expecting the following stderr line:


properties: Initial security property: last-file=file0.properties


And the following stdout line (generated [here](https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/jdk/java/security/Security/ConfigFileTest.java#L86-L87)):


last-file: file0.properties


I hope this is clearer now, and followable in the output of the failure sample appendix. We'll add two comments in `Executor::assertSuccess()` explaining how this work and showing an example, and move the `lastFile` assignation latter, so it's separated from the first group of asserts.

> Also, is `handeRequest` deliberate or a typo of `handleRequest`?

Definitely a typo, we'll also fix this.


# Appendix

For the record, I'll edit `ConfigFileTest::testIncludeBasic()` to produce an error and have a sample of the output documented here:
https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/jdk/java/security/Security/ConfigFileTest.java#L117-L132

The last included file is `file1`, because `extraFile` (which is loaded after `masterFile`) includes `file2`, which includes `file1` in line 127:


        file2.addAbsoluteInclude(file1);


I'll change line 127 to its `PropsFile::addRawProperty()` equivalent:


        file2.addRawProperty("include", file1.path.toString());


In this way, the same include is produced, but it isn't [tracked in `PropsFile.includes`](https://github.com/openjdk/jdk/blob/2a4112e44644e35a002549f8fad227d1024491fe/test/jdk/java/security/Security/ConfigFileTest.java#L401), so the test will still expect `file2` to be the last include.

<details>
<summary>
<h3>Expand full failure log</h3>
</summary>


#Test Results (version 2)
#Mon Nov 13 20:22:10 CET 2023
#-----testdescription-----
$file=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security/ConfigFileTest.java
$root=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk
keywords=bug8155246 bug8292297 bug8292177 bug8281658 bug8319332
library=/test/lib
modules=java.base/sun.net.www
run=USER_SPECIFIED main ConfigFileTest\n
source=ConfigFileTest.java
title=Tests security properties passed through java.security, java.security.properties or included from other properties files.

#-----environment-----

#-----testresult-----
description=file:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security/ConfigFileTest.java
elapsed=28787 0:00:28.787
end=Mon Nov 13 20:22:10 CET 2023
environment=regtest
execStatus=Failed. Execution failed: `main' threw exception: java.lang.reflect.InvocationTargetException
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
hostname=vmhost.lab
javatestOS=Linux 6.5.10-200.fc38.x86_64 (amd64)
javatestVersion=6.0-ea+b24-2023-05-08-${BUILT_FROM_COMMIT}
jtregVersion=jtreg 7.3.1 dev 0
modules=java.base/sun.net.www
script=com.sun.javatest.regtest.exec.RegressionScript
sections=script_messages build compile main
start=Mon Nov 13 20:21:42 CET 2023
test=java/security/Security/ConfigFileTest.java
testJDK=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk
testJDK_OS=[name:Linux,arch:amd64,version:6.5.10-200.fc38.x86_64,family:linux,simple_arch:x64,simple_version:6.5,processors:12,maxMemory:33384845312,maxSwap:8589930496]
testJDK_os.arch=amd64
testJDK_os.name=Linux
testJDK_os.version=6.5.10-200.fc38.x86_64
totalTime=28791
user.name=fferrari
work=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/java/security/Security

#section:script_messages
----------messages:(7/731)----------
JDK under test: /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk
openjdk version "22-internal" 2024-03-19
OpenJDK Runtime Environment (slowdebug build 22-internal-adhoc.fferrari.java-security-includes)
OpenJDK 64-Bit Server VM (slowdebug build 22-internal-adhoc.fferrari.java-security-includes, mixed mode, sharing)
Library /test/lib; kind: packages
   source directory: /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib
   class directory: /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib

#section:build
----------messages:(7/219)----------
command: build ConfigFileTest
reason: Named class compiled on demand
started: Mon Nov 13 20:21:42 CET 2023
Test directory:
  compile: ConfigFileTest
finished: Mon Nov 13 20:21:59 CET 2023
elapsed time (seconds): 16.667
result: Passed. Build successful

#section:compile
----------messages:(8/439)----------
command: compile /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security/ConfigFileTest.java
reason: .class file out of date or does not exist
started: Mon Nov 13 20:21:42 CET 2023
Additional options from @modules: --add-modules java.base --add-exports java.base/sun.net.www=ALL-UNNAMED
Mode: agentvm
Agent id: 1
finished: Mon Nov 13 20:21:59 CET 2023
elapsed time (seconds): 16.663
----------configuration:(14/1285)----------
Boot Layer (javac runtime environment)
  class path: /home/fferrari/programs/jtreg/build/images/jtreg/lib/javatest.jar 
              /home/fferrari/programs/jtreg/build/images/jtreg/lib/jtreg.jar 
  patch:      java.base /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/patches/java.base

javac compilation environment
  add modules: java.base             
  add exports: java.base/sun.net.www ALL-UNNAMED
  source path: /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security 
               /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib 
  class path:  /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security 
               /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d 
               /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib 

----------rerun:(44/4654)*----------
cd /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch && \\
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus \\
DESKTOP_SESSION=cinnamon \\
DISPLAY=:0 \\
GDMSESSION=cinnamon \\
GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\
HOME=/home/fferrari \\
LANG=en_US.UTF-8 \\
PATH=/bin:/usr/bin:/usr/sbin \\
XDG_CURRENT_DESKTOP=X-Cinnamon \\
XDG_DATA_DIRS=/home/fferrari/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share \\
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/fferrari \\
XDG_RUNTIME_DIR=/run/user/1000 \\
XDG_SEAT=seat0 \\
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 \\
XDG_SESSION_CLASS=user \\
XDG_SESSION_DESKTOP=cinnamon \\
XDG_SESSION_ID=2 \\
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 \\
XDG_SESSION_TYPE=x11 \\
XDG_VTNR=1 \\
XMODIFIERS=@im=none \\
    /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk/bin/javac \\
        -J-Dtest.vm.opts= \\
        -J-Dtest.tool.vm.opts= \\
        -J-Dtest.compiler.opts= \\
        -J-Dtest.java.opts= \\
        -J-Dtest.jdk=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk \\
        -J-Dcompile.jdk=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk \\
        -J-Dtest.timeout.factor=1.0 \\
        -J-Dtest.root=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk \\
        -J-Dtest.name=java/security/Security/ConfigFileTest.java \\
        -J-Dtest.file=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security/ConfigFileTest.java \\
        -J-Dtest.src=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security \\
        -J-Dtest.src.path=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib \\
        -J-Dtest.classes=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d \\
        -J-Dtest.class.path=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib \\
        -J-Dtest.class.path.prefix=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib \\
        -J-Dtest.modules=java.base/sun.net.www \\
        --add-modules java.base \\
        --add-exports java.base/sun.net.www=ALL-UNNAMED \\
        -d /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d \\
        -sourcepath /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib \\
        -classpath /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security/ConfigFileTest.java
----------direct:(2/110)----------
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
result: Passed. Compilation successful

#section:main
----------messages:(8/293)----------
command: main ConfigFileTest
reason: User specified action: run main ConfigFileTest 
started: Mon Nov 13 20:21:59 CET 2023
Mode: agentvm
Agent id: 2
Additional exports to unnamed modules from @modules: java.base/sun.net.www
finished: Mon Nov 13 20:22:10 CET 2023
elapsed time (seconds): 11.51
----------configuration:(16/1441)----------
Boot Layer
  class path: /home/fferrari/programs/jtreg/build/images/jtreg/lib/javatest.jar 
              /home/fferrari/programs/jtreg/build/images/jtreg/lib/jtreg.jar 
              /home/fferrari/programs/jtreg/build/images/jtreg/lib/junit-platform-console-standalone-1.9.2.jar 
              /home/fferrari/programs/jtreg/build/images/jtreg/lib/testng-7.3.0.jar 
              /home/fferrari/programs/jtreg/build/images/jtreg/lib/guice-5.1.0.jar 
              /home/fferrari/programs/jtreg/build/images/jtreg/lib/jcommander-1.82.jar 
  patch:      java.base /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/patches/java.base

Test Layer
  add exports: java.base/sun.net.www ALL-UNNAMED
  class path:  /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d 
               /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security 
               /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib 
               /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib 

----------rerun:(41/4197)*----------
cd /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch && \\
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus \\
DESKTOP_SESSION=cinnamon \\
DISPLAY=:0 \\
GDMSESSION=cinnamon \\
GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\
HOME=/home/fferrari \\
LANG=en_US.UTF-8 \\
PATH=/bin:/usr/bin:/usr/sbin \\
XDG_CURRENT_DESKTOP=X-Cinnamon \\
XDG_DATA_DIRS=/home/fferrari/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share \\
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/fferrari \\
XDG_RUNTIME_DIR=/run/user/1000 \\
XDG_SEAT=seat0 \\
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 \\
XDG_SESSION_CLASS=user \\
XDG_SESSION_DESKTOP=cinnamon \\
XDG_SESSION_ID=2 \\
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 \\
XDG_SESSION_TYPE=x11 \\
XDG_VTNR=1 \\
XMODIFIERS=@im=none \\
    /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk/bin/java \\
        -Dtest.vm.opts= \\
        -Dtest.tool.vm.opts= \\
        -Dtest.compiler.opts= \\
        -Dtest.java.opts= \\
        -Dtest.jdk=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk \\
        -Dcompile.jdk=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/images/jdk \\
        -Dtest.timeout.factor=1.0 \\
        -Dtest.root=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk \\
        -Dtest.name=java/security/Security/ConfigFileTest.java \\
        -Dtest.file=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security/ConfigFileTest.java \\
        -Dtest.src=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security \\
        -Dtest.src.path=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib \\
        -Dtest.classes=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d \\
        -Dtest.class.path=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib \\
        -Dtest.class.path.prefix=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib \\
        -Dtest.modules=java.base/sun.net.www \\
        -classpath /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/jdk/java/security/Security:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/test/lib:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/test/lib:/home/fferrari/programs/jtreg/build/images/jtreg/lib/javatest.jar:/home/fferrari/programs/jtreg/build/images/jtreg/lib/jtreg.jar \\
        ConfigFileTest
----------System.out:(24/1241)----------

----------------------------
testShowSettings
----------------------------

[2023-11-13T19:22:03.983731120Z] Gathering output for process 33742
[2023-11-13T19:22:08.467176610Z] Waiting for completion for process 33742
[2023-11-13T19:22:08.467588933Z] Waiting for completion finished for process 33742
Output and diagnostic info for process 33742 was saved into 'pid-33742-output.log'
[2023-11-13T19:22:08.477211660Z] Waiting for completion for process 33742
[2023-11-13T19:22:08.477408699Z] Waiting for completion finished for process 33742

----------------------------
testIncludeBasic
----------------------------

[2023-11-13T19:22:08.578626159Z] Gathering output for process 33779
[2023-11-13T19:22:10.400474490Z] Waiting for completion for process 33779
[2023-11-13T19:22:10.401163753Z] Waiting for completion finished for process 33779
Output and diagnostic info for process 33779 was saved into 'pid-33779-output.log'
[2023-11-13T19:22:10.403160023Z] Waiting for completion for process 33779
[2023-11-13T19:22:10.403351737Z] Waiting for completion finished for process 33779
[2023-11-13T19:22:10.407549929Z] Waiting for completion for process 33779
[2023-11-13T19:22:10.407776650Z] Waiting for completion finished for process 33779
----------System.err:(1343/70332)----------
 stdout: [last-file: file1.properties
];
 stderr: [properties: > starting to process /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/jdk/conf/security/java.security
properties: processing include: '/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/file0.properties'
properties: >> starting to process /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/file0.properties
properties: << finished processing /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/file0.properties
properties: < finished processing /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/jdk/conf/security/java.security
properties: > starting to process /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/extra.properties
properties: processing include: 'dir1/dir2/${props.none}${props.fileName}' (expanded to 'dir1/dir2/file2.properties')
properties: >> starting to process /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/dir2/file2.properties
properties: processing include: '/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/file1.properties'
properties: >>> starting to process /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/file1.properties
properties: <<< finished processing /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/file1.properties
properties: << finished processing /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/dir2/file2.properties
properties: < finished processing /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/extra.properties
properties: Initial security property: jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01
properties: Initial security property: jdk.security.legacyAlgorithms=SHA1, RSA keySize < 2048, DSA keySize < 2048, DES, DESede, MD5, RC2, ARCFOUR
properties: Initial security property: crypto.policy=unlimited
properties: Initial security property: jceks.key.serialFilter=java.base/java.lang.Enum;java.base/java.security.KeyRep;java.base/java.security.KeyRep$Type;java.base/javax.crypto.spec.SecretKeySpec;!*
properties: Initial security property: login.configuration.provider=sun.security.provider.ConfigFile
properties: Initial security property: security.overridePropertiesFile=true
properties: Initial security property: jdk.tls.legacyAlgorithms=NULL, anon, RC4, DES, 3DES_EDE_CBC
properties: Initial security property: file2.properties=applied
properties: Initial security property: security.provider.7=SunSASL
properties: Initial security property: security.provider.8=XMLDSig
properties: Initial security property: java.security=applied
properties: Initial security property: security.provider.9=SunPCSC
properties: Initial security property: jdk.security.caDistrustPolicies=SYMANTEC_TLS
properties: Initial security property: extra.properties=applied
properties: Initial security property: security.provider.1=SUN
properties: Initial security property: security.provider.2=SunRsaSign
properties: Initial security property: security.provider.3=SunEC
properties: Initial security property: security.provider.4=SunJSSE
properties: Initial security property: networkaddress.cache.negative.ttl=10
properties: Initial security property: jdk.tls.alpnCharset=ISO_8859_1
properties: Initial security property: security.provider.5=SunJCE
properties: Initial security property: security.provider.6=SunJGSS
properties: Initial security property: ssl.KeyManagerFactory.algorithm=SunX509
properties: Initial security property: ssl.TrustManagerFactory.algorithm=PKIX
properties: Initial security property: policy.allowSystemProperty=true
properties: Initial security property: jdk.io.permissionsUseCanonicalPath=false
properties: Initial security property: file0.properties=applied
properties: Initial security property: package.access=sun.misc.,sun.reflect.
properties: Initial security property: package.definition=sun.misc.,sun.reflect.
properties: Initial security property: security.provider.12=SunPKCS11
properties: Initial security property: http.auth.digest.disabledAlgorithms=MD5, SHA-1
properties: Initial security property: policy.provider=sun.security.provider.PolicyFile
properties: Initial security property: file1.properties=applied
properties: Initial security property: policy.url.1=file:${java.home}/conf/security/java.policy
properties: Initial security property: policy.url.2=file:${user.home}/.java.policy
properties: Initial security property: securerandom.source=file:/dev/random
properties: Initial security property: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01
properties: Initial security property: jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH
properties: Initial security property: policy.ignoreIdentityScope=false
properties: Initial security property: keystore.type.compat=true
properties: Initial security property: security.provider.11=JdkSASL
properties: Initial security property: security.provider.10=JdkLDAP
properties: Initial security property: jdk.sasl.disabledMechanisms=
properties: Initial security property: sun.security.krb5.maxReferrals=5
properties: Initial security property: jdk.tls.keyLimits=AES/GCM/NoPadding KeyUpdate 2^37, ChaCha20-Poly1305 KeyUpdate 2^37
properties: Initial security property: last-file=file1.properties
properties: Initial security property: jdk.xml.dsig.secureValidationPolicy=disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,disallowAlg http://www.w3.org/2000/09/xmldsig#sha1,disallowAlg http://www.w3.org/2000/09/xmldsig#dsa-sha1,disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1,disallowAlg http://www.w3.org/2007/05/xmldsig-more#sha1-rsa-MGF1,disallowAlg http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1,maxTransforms 5,maxReferences 30,disallowReferenceUriSchemes file http https,minKeySize RSA 1024,minKeySize DSA 1024,minKeySize EC 224,noDuplicateIds,noRetrievalMethodLoops
properties: Initial security property: securerandom.drbg.config=
properties: Initial security property: sun.security.krb5.disableReferrals=false
properties: Initial security property: keystore.type=pkcs12
properties: Initial security property: securerandom.strongAlgorithms=NativePRNGBlocking:SUN,DRBG:SUN
properties: Initial security property: policy.expandProperties=true
properties: Initial security property: krb5.kdc.bad.policy=tryLast
scl:  getPermissions ProtectionDomain  (file:/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d/ <no signer certificates>)
 jdk.internal.loader.ClassLoaders$AppClassLoader at 32a1bec0
 <no principals>
 java.security.Permissions at 1b6d3586 (
 ("java.io.FilePermission" "/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/classes/java/security/Security/ConfigFileTest.d/-" "read")
 ("java.lang.RuntimePermission" "exitVM")
)


scl: 
ProviderList: provider configuration: [SUN, SunRsaSign, SunEC, SunJSSE, SunJCE, SunJGSS, SunSASL, XMLDSig, SunPCSC, JdkLDAP, JdkSASL, SunPKCS11]
ProviderList: config configuration: null
ProviderList: Loading all providers
java.lang.Exception: Debug Info. Call trace:
	at java.base/sun.security.jca.ProviderList.loadAll(ProviderList.java:316)
	at java.base/sun.security.jca.ProviderList.removeInvalid(ProviderList.java:337)
	at java.base/sun.security.jca.Providers.getFullProviderList(Providers.java:186)
	at java.base/java.security.Security.getProviders(Security.java:550)
	at ConfigFileTest.main(ConfigFileTest.java:84)
provider: NativePRNG egdUrl: file:/dev/random
provider: NativePRNG.MIXED seedFile: /dev/random nextFile: /dev/urandom
provider: NativePRNG.BLOCKING seedFile: /dev/random nextFile: /dev/random
provider: NativePRNG.NONBLOCKING seedFile: /dev/urandom nextFile: /dev/urandom
jca: Setting up name2enum:
jca: 2.5.4.3 => CommonName
jca: COMMONNAME => CommonName
jca: 2.5.4.4 => Surname
jca: SURNAME => Surname
jca: 2.5.4.5 => SerialNumber
jca: SERIALNUMBER => SerialNumber
jca: 2.5.4.6 => CountryName
jca: COUNTRYNAME => CountryName
jca: 2.5.4.7 => LocalityName
jca: LOCALITYNAME => LocalityName
jca: 2.5.4.8 => StateName
jca: STATENAME => StateName
jca: 2.5.4.9 => StreetAddress
jca: STREETADDRESS => StreetAddress
jca: 2.5.4.10 => OrgName
jca: ORGNAME => OrgName
jca: 2.5.4.11 => OrgUnitName
jca: ORGUNITNAME => OrgUnitName
jca: 2.5.4.12 => Title
jca: TITLE => Title
jca: 2.5.4.42 => GivenName
jca: GIVENNAME => GivenName
jca: 2.5.4.43 => Initials
jca: INITIALS => Initials
jca: 2.5.4.44 => GenerationQualifier
jca: GENERATIONQUALIFIER => GenerationQualifier
jca: 2.5.4.46 => DNQualifier
jca: DNQUALIFIER => DNQualifier
jca: 2.5.29.9 => SubjectDirectoryAttributes
jca: SUBJECTDIRECTORYATTRIBUTES => SubjectDirectoryAttributes
jca: 2.5.29.14 => SubjectKeyID
jca: SUBJECTKEYID => SubjectKeyID
jca: 2.5.29.15 => KeyUsage
jca: KEYUSAGE => KeyUsage
jca: 2.5.29.16 => PrivateKeyUsage
jca: PRIVATEKEYUSAGE => PrivateKeyUsage
jca: 2.5.29.17 => SubjectAlternativeName
jca: SUBJECTALTERNATIVENAME => SubjectAlternativeName
jca: 2.5.29.18 => IssuerAlternativeName
jca: ISSUERALTERNATIVENAME => IssuerAlternativeName
jca: 2.5.29.19 => BasicConstraints
jca: BASICCONSTRAINTS => BasicConstraints
jca: 2.5.29.20 => CRLNumber
jca: CRLNUMBER => CRLNumber
jca: 2.5.29.21 => ReasonCode
jca: REASONCODE => ReasonCode
jca: 2.5.29.23 => HoldInstructionCode
jca: HOLDINSTRUCTIONCODE => HoldInstructionCode
jca: 2.5.29.24 => InvalidityDate
jca: INVALIDITYDATE => InvalidityDate
jca: 2.5.29.27 => DeltaCRLIndicator
jca: DELTACRLINDICATOR => DeltaCRLIndicator
jca: 2.5.29.28 => IssuingDistributionPoint
jca: ISSUINGDISTRIBUTIONPOINT => IssuingDistributionPoint
jca: 2.5.29.29 => CertificateIssuer
jca: CERTIFICATEISSUER => CertificateIssuer
jca: 2.5.29.30 => NameConstraints
jca: NAMECONSTRAINTS => NameConstraints
jca: 2.5.29.31 => CRLDistributionPoints
jca: CRLDISTRIBUTIONPOINTS => CRLDistributionPoints
jca: 2.5.29.32 => CertificatePolicies
jca: CERTIFICATEPOLICIES => CertificatePolicies
jca: 2.5.29.32.0 => CE_CERT_POLICIES_ANY
jca: CE_CERT_POLICIES_ANY => CE_CERT_POLICIES_ANY
jca: 2.5.29.33 => PolicyMappings
jca: POLICYMAPPINGS => PolicyMappings
jca: 2.5.29.35 => AuthorityKeyID
jca: AUTHORITYKEYID => AuthorityKeyID
jca: 2.5.29.36 => PolicyConstraints
jca: POLICYCONSTRAINTS => PolicyConstraints
jca: 2.5.29.37 => extendedKeyUsage
jca: EXTENDEDKEYUSAGE => extendedKeyUsage
jca: 2.5.29.37.0 => anyExtendedKeyUsage
jca: ANYEXTENDEDKEYUSAGE => anyExtendedKeyUsage
jca: 2.5.29.46 => FreshestCRL
jca: FRESHESTCRL => FreshestCRL
jca: 2.5.29.54 => InhibitAnyPolicy
jca: INHIBITANYPOLICY => InhibitAnyPolicy
jca: 1.3.6.1.5.5.7.1.1 => AuthInfoAccess
jca: AUTHINFOACCESS => AuthInfoAccess
jca: 1.3.6.1.5.5.7.1.11 => SubjectInfoAccess
jca: SUBJECTINFOACCESS => SubjectInfoAccess
jca: 1.3.6.1.5.5.7.3.1 => serverAuth
jca: SERVERAUTH => serverAuth
jca: 1.3.6.1.5.5.7.3.2 => clientAuth
jca: CLIENTAUTH => clientAuth
jca: 1.3.6.1.5.5.7.3.3 => codeSigning
jca: CODESIGNING => codeSigning
jca: 1.3.6.1.5.5.7.3.4 => emailProtection
jca: EMAILPROTECTION => emailProtection
jca: 1.3.6.1.5.5.7.3.5 => ipsecEndSystem
jca: IPSECENDSYSTEM => ipsecEndSystem
jca: 1.3.6.1.5.5.7.3.6 => ipsecTunnel
jca: IPSECTUNNEL => ipsecTunnel
jca: 1.3.6.1.5.5.7.3.7 => ipsecUser
jca: IPSECUSER => ipsecUser
jca: 1.3.6.1.5.5.7.3.8 => KP_TimeStamping
jca: 1.3.6.1.5.5.7.3.9 => OCSPSigning
jca: OCSPSIGNING => OCSPSigning
jca: 1.3.6.1.5.5.7.48.1 => OCSP
jca: OCSP => OCSP
jca: 1.3.6.1.5.5.7.48.1.1 => OCSPBasicResponse
jca: OCSPBASICRESPONSE => OCSPBasicResponse
jca: 1.3.6.1.5.5.7.48.1.2 => OCSPNonceExt
jca: OCSPNONCEEXT => OCSPNonceExt
jca: 1.3.6.1.5.5.7.48.1.5 => OCSPNoCheck
jca: OCSPNOCHECK => OCSPNoCheck
jca: 1.3.6.1.5.5.7.48.2 => caIssuers
jca: CAISSUERS => caIssuers
jca: 1.3.6.1.5.5.7.48.3 => AD_TimeStamping
jca: 1.3.6.1.5.5.7.48.5 => caRepository
jca: CAREPOSITORY => caRepository
jca: 2.16.840.1.101.3.4.1 => AES
jca: AES => AES
jca: 2.16.840.1.101.3.4.1.1 => AES_128$ECB$NoPadding
jca: AES_128/ECB/NOPADDING => AES_128$ECB$NoPadding
jca: 2.16.840.1.101.3.4.1.2 => AES_128$CBC$NoPadding
jca: AES_128/CBC/NOPADDING => AES_128$CBC$NoPadding
jca: 2.16.840.1.101.3.4.1.3 => AES_128$OFB$NoPadding
jca: AES_128/OFB/NOPADDING => AES_128$OFB$NoPadding
jca: 2.16.840.1.101.3.4.1.4 => AES_128$CFB$NoPadding
jca: AES_128/CFB/NOPADDING => AES_128$CFB$NoPadding
jca: 2.16.840.1.101.3.4.1.5 => AES_128$KW$NoPadding
jca: AES_128/KW/NOPADDING => AES_128$KW$NoPadding
jca: AESWRAP_128 => AES_128$KW$NoPadding
jca: 2.16.840.1.101.3.4.1.6 => AES_128$GCM$NoPadding
jca: AES_128/GCM/NOPADDING => AES_128$GCM$NoPadding
jca: 2.16.840.1.101.3.4.1.8 => AES_128$KWP$NoPadding
jca: AES_128/KWP/NOPADDING => AES_128$KWP$NoPadding
jca: AESWRAPPAD_128 => AES_128$KWP$NoPadding
jca: 2.16.840.1.101.3.4.1.21 => AES_192$ECB$NoPadding
jca: AES_192/ECB/NOPADDING => AES_192$ECB$NoPadding
jca: 2.16.840.1.101.3.4.1.22 => AES_192$CBC$NoPadding
jca: AES_192/CBC/NOPADDING => AES_192$CBC$NoPadding
jca: 2.16.840.1.101.3.4.1.23 => AES_192$OFB$NoPadding
jca: AES_192/OFB/NOPADDING => AES_192$OFB$NoPadding
jca: 2.16.840.1.101.3.4.1.24 => AES_192$CFB$NoPadding
jca: AES_192/CFB/NOPADDING => AES_192$CFB$NoPadding
jca: 2.16.840.1.101.3.4.1.25 => AES_192$KW$NoPadding
jca: AES_192/KW/NOPADDING => AES_192$KW$NoPadding
jca: AESWRAP_192 => AES_192$KW$NoPadding
jca: 2.16.840.1.101.3.4.1.26 => AES_192$GCM$NoPadding
jca: AES_192/GCM/NOPADDING => AES_192$GCM$NoPadding
jca: 2.16.840.1.101.3.4.1.28 => AES_192$KWP$NoPadding
jca: AES_192/KWP/NOPADDING => AES_192$KWP$NoPadding
jca: AESWRAPPAD_192 => AES_192$KWP$NoPadding
jca: 2.16.840.1.101.3.4.1.41 => AES_256$ECB$NoPadding
jca: AES_256/ECB/NOPADDING => AES_256$ECB$NoPadding
jca: 2.16.840.1.101.3.4.1.42 => AES_256$CBC$NoPadding
jca: AES_256/CBC/NOPADDING => AES_256$CBC$NoPadding
jca: 2.16.840.1.101.3.4.1.43 => AES_256$OFB$NoPadding
jca: AES_256/OFB/NOPADDING => AES_256$OFB$NoPadding
jca: 2.16.840.1.101.3.4.1.44 => AES_256$CFB$NoPadding
jca: AES_256/CFB/NOPADDING => AES_256$CFB$NoPadding
jca: 2.16.840.1.101.3.4.1.45 => AES_256$KW$NoPadding
jca: AES_256/KW/NOPADDING => AES_256$KW$NoPadding
jca: AESWRAP_256 => AES_256$KW$NoPadding
jca: 2.16.840.1.101.3.4.1.46 => AES_256$GCM$NoPadding
jca: AES_256/GCM/NOPADDING => AES_256$GCM$NoPadding
jca: 2.16.840.1.101.3.4.1.48 => AES_256$KWP$NoPadding
jca: AES_256/KWP/NOPADDING => AES_256$KWP$NoPadding
jca: AESWRAPPAD_256 => AES_256$KWP$NoPadding
jca: 2.16.840.1.101.3.4.2.1 => SHA_256
jca: SHA-256 => SHA_256
jca: SHA256 => SHA_256
jca: 2.16.840.1.101.3.4.2.2 => SHA_384
jca: SHA-384 => SHA_384
jca: SHA384 => SHA_384
jca: 2.16.840.1.101.3.4.2.3 => SHA_512
jca: SHA-512 => SHA_512
jca: SHA512 => SHA_512
jca: 2.16.840.1.101.3.4.2.4 => SHA_224
jca: SHA-224 => SHA_224
jca: SHA224 => SHA_224
jca: 2.16.840.1.101.3.4.2.5 => SHA_512$224
jca: SHA-512/224 => SHA_512$224
jca: SHA512/224 => SHA_512$224
jca: 2.16.840.1.101.3.4.2.6 => SHA_512$256
jca: SHA-512/256 => SHA_512$256
jca: SHA512/256 => SHA_512$256
jca: 2.16.840.1.101.3.4.2.7 => SHA3_224
jca: SHA3-224 => SHA3_224
jca: 2.16.840.1.101.3.4.2.8 => SHA3_256
jca: SHA3-256 => SHA3_256
jca: 2.16.840.1.101.3.4.2.9 => SHA3_384
jca: SHA3-384 => SHA3_384
jca: 2.16.840.1.101.3.4.2.10 => SHA3_512
jca: SHA3-512 => SHA3_512
jca: 2.16.840.1.101.3.4.2.11 => SHAKE128
jca: SHAKE128 => SHAKE128
jca: 2.16.840.1.101.3.4.2.12 => SHAKE256
jca: SHAKE256 => SHAKE256
jca: 2.16.840.1.101.3.4.2.13 => HmacSHA3_224
jca: HMACSHA3-224 => HmacSHA3_224
jca: 2.16.840.1.101.3.4.2.14 => HmacSHA3_256
jca: HMACSHA3-256 => HmacSHA3_256
jca: 2.16.840.1.101.3.4.2.15 => HmacSHA3_384
jca: HMACSHA3-384 => HmacSHA3_384
jca: 2.16.840.1.101.3.4.2.16 => HmacSHA3_512
jca: HMACSHA3-512 => HmacSHA3_512
jca: 2.16.840.1.101.3.4.2.17 => SHAKE128_LEN
jca: SHAKE128-LEN => SHAKE128_LEN
jca: 2.16.840.1.101.3.4.2.18 => SHAKE256_LEN
jca: SHAKE256-LEN => SHAKE256_LEN
jca: 2.16.840.1.101.3.4.3.1 => SHA224withDSA
jca: SHA224WITHDSA => SHA224withDSA
jca: 2.16.840.1.101.3.4.3.2 => SHA256withDSA
jca: SHA256WITHDSA => SHA256withDSA
jca: 2.16.840.1.101.3.4.3.3 => SHA384withDSA
jca: SHA384WITHDSA => SHA384withDSA
jca: 2.16.840.1.101.3.4.3.4 => SHA512withDSA
jca: SHA512WITHDSA => SHA512withDSA
jca: 2.16.840.1.101.3.4.3.5 => SHA3_224withDSA
jca: SHA3-224WITHDSA => SHA3_224withDSA
jca: 2.16.840.1.101.3.4.3.6 => SHA3_256withDSA
jca: SHA3-256WITHDSA => SHA3_256withDSA
jca: 2.16.840.1.101.3.4.3.7 => SHA3_384withDSA
jca: SHA3-384WITHDSA => SHA3_384withDSA
jca: 2.16.840.1.101.3.4.3.8 => SHA3_512withDSA
jca: SHA3-512WITHDSA => SHA3_512withDSA
jca: 2.16.840.1.101.3.4.3.9 => SHA3_224withECDSA
jca: SHA3-224WITHECDSA => SHA3_224withECDSA
jca: 2.16.840.1.101.3.4.3.10 => SHA3_256withECDSA
jca: SHA3-256WITHECDSA => SHA3_256withECDSA
jca: 2.16.840.1.101.3.4.3.11 => SHA3_384withECDSA
jca: SHA3-384WITHECDSA => SHA3_384withECDSA
jca: 2.16.840.1.101.3.4.3.12 => SHA3_512withECDSA
jca: SHA3-512WITHECDSA => SHA3_512withECDSA
jca: 2.16.840.1.101.3.4.3.13 => SHA3_224withRSA
jca: SHA3-224WITHRSA => SHA3_224withRSA
jca: 2.16.840.1.101.3.4.3.14 => SHA3_256withRSA
jca: SHA3-256WITHRSA => SHA3_256withRSA
jca: 2.16.840.1.101.3.4.3.15 => SHA3_384withRSA
jca: SHA3-384WITHRSA => SHA3_384withRSA
jca: 2.16.840.1.101.3.4.3.16 => SHA3_512withRSA
jca: SHA3-512WITHRSA => SHA3_512withRSA
jca: 1.2.840.113549.1.1 => PKCS1
jca: 1.2.840.113549.1.1.1 => RSA
jca: RSA => RSA
jca: 1.2.840.113549.1.1.2 => MD2withRSA
jca: MD2WITHRSA => MD2withRSA
jca: 1.2.840.113549.1.1.4 => MD5withRSA
jca: MD5WITHRSA => MD5withRSA
jca: 1.2.840.113549.1.1.5 => SHA1withRSA
jca: SHA1WITHRSA => SHA1withRSA
jca: 1.2.840.113549.1.1.7 => OAEP
jca: OAEP => OAEP
jca: 1.2.840.113549.1.1.8 => MGF1
jca: MGF1 => MGF1
jca: 1.2.840.113549.1.1.9 => PSpecified
jca: PSPECIFIED => PSpecified
jca: 1.2.840.113549.1.1.10 => RSASSA_PSS
jca: RSASSA-PSS => RSASSA_PSS
jca: PSS => RSASSA_PSS
jca: 1.2.840.113549.1.1.11 => SHA256withRSA
jca: SHA256WITHRSA => SHA256withRSA
jca: 1.2.840.113549.1.1.12 => SHA384withRSA
jca: SHA384WITHRSA => SHA384withRSA
jca: 1.2.840.113549.1.1.13 => SHA512withRSA
jca: SHA512WITHRSA => SHA512withRSA
jca: 1.2.840.113549.1.1.14 => SHA224withRSA
jca: SHA224WITHRSA => SHA224withRSA
jca: 1.2.840.113549.1.1.15 => SHA512$224withRSA
jca: SHA512/224WITHRSA => SHA512$224withRSA
jca: 1.2.840.113549.1.1.16 => SHA512$256withRSA
jca: SHA512/256WITHRSA => SHA512$256withRSA
jca: 1.2.840.113549.1.3.1 => DiffieHellman
jca: DIFFIEHELLMAN => DiffieHellman
jca: DH => DiffieHellman
jca: 1.2.840.113549.1.5.3 => PBEWithMD5AndDES
jca: PBEWITHMD5ANDDES => PBEWithMD5AndDES
jca: 1.2.840.113549.1.5.6 => PBEWithMD5AndRC2
jca: PBEWITHMD5ANDRC2 => PBEWithMD5AndRC2
jca: 1.2.840.113549.1.5.10 => PBEWithSHA1AndDES
jca: PBEWITHSHA1ANDDES => PBEWithSHA1AndDES
jca: 1.2.840.113549.1.5.11 => PBEWithSHA1AndRC2
jca: PBEWITHSHA1ANDRC2 => PBEWithSHA1AndRC2
jca: 1.2.840.113549.1.5.12 => PBKDF2WithHmacSHA1
jca: PBKDF2WITHHMACSHA1 => PBKDF2WithHmacSHA1
jca: 1.2.840.113549.1.5.13 => PBES2
jca: PBES2 => PBES2
jca: 1.2.840.113549.1.7 => PKCS7
jca: PKCS7 => PKCS7
jca: 1.2.840.113549.1.7.1 => Data
jca: DATA => Data
jca: 1.2.840.113549.1.7.2 => SignedData
jca: SIGNEDDATA => SignedData
jca: 1.2.840.1113549.1.7.1 => JDK_OLD_Data
jca: JDK_OLD_DATA => JDK_OLD_Data
jca: 1.2.840.1113549.1.7.2 => JDK_OLD_SignedData
jca: JDK_OLD_SIGNEDDATA => JDK_OLD_SignedData
jca: 1.2.840.113549.1.7.3 => EnvelopedData
jca: ENVELOPEDDATA => EnvelopedData
jca: 1.2.840.113549.1.7.4 => SignedAndEnvelopedData
jca: SIGNEDANDENVELOPEDDATA => SignedAndEnvelopedData
jca: 1.2.840.113549.1.7.5 => DigestedData
jca: DIGESTEDDATA => DigestedData
jca: 1.2.840.113549.1.7.6 => EncryptedData
jca: ENCRYPTEDDATA => EncryptedData
jca: 1.2.840.113549.1.9.1 => EmailAddress
jca: EMAILADDRESS => EmailAddress
jca: 1.2.840.113549.1.9.2 => UnstructuredName
jca: UNSTRUCTUREDNAME => UnstructuredName
jca: 1.2.840.113549.1.9.3 => ContentType
jca: CONTENTTYPE => ContentType
jca: 1.2.840.113549.1.9.4 => MessageDigest
jca: MESSAGEDIGEST => MessageDigest
jca: 1.2.840.113549.1.9.5 => SigningTime
jca: SIGNINGTIME => SigningTime
jca: 1.2.840.113549.1.9.6 => CounterSignature
jca: COUNTERSIGNATURE => CounterSignature
jca: 1.2.840.113549.1.9.7 => ChallengePassword
jca: CHALLENGEPASSWORD => ChallengePassword
jca: 1.2.840.113549.1.9.8 => UnstructuredAddress
jca: UNSTRUCTUREDADDRESS => UnstructuredAddress
jca: 1.2.840.113549.1.9.9 => ExtendedCertificateAttributes
jca: EXTENDEDCERTIFICATEATTRIBUTES => ExtendedCertificateAttributes
jca: 1.2.840.113549.1.9.10 => IssuerAndSerialNumber
jca: ISSUERANDSERIALNUMBER => IssuerAndSerialNumber
jca: 1.2.840.113549.1.9.14 => ExtensionRequest
jca: EXTENSIONREQUEST => ExtensionRequest
jca: 1.2.840.113549.1.9.15 => SMIMECapability
jca: SMIMECAPABILITY => SMIMECapability
jca: 1.2.840.113549.1.9.16.1.4 => TimeStampTokenInfo
jca: TIMESTAMPTOKENINFO => TimeStampTokenInfo
jca: 1.2.840.113549.1.9.16.2.12 => SigningCertificate
jca: SIGNINGCERTIFICATE => SigningCertificate
jca: 1.2.840.113549.1.9.16.2.14 => SignatureTimestampToken
jca: SIGNATURETIMESTAMPTOKEN => SignatureTimestampToken
jca: 1.2.840.113549.1.9.16.3.17 => HSSLMS
jca: HSS/LMS => HSSLMS
jca: 1.2.840.113549.1.9.16.3.18 => CHACHA20_POLY1305
jca: CHACHA20-POLY1305 => CHACHA20_POLY1305
jca: 1.2.840.113549.1.9.20 => FriendlyName
jca: FRIENDLYNAME => FriendlyName
jca: 1.2.840.113549.1.9.21 => LocalKeyID
jca: LOCALKEYID => LocalKeyID
jca: 1.2.840.113549.1.9.22.1 => CertTypeX509
jca: CERTTYPEX509 => CertTypeX509
jca: 1.2.840.113549.1.9.52 => CMSAlgorithmProtection
jca: CMSALGORITHMPROTECTION => CMSAlgorithmProtection
jca: 1.2.840.113549.1.12.1.1 => PBEWithSHA1AndRC4_128
jca: PBEWITHSHA1ANDRC4_128 => PBEWithSHA1AndRC4_128
jca: 1.2.840.113549.1.12.1.2 => PBEWithSHA1AndRC4_40
jca: PBEWITHSHA1ANDRC4_40 => PBEWithSHA1AndRC4_40
jca: 1.2.840.113549.1.12.1.3 => PBEWithSHA1AndDESede
jca: PBEWITHSHA1ANDDESEDE => PBEWithSHA1AndDESede
jca: 1.2.840.113549.1.12.1.5 => PBEWithSHA1AndRC2_128
jca: PBEWITHSHA1ANDRC2_128 => PBEWithSHA1AndRC2_128
jca: 1.2.840.113549.1.12.1.6 => PBEWithSHA1AndRC2_40
jca: PBEWITHSHA1ANDRC2_40 => PBEWithSHA1AndRC2_40
jca: 1.2.840.113549.1.12.10.1.2 => PKCS8ShroudedKeyBag
jca: PKCS8SHROUDEDKEYBAG => PKCS8ShroudedKeyBag
jca: 1.2.840.113549.1.12.10.1.3 => CertBag
jca: CERTBAG => CertBag
jca: 1.2.840.113549.1.12.10.1.5 => SecretBag
jca: SECRETBAG => SecretBag
jca: 1.2.840.113549.2.2 => MD2
jca: MD2 => MD2
jca: 1.2.840.113549.2.5 => MD5
jca: MD5 => MD5
jca: 1.2.840.113549.2.7 => HmacSHA1
jca: HMACSHA1 => HmacSHA1
jca: 1.2.840.113549.2.8 => HmacSHA224
jca: HMACSHA224 => HmacSHA224
jca: 1.2.840.113549.2.9 => HmacSHA256
jca: HMACSHA256 => HmacSHA256
jca: 1.2.840.113549.2.10 => HmacSHA384
jca: HMACSHA384 => HmacSHA384
jca: 1.2.840.113549.2.11 => HmacSHA512
jca: HMACSHA512 => HmacSHA512
jca: 1.2.840.113549.2.12 => HmacSHA512$224
jca: HMACSHA512/224 => HmacSHA512$224
jca: 1.2.840.113549.2.13 => HmacSHA512$256
jca: HMACSHA512/256 => HmacSHA512$256
jca: 1.2.840.113549.3.2 => RC2$CBC$PKCS5Padding
jca: RC2/CBC/PKCS5PADDING => RC2$CBC$PKCS5Padding
jca: RC2 => RC2$CBC$PKCS5Padding
jca: 1.2.840.113549.3.4 => ARCFOUR
jca: ARCFOUR => ARCFOUR
jca: RC4 => ARCFOUR
jca: 1.2.840.113549.3.7 => DESede$CBC$NoPadding
jca: DESEDE/CBC/NOPADDING => DESede$CBC$NoPadding
jca: 1.2.840.113549.3.9 => RC5$CBC$PKCS5Padding
jca: RC5/CBC/PKCS5PADDING => RC5$CBC$PKCS5Padding
jca: 1.2.840.10040.4.1 => DSA
jca: DSA => DSA
jca: 1.2.840.10040.4.3 => SHA1withDSA
jca: SHA1WITHDSA => SHA1withDSA
jca: DSS => SHA1withDSA
jca: 1.2.840.10045.2.1 => EC
jca: EC => EC
jca: 1.2.840.10045.3.0.5 => c2tnb191v1
jca: X9.62 C2TNB191V1 => c2tnb191v1
jca: 1.2.840.10045.3.0.6 => c2tnb191v2
jca: X9.62 C2TNB191V2 => c2tnb191v2
jca: 1.2.840.10045.3.0.7 => c2tnb191v3
jca: X9.62 C2TNB191V3 => c2tnb191v3
jca: 1.2.840.10045.3.0.11 => c2tnb239v1
jca: X9.62 C2TNB239V1 => c2tnb239v1
jca: 1.2.840.10045.3.0.12 => c2tnb239v2
jca: X9.62 C2TNB239V2 => c2tnb239v2
jca: 1.2.840.10045.3.0.13 => c2tnb239v3
jca: X9.62 C2TNB239V3 => c2tnb239v3
jca: 1.2.840.10045.3.0.18 => c2tnb359v1
jca: X9.62 C2TNB359V1 => c2tnb359v1
jca: 1.2.840.10045.3.0.20 => c2tnb431r1
jca: X9.62 C2TNB431R1 => c2tnb431r1
jca: 1.2.840.10045.3.1.1 => secp192r1
jca: SECP192R1 => secp192r1
jca: NIST P-192 => secp192r1
jca: X9.62 PRIME192V1 => secp192r1
jca: 1.2.840.10045.3.1.2 => prime192v2
jca: X9.62 PRIME192V2 => prime192v2
jca: 1.2.840.10045.3.1.3 => prime192v3
jca: X9.62 PRIME192V3 => prime192v3
jca: 1.2.840.10045.3.1.4 => prime239v1
jca: X9.62 PRIME239V1 => prime239v1
jca: 1.2.840.10045.3.1.5 => prime239v2
jca: X9.62 PRIME239V2 => prime239v2
jca: 1.2.840.10045.3.1.6 => prime239v3
jca: X9.62 PRIME239V3 => prime239v3
jca: 1.2.840.10045.3.1.7 => secp256r1
jca: SECP256R1 => secp256r1
jca: NIST P-256 => secp256r1
jca: X9.62 PRIME256V1 => secp256r1
jca: 1.2.840.10045.4.1 => SHA1withECDSA
jca: SHA1WITHECDSA => SHA1withECDSA
jca: 1.2.840.10045.4.3.1 => SHA224withECDSA
jca: SHA224WITHECDSA => SHA224withECDSA
jca: 1.2.840.10045.4.3.2 => SHA256withECDSA
jca: SHA256WITHECDSA => SHA256withECDSA
jca: 1.2.840.10045.4.3.3 => SHA384withECDSA
jca: SHA384WITHECDSA => SHA384withECDSA
jca: 1.2.840.10045.4.3.4 => SHA512withECDSA
jca: SHA512WITHECDSA => SHA512withECDSA
jca: 1.2.840.10045.4.3 => SpecifiedSHA2withECDSA
jca: SPECIFIEDSHA2WITHECDSA => SpecifiedSHA2withECDSA
jca: 1.2.840.10046.2.1 => X942_DH
jca: 1.3.36.3.3.2.8.1.1.1 => brainpoolP160r1
jca: BRAINPOOLP160R1 => brainpoolP160r1
jca: 1.3.36.3.3.2.8.1.1.3 => brainpoolP192r1
jca: BRAINPOOLP192R1 => brainpoolP192r1
jca: 1.3.36.3.3.2.8.1.1.5 => brainpoolP224r1
jca: BRAINPOOLP224R1 => brainpoolP224r1
jca: 1.3.36.3.3.2.8.1.1.7 => brainpoolP256r1
jca: BRAINPOOLP256R1 => brainpoolP256r1
jca: 1.3.36.3.3.2.8.1.1.9 => brainpoolP320r1
jca: BRAINPOOLP320R1 => brainpoolP320r1
jca: 1.3.36.3.3.2.8.1.1.11 => brainpoolP384r1
jca: BRAINPOOLP384R1 => brainpoolP384r1
jca: 1.3.36.3.3.2.8.1.1.13 => brainpoolP512r1
jca: BRAINPOOLP512R1 => brainpoolP512r1
jca: 1.3.132.0.1 => sect163k1
jca: SECT163K1 => sect163k1
jca: NIST K-163 => sect163k1
jca: 1.3.132.0.2 => sect163r1
jca: SECT163R1 => sect163r1
jca: 1.3.132.0.3 => sect239k1
jca: SECT239K1 => sect239k1
jca: 1.3.132.0.4 => sect113r1
jca: SECT113R1 => sect113r1
jca: 1.3.132.0.5 => sect113r2
jca: SECT113R2 => sect113r2
jca: 1.3.132.0.6 => secp112r1
jca: SECP112R1 => secp112r1
jca: 1.3.132.0.7 => secp112r2
jca: SECP112R2 => secp112r2
jca: 1.3.132.0.8 => secp160r1
jca: SECP160R1 => secp160r1
jca: 1.3.132.0.9 => secp160k1
jca: SECP160K1 => secp160k1
jca: 1.3.132.0.10 => secp256k1
jca: SECP256K1 => secp256k1
jca: 1.3.132.0.15 => sect163r2
jca: SECT163R2 => sect163r2
jca: NIST B-163 => sect163r2
jca: 1.3.132.0.16 => sect283k1
jca: SECT283K1 => sect283k1
jca: NIST K-283 => sect283k1
jca: 1.3.132.0.17 => sect283r1
jca: SECT283R1 => sect283r1
jca: NIST B-283 => sect283r1
jca: 1.3.132.0.22 => sect131r1
jca: SECT131R1 => sect131r1
jca: 1.3.132.0.23 => sect131r2
jca: SECT131R2 => sect131r2
jca: 1.3.132.0.24 => sect193r1
jca: SECT193R1 => sect193r1
jca: 1.3.132.0.25 => sect193r2
jca: SECT193R2 => sect193r2
jca: 1.3.132.0.26 => sect233k1
jca: SECT233K1 => sect233k1
jca: NIST K-233 => sect233k1
jca: 1.3.132.0.27 => sect233r1
jca: SECT233R1 => sect233r1
jca: NIST B-233 => sect233r1
jca: 1.3.132.0.28 => secp128r1
jca: SECP128R1 => secp128r1
jca: 1.3.132.0.29 => secp128r2
jca: SECP128R2 => secp128r2
jca: 1.3.132.0.30 => secp160r2
jca: SECP160R2 => secp160r2
jca: 1.3.132.0.31 => secp192k1
jca: SECP192K1 => secp192k1
jca: 1.3.132.0.32 => secp224k1
jca: SECP224K1 => secp224k1
jca: 1.3.132.0.33 => secp224r1
jca: SECP224R1 => secp224r1
jca: NIST P-224 => secp224r1
jca: 1.3.132.0.34 => secp384r1
jca: SECP384R1 => secp384r1
jca: NIST P-384 => secp384r1
jca: 1.3.132.0.35 => secp521r1
jca: SECP521R1 => secp521r1
jca: NIST P-521 => secp521r1
jca: 1.3.132.0.36 => sect409k1
jca: SECT409K1 => sect409k1
jca: NIST K-409 => sect409k1
jca: 1.3.132.0.37 => sect409r1
jca: SECT409R1 => sect409r1
jca: NIST B-409 => sect409r1
jca: 1.3.132.0.38 => sect571k1
jca: SECT571K1 => sect571k1
jca: NIST K-571 => sect571k1
jca: 1.3.132.0.39 => sect571r1
jca: SECT571R1 => sect571r1
jca: NIST B-571 => sect571r1
jca: 1.3.132.1.12 => ECDH
jca: ECDH => ECDH
jca: 1.3.14.3.2.7 => OIW_DES_CBC
jca: DES/CBC => OIW_DES_CBC
jca: DES => OIW_DES_CBC
jca: 1.3.14.3.2.12 => OIW_DSA
jca: 1.3.14.3.2.13 => OIW_JDK_SHA1withDSA
jca: 1.3.14.3.2.15 => OIW_SHA1withRSA_Odd
jca: 1.3.14.3.2.17 => DESede
jca: DESEDE => DESede
jca: 1.3.14.3.2.26 => SHA_1
jca: SHA-1 => SHA_1
jca: SHA => SHA_1
jca: SHA1 => SHA_1
jca: 1.3.14.3.2.27 => OIW_SHA1withDSA
jca: 1.3.14.3.2.29 => OIW_SHA1withRSA
jca: 1.3.101.110 => X25519
jca: X25519 => X25519
jca: 1.3.101.111 => X448
jca: X448 => X448
jca: 1.3.101.112 => Ed25519
jca: ED25519 => Ed25519
jca: 1.3.101.113 => Ed448
jca: ED448 => Ed448
jca: 0.9.2342.19200300.100.1.1 => UCL_UserID
jca: UCL_USERID => UCL_UserID
jca: 0.9.2342.19200300.100.1.25 => UCL_DomainComponent
jca: UCL_DOMAINCOMPONENT => UCL_DomainComponent
jca: 2.16.840.1.113730.1.1 => NETSCAPE_CertType
jca: NETSCAPE_CERTTYPE => NETSCAPE_CertType
jca: 2.16.840.1.113730.2.5 => NETSCAPE_CertSequence
jca: NETSCAPE_CERTSEQUENCE => NETSCAPE_CertSequence
jca: 2.16.840.1.113730.4.1 => NETSCAPE_ExportApproved
jca: NETSCAPE_EXPORTAPPROVED => NETSCAPE_ExportApproved
jca: 2.16.840.1.113894.746875.1.1 => ORACLE_TrustedKeyUsage
jca: ORACLE_TRUSTEDKEYUSAGE => ORACLE_TrustedKeyUsage
jca: 2.5.8.1.1 => ITUX509_RSA
jca: 1.3.6.1.4.1.42.2.11.2.1 => SkipIPAddress
jca: SKIPIPADDRESS => SkipIPAddress
jca: 1.3.6.1.4.1.42.2.17.1.1 => JAVASOFT_JDKKeyProtector
jca: JAVASOFT_JDKKEYPROTECTOR => JAVASOFT_JDKKeyProtector
jca: 1.3.6.1.4.1.42.2.19.1 => JAVASOFT_JCEKeyProtector
jca: JAVASOFT_JCEKEYPROTECTOR => JAVASOFT_JCEKeyProtector
jca: 1.3.6.1.4.1.311.10.3.3 => MICROSOFT_ExportApproved
jca: MICROSOFT_EXPORTAPPROVED => MICROSOFT_ExportApproved
jca: 1.3.6.1.4.1.3029.1.1.2 => Blowfish
jca: BLOWFISH => Blowfish
Provider: SUN.putService(): SUN: SecureRandom.NativePRNG -> sun.security.provider.NativePRNG
  attributes: {ThreadSafe=true}

Provider: Add SecureRandom algo NativePRNG
Provider: SUN.putService(): SUN: SecureRandom.NativePRNGBlocking -> sun.security.provider.NativePRNG$Blocking
  attributes: {ThreadSafe=true}

Provider: Add SecureRandom algo NativePRNGBlocking
Provider: SUN.putService(): SUN: SecureRandom.NativePRNGNonBlocking -> sun.security.provider.NativePRNG$NonBlocking
  attributes: {ThreadSafe=true}

Provider: Add SecureRandom algo NativePRNGNonBlocking
Provider: SUN.putService(): SUN: SecureRandom.DRBG -> sun.security.provider.DRBG
  attributes: {ImplementedIn=Software, ThreadSafe=true}

Provider: Add SecureRandom algo DRBG
Provider: SUN.putService(): SUN: SecureRandom.SHA1PRNG -> sun.security.provider.SecureRandom
  attributes: {ImplementedIn=Software, ThreadSafe=true}

Provider: Add SecureRandom algo SHA1PRNG
Provider: SUN.putService(): SUN: Signature.SHA1withDSA -> sun.security.provider.DSA$SHA1withDSA
  aliases: [OID.1.2.840.10040.4.3, 1.2.840.10040.4.3, DSS, 1.3.14.3.2.13, 1.3.14.3.2.27, DSA, SHA/DSA, SHA-1/DSA, SHA1/DSA, SHAwithDSA, DSAWithSHA1]
  attributes: {ImplementedIn=Software, KeySize=1024, SupportedKeyClasses=java.security.interfaces.DSAPublicKey|java.security.interfaces.DSAPrivateKey}

Provider: SUN.putService(): SUN: Signature.NONEwithDSA -> sun.security.provider.DSA$RawDSA
  aliases: [RawDSA]
  attributes: {ImplementedIn=Software, KeySize=1024, SupportedKeyClasses=java.security.interface

...
Output overflow:
JT Harness has limited the test output to the text
at the beginning and the end, so that you can see how the
test began, and how it completed.

If you need to see more of the output from the test,
set the system property javatest.maxOutputSize to a higher
value. The current value is 100000
...


  attributes: {SupportedKeyFormats=RAW, SupportedModes=GCM}

Provider: SunJCE.putService(): SunJCE: Cipher.AES_192/GCM/NoPadding -> com.sun.crypto.provider.GaloisCounterMode$AES192
  aliases: [OID.2.16.840.1.101.3.4.1.26, 2.16.840.1.101.3.4.1.26]
  attributes: {SupportedKeyFormats=RAW, SupportedModes=GCM}

Provider: SunJCE.putService(): SunJCE: Cipher.AES_256/GCM/NoPadding -> com.sun.crypto.provider.GaloisCounterMode$AES256
  aliases: [OID.2.16.840.1.101.3.4.1.46, 2.16.840.1.101.3.4.1.46]
  attributes: {SupportedKeyFormats=RAW, SupportedModes=GCM}

Provider: SunJCE.putService(): SunJCE: Cipher.DESedeWrap -> com.sun.crypto.provider.DESedeWrapCipher
  attributes: {SupportedKeyFormats=RAW, SupportedModes=CBC, SupportedPaddings=NOPADDING}

Provider: SunJCE.putService(): SunJCE: Cipher.ARCFOUR -> com.sun.crypto.provider.ARCFOURCipher
  aliases: [OID.1.2.840.113549.3.4, 1.2.840.113549.3.4, RC4]
  attributes: {SupportedKeyFormats=RAW, SupportedModes=ECB, SupportedPaddings=NOPADDING}

Provider: SunJCE.putService(): SunJCE: Cipher.ChaCha20 -> com.sun.crypto.provider.ChaCha20Cipher$ChaCha20Only
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Cipher.ChaCha20-Poly1305 -> com.sun.crypto.provider.ChaCha20Cipher$ChaCha20Poly1305
  aliases: [OID.1.2.840.113549.1.9.16.3.18, 1.2.840.113549.1.9.16.3.18]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithMD5AndDES -> com.sun.crypto.provider.PBEWithMD5AndDESCipher
  aliases: [OID.1.2.840.113549.1.5.3, 1.2.840.113549.1.5.3, PBE]

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithMD5AndTripleDES -> com.sun.crypto.provider.PBEWithMD5AndTripleDESCipher

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithSHA1AndDESede -> com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndDESede
  aliases: [OID.1.2.840.113549.1.12.1.3, 1.2.840.113549.1.12.1.3]

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithSHA1AndRC2_40 -> com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndRC2_40
  aliases: [OID.1.2.840.113549.1.12.1.6, 1.2.840.113549.1.12.1.6]

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithSHA1AndRC2_128 -> com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndRC2_128
  aliases: [OID.1.2.840.113549.1.12.1.5, 1.2.840.113549.1.12.1.5]

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithSHA1AndRC4_40 -> com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndRC4_40
  aliases: [OID.1.2.840.113549.1.12.1.2, 1.2.840.113549.1.12.1.2]

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithSHA1AndRC4_128 -> com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndRC4_128
  aliases: [OID.1.2.840.113549.1.12.1.1, 1.2.840.113549.1.12.1.1]

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA1AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA1AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA224AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA224AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA256AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA256AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA384AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA384AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA512AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA512AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA512/224AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA512_224AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA512/256AndAES_128 -> com.sun.crypto.provider.PBES2Core$HmacSHA512_256AndAES_128

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA1AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA1AndAES_256

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA224AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA224AndAES_256

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA256AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA256AndAES_256

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA384AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA384AndAES_256

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA512AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA512AndAES_256

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA512/224AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA512_224AndAES_256

Provider: SunJCE.putService(): SunJCE: Cipher.PBEWithHmacSHA512/256AndAES_256 -> com.sun.crypto.provider.PBES2Core$HmacSHA512_256AndAES_256

Provider: SunJCE.putService(): SunJCE: KeyGenerator.DES -> com.sun.crypto.provider.DESKeyGenerator

Provider: SunJCE.putService(): SunJCE: KeyGenerator.DESede -> com.sun.crypto.provider.DESedeKeyGenerator
  aliases: [TripleDES]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.Blowfish -> com.sun.crypto.provider.BlowfishKeyGenerator

Provider: SunJCE.putService(): SunJCE: KeyGenerator.AES -> com.sun.crypto.provider.AESKeyGenerator
  aliases: [OID.2.16.840.1.101.3.4.1, 2.16.840.1.101.3.4.1]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.RC2 -> com.sun.crypto.provider.KeyGeneratorCore$RC2KeyGenerator

Provider: SunJCE.putService(): SunJCE: KeyGenerator.ARCFOUR -> com.sun.crypto.provider.KeyGeneratorCore$ARCFOURKeyGenerator
  aliases: [OID.1.2.840.113549.3.4, 1.2.840.113549.3.4, RC4]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.ChaCha20 -> com.sun.crypto.provider.KeyGeneratorCore$ChaCha20KeyGenerator

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacMD5 -> com.sun.crypto.provider.HmacMD5KeyGenerator

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA1 -> com.sun.crypto.provider.HmacSHA1KeyGenerator
  aliases: [OID.1.2.840.113549.2.7, 1.2.840.113549.2.7]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA224 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA224
  aliases: [OID.1.2.840.113549.2.8, 1.2.840.113549.2.8]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA256 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA256
  aliases: [OID.1.2.840.113549.2.9, 1.2.840.113549.2.9]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA384 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA384
  aliases: [OID.1.2.840.113549.2.10, 1.2.840.113549.2.10]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA512 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA512
  aliases: [OID.1.2.840.113549.2.11, 1.2.840.113549.2.11]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA512/224 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA512_224
  aliases: [OID.1.2.840.113549.2.12, 1.2.840.113549.2.12]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA512/256 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA512_256
  aliases: [OID.1.2.840.113549.2.13, 1.2.840.113549.2.13]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA3-224 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA3_224
  aliases: [OID.2.16.840.1.101.3.4.2.13, 2.16.840.1.101.3.4.2.13]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA3-256 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA3_256
  aliases: [OID.2.16.840.1.101.3.4.2.14, 2.16.840.1.101.3.4.2.14]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA3-384 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA3_384
  aliases: [OID.2.16.840.1.101.3.4.2.15, 2.16.840.1.101.3.4.2.15]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.HmacSHA3-512 -> com.sun.crypto.provider.KeyGeneratorCore$HmacKG$SHA3_512
  aliases: [OID.2.16.840.1.101.3.4.2.16, 2.16.840.1.101.3.4.2.16]

Provider: SunJCE.putService(): SunJCE: KeyPairGenerator.DiffieHellman -> com.sun.crypto.provider.DHKeyPairGenerator
  aliases: [OID.1.2.840.113549.1.3.1, 1.2.840.113549.1.3.1, DH]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameterGenerator.DiffieHellman -> com.sun.crypto.provider.DHParameterGenerator
  aliases: [OID.1.2.840.113549.1.3.1, 1.2.840.113549.1.3.1, DH]

Provider: SunJCE.putService(): SunJCE: KeyAgreement.DiffieHellman -> com.sun.crypto.provider.DHKeyAgreement
  aliases: [OID.1.2.840.113549.1.3.1, 1.2.840.113549.1.3.1, DH]
  attributes: {SupportedKeyClasses=javax.crypto.interfaces.DHPublicKey|javax.crypto.interfaces.DHPrivateKey}

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.DiffieHellman -> com.sun.crypto.provider.DHParameters
  aliases: [OID.1.2.840.113549.1.3.1, 1.2.840.113549.1.3.1, DH]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.DES -> com.sun.crypto.provider.DESParameters

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.DESede -> com.sun.crypto.provider.DESedeParameters
  aliases: [TripleDES]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithMD5AndDES -> com.sun.crypto.provider.PBEParameters
  aliases: [OID.1.2.840.113549.1.5.3, 1.2.840.113549.1.5.3, PBE]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithMD5AndTripleDES -> com.sun.crypto.provider.PBEParameters

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithSHA1AndDESede -> com.sun.crypto.provider.PBEParameters
  aliases: [OID.1.2.840.113549.1.12.1.3, 1.2.840.113549.1.12.1.3]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithSHA1AndRC2_40 -> com.sun.crypto.provider.PBEParameters
  aliases: [OID.1.2.840.113549.1.12.1.6, 1.2.840.113549.1.12.1.6]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithSHA1AndRC2_128 -> com.sun.crypto.provider.PBEParameters
  aliases: [OID.1.2.840.113549.1.12.1.5, 1.2.840.113549.1.12.1.5]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithSHA1AndRC4_40 -> com.sun.crypto.provider.PBEParameters
  aliases: [OID.1.2.840.113549.1.12.1.2, 1.2.840.113549.1.12.1.2]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithSHA1AndRC4_128 -> com.sun.crypto.provider.PBEParameters
  aliases: [OID.1.2.840.113549.1.12.1.1, 1.2.840.113549.1.12.1.1]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBES2 -> com.sun.crypto.provider.PBES2Parameters$General
  aliases: [OID.1.2.840.113549.1.5.13, 1.2.840.113549.1.5.13]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA1AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA1AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA224AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA224AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA256AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA256AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA384AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA384AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA512AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA512AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA512/224AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA512_224AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA512/256AndAES_128 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA512_256AndAES_128

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA1AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA1AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA224AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA224AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA256AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA256AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA384AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA384AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA512AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA512AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA512/224AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA512_224AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.PBEWithHmacSHA512/256AndAES_256 -> com.sun.crypto.provider.PBES2Parameters$HmacSHA512_256AndAES_256

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.Blowfish -> com.sun.crypto.provider.BlowfishParameters

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.AES -> com.sun.crypto.provider.AESParameters
  aliases: [OID.2.16.840.1.101.3.4.1, 2.16.840.1.101.3.4.1]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.GCM -> com.sun.crypto.provider.GCMParameters

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.RC2 -> com.sun.crypto.provider.RC2Parameters

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.OAEP -> com.sun.crypto.provider.OAEPParameters
  aliases: [OID.1.2.840.113549.1.1.7, 1.2.840.113549.1.1.7]

Provider: SunJCE.putService(): SunJCE: AlgorithmParameters.ChaCha20-Poly1305 -> com.sun.crypto.provider.ChaCha20Poly1305Parameters
  aliases: [OID.1.2.840.113549.1.9.16.3.18, 1.2.840.113549.1.9.16.3.18]

Provider: SunJCE.putService(): SunJCE: KeyFactory.DiffieHellman -> com.sun.crypto.provider.DHKeyFactory
  aliases: [OID.1.2.840.113549.1.3.1, 1.2.840.113549.1.3.1, DH]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.DES -> com.sun.crypto.provider.DESKeyFactory

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.DESede -> com.sun.crypto.provider.DESedeKeyFactory
  aliases: [TripleDES]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithMD5AndDES -> com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndDES
  aliases: [OID.1.2.840.113549.1.5.3, 1.2.840.113549.1.5.3, PBE]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithMD5AndTripleDES -> com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndTripleDES

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithSHA1AndDESede -> com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndDESede
  aliases: [OID.1.2.840.113549.1.12.1.3, 1.2.840.113549.1.12.1.3]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithSHA1AndRC2_40 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndRC2_40
  aliases: [OID.1.2.840.113549.1.12.1.6, 1.2.840.113549.1.12.1.6]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithSHA1AndRC2_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndRC2_128
  aliases: [OID.1.2.840.113549.1.12.1.5, 1.2.840.113549.1.12.1.5]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithSHA1AndRC4_40 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndRC4_40
  aliases: [OID.1.2.840.113549.1.12.1.2, 1.2.840.113549.1.12.1.2]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithSHA1AndRC4_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndRC4_128
  aliases: [OID.1.2.840.113549.1.12.1.1, 1.2.840.113549.1.12.1.1]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA1AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA1AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA224AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA224AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA256AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA256AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA384AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA384AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA512AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA512AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA512/224AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA512_224AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA512/256AndAES_128 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA512_256AndAES_128

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA1AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA1AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA224AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA224AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA256AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA256AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA384AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA384AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA512AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA512AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA512/224AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA512_224AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBEWithHmacSHA512/256AndAES_256 -> com.sun.crypto.provider.PBEKeyFactory$PBEWithHmacSHA512_256AndAES_256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA1 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA1
  aliases: [OID.1.2.840.113549.1.5.12, 1.2.840.113549.1.5.12]

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA224 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA224

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA256 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA256

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA384 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA384

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA512 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA512

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA512/224 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA512_224

Provider: SunJCE.putService(): SunJCE: SecretKeyFactory.PBKDF2WithHmacSHA512/256 -> com.sun.crypto.provider.PBKDF2Core$HmacSHA512_256

Provider: SunJCE.putService(): SunJCE: Mac.HmacMD5 -> com.sun.crypto.provider.HmacMD5
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA1 -> com.sun.crypto.provider.HmacSHA1
  aliases: [OID.1.2.840.113549.2.7, 1.2.840.113549.2.7]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA224 -> com.sun.crypto.provider.HmacCore$HmacSHA224
  aliases: [OID.1.2.840.113549.2.8, 1.2.840.113549.2.8]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA256 -> com.sun.crypto.provider.HmacCore$HmacSHA256
  aliases: [OID.1.2.840.113549.2.9, 1.2.840.113549.2.9]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA384 -> com.sun.crypto.provider.HmacCore$HmacSHA384
  aliases: [OID.1.2.840.113549.2.10, 1.2.840.113549.2.10]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA512 -> com.sun.crypto.provider.HmacCore$HmacSHA512
  aliases: [OID.1.2.840.113549.2.11, 1.2.840.113549.2.11]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA512/224 -> com.sun.crypto.provider.HmacCore$HmacSHA512_224
  aliases: [OID.1.2.840.113549.2.12, 1.2.840.113549.2.12]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA512/256 -> com.sun.crypto.provider.HmacCore$HmacSHA512_256
  aliases: [OID.1.2.840.113549.2.13, 1.2.840.113549.2.13]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA3-224 -> com.sun.crypto.provider.HmacCore$HmacSHA3_224
  aliases: [OID.2.16.840.1.101.3.4.2.13, 2.16.840.1.101.3.4.2.13]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA3-256 -> com.sun.crypto.provider.HmacCore$HmacSHA3_256
  aliases: [OID.2.16.840.1.101.3.4.2.14, 2.16.840.1.101.3.4.2.14]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA3-384 -> com.sun.crypto.provider.HmacCore$HmacSHA3_384
  aliases: [OID.2.16.840.1.101.3.4.2.15, 2.16.840.1.101.3.4.2.15]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacSHA3-512 -> com.sun.crypto.provider.HmacCore$HmacSHA3_512
  aliases: [OID.2.16.840.1.101.3.4.2.16, 2.16.840.1.101.3.4.2.16]
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA1 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA1
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA224 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA224
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA256 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA256
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA384 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA384
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA512 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA512
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA512/224 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA512_224
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.HmacPBESHA512/256 -> com.sun.crypto.provider.HmacPKCS12PBECore$HmacPKCS12PBE_SHA512_256
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA1 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA1
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA224 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA224
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA256 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA256
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA384 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA384
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA512 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA512
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA512/224 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA512_224
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.PBEWithHmacSHA512/256 -> com.sun.crypto.provider.PBMAC1Core$HmacSHA512_256
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.SslMacMD5 -> com.sun.crypto.provider.SslMacCore$SslMacMD5
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: Mac.SslMacSHA1 -> com.sun.crypto.provider.SslMacCore$SslMacSHA1
  attributes: {SupportedKeyFormats=RAW}

Provider: SunJCE.putService(): SunJCE: KeyStore.JCEKS -> com.sun.crypto.provider.JceKeyStore

Provider: SunJCE.putService(): SunJCE: KEM.DHKEM -> com.sun.crypto.provider.DHKEM
  attributes: {ImplementedIn=Software, SupportedKeyClasses=java.security.interfaces.ECKey|java.security.interfaces.XECKey}

Provider: SunJCE.putService(): SunJCE: KeyGenerator.SunTlsPrf -> com.sun.crypto.provider.TlsPrfGenerator$V10

Provider: SunJCE.putService(): SunJCE: KeyGenerator.SunTls12Prf -> com.sun.crypto.provider.TlsPrfGenerator$V12

Provider: SunJCE.putService(): SunJCE: KeyGenerator.SunTlsMasterSecret -> com.sun.crypto.provider.TlsMasterSecretGenerator
  aliases: [SunTls12MasterSecret, SunTlsExtendedMasterSecret]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.SunTlsKeyMaterial -> com.sun.crypto.provider.TlsKeyMaterialGenerator
  aliases: [SunTls12KeyMaterial]

Provider: SunJCE.putService(): SunJCE: KeyGenerator.SunTlsRsaPremasterSecret -> com.sun.crypto.provider.TlsRsaPremasterSecretGenerator
  aliases: [SunTls12RsaPremasterSecret]

ProviderConfig: Loading provider SunJGSS
ProviderConfig: Attempt to load SunJGSS using SL
scl:  getPermissions ProtectionDomain  (jrt:/jdk.security.jgss <no signer certificates>)
 jdk.internal.loader.ClassLoaders$PlatformClassLoader at 3b1fbc70
 <no principals>
 java.security.Permissions at 3941a79c (
 ("java.lang.RuntimePermission" "accessSystemModules")
)


scl: 
Provider: JdkSASL.putService(): JdkSASL: SaslClientFactory.GSSAPI -> com.sun.security.sasl.gsskerb.FactoryImpl

Provider: JdkSASL.putService(): JdkSASL: SaslServerFactory.GSSAPI -> com.sun.security.sasl.gsskerb.FactoryImpl

ProviderConfig: Found SL Provider named JdkSASL
scl:  getPermissions ProtectionDomain  (jrt:/java.smartcardio <no signer certificates>)
 jdk.internal.loader.ClassLoaders$PlatformClassLoader at 3b1fbc70
 <no principals>
 java.security.Permissions at 3d494fbf (
 ("java.lang.RuntimePermission" "accessSystemModules")
)


scl: 
Provider: SunPCSC.putService(): SunPCSC: TerminalFactory.PC/SC -> sun.security.smartcardio.SunPCSC$Factory

ProviderConfig: Found SL Provider named SunPCSC
scl:  getPermissions ProtectionDomain  (jrt:/jdk.crypto.cryptoki <no signer certificates>)
 jdk.internal.loader.ClassLoaders$PlatformClassLoader at 3b1fbc70
 <no principals>
 java.security.Permissions at 7cd84586 (
 ("java.lang.RuntimePermission" "accessSystemModules")
)


scl: 
ProviderConfig: Found SL Provider named SunPKCS11
scl:  getPermissions ProtectionDomain  (jrt:/java.xml.crypto <no signer certificates>)
 jdk.internal.loader.ClassLoaders$PlatformClassLoader at 3b1fbc70
 <no principals>
 java.security.Permissions at 1e80bfe8 (
 ("java.lang.RuntimePermission" "accessSystemModules")
)


scl: 
Provider: XMLDSig.putService(): XMLDSig: XMLSignatureFactory.DOM -> org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory

Provider: XMLDSig.putService(): XMLDSig: KeyInfoFactory.DOM -> org.jcp.xml.dsig.internal.dom.DOMKeyInfoFactory

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/TR/2001/REC-xml-c14n-20010315 -> org.jcp.xml.dsig.internal.dom.DOMCanonicalXMLC14NMethod
  aliases: [INCLUSIVE]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments -> org.jcp.xml.dsig.internal.dom.DOMCanonicalXMLC14NMethod
  aliases: [INCLUSIVE_WITH_COMMENTS]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2006/12/xml-c14n11 -> org.jcp.xml.dsig.internal.dom.DOMCanonicalXMLC14N11Method
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2006/12/xml-c14n11#WithComments -> org.jcp.xml.dsig.internal.dom.DOMCanonicalXMLC14N11Method
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2001/10/xml-exc-c14n# -> org.jcp.xml.dsig.internal.dom.DOMExcC14NMethod
  aliases: [EXCLUSIVE]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2001/10/xml-exc-c14n#WithComments -> org.jcp.xml.dsig.internal.dom.DOMExcC14NMethod
  aliases: [EXCLUSIVE_WITH_COMMENTS]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2000/09/xmldsig#base64 -> org.jcp.xml.dsig.internal.dom.DOMBase64Transform
  aliases: [BASE64]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2000/09/xmldsig#enveloped-signature -> org.jcp.xml.dsig.internal.dom.DOMEnvelopedTransform
  aliases: [ENVELOPED]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/2002/06/xmldsig-filter2 -> org.jcp.xml.dsig.internal.dom.DOMXPathFilter2Transform
  aliases: [XPATH2]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/TR/1999/REC-xpath-19991116 -> org.jcp.xml.dsig.internal.dom.DOMXPathTransform
  aliases: [XPATH]
  attributes: {MechanismType=DOM}

Provider: XMLDSig.putService(): XMLDSig: TransformService.http://www.w3.org/TR/1999/REC-xslt-19991116 -> org.jcp.xml.dsig.internal.dom.DOMXSLTTransform
  aliases: [XSLT]
  attributes: {MechanismType=DOM}

ProviderConfig: Found SL Provider named XMLDSig
scl:  getPermissions ProtectionDomain  (jrt:/java.security.jgss <no signer certificates>)
 jdk.internal.loader.ClassLoaders$PlatformClassLoader at 3b1fbc70
 <no principals>
 java.security.Permissions at 65b3120a (
 ("java.lang.RuntimePermission" "accessSystemModules")
)


scl: 
Provider: SunJGSS.putService(): SunJGSS: GssApiMechanism.1.2.840.113554.1.2.2 -> sun.security.jgss.krb5.Krb5MechFactory

Provider: SunJGSS.putService(): SunJGSS: GssApiMechanism.1.3.6.1.5.5.2 -> sun.security.jgss.spnego.SpNegoMechFactory

ProviderConfig: Found SL Provider named SunJGSS
ProviderConfig: Loaded provider SunJGSS
ProviderConfig: Loading provider SunSASL
ProviderConfig: Attempt to load SunSASL using SL
ProviderConfig: Found SL Provider named JdkSASL
ProviderConfig: Found SL Provider named SunPCSC
ProviderConfig: Found SL Provider named SunPKCS11
ProviderConfig: Found SL Provider named XMLDSig
ProviderConfig: Found SL Provider named SunJGSS
Provider: SunSASL.putService(): SunSASL: SaslClientFactory.DIGEST-MD5 -> com.sun.security.sasl.digest.FactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslClientFactory.NTLM -> com.sun.security.sasl.ntlm.FactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslClientFactory.EXTERNAL -> com.sun.security.sasl.ClientFactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslClientFactory.PLAIN -> com.sun.security.sasl.ClientFactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslClientFactory.CRAM-MD5 -> com.sun.security.sasl.ClientFactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslServerFactory.CRAM-MD5 -> com.sun.security.sasl.ServerFactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslServerFactory.DIGEST-MD5 -> com.sun.security.sasl.digest.FactoryImpl

Provider: SunSASL.putService(): SunSASL: SaslServerFactory.NTLM -> com.sun.security.sasl.ntlm.FactoryImpl

ProviderConfig: Found SL Provider named SunSASL
ProviderConfig: Loaded provider SunSASL
ProviderConfig: Loading provider XMLDSig
ProviderConfig: Attempt to load XMLDSig using SL
ProviderConfig: Found SL Provider named JdkSASL
ProviderConfig: Found SL Provider named SunPCSC
ProviderConfig: Found SL Provider named SunPKCS11
ProviderConfig: Found SL Provider named XMLDSig
ProviderConfig: Loaded provider XMLDSig
ProviderConfig: Loading provider SunPCSC
ProviderConfig: Attempt to load SunPCSC using SL
ProviderConfig: Found SL Provider named JdkSASL
ProviderConfig: Found SL Provider named SunPCSC
ProviderConfig: Loaded provider SunPCSC
ProviderConfig: Loading provider JdkLDAP
ProviderConfig: Attempt to load JdkLDAP using SL
ProviderConfig: Found SL Provider named JdkSASL
ProviderConfig: Found SL Provider named SunPCSC
ProviderConfig: Found SL Provider named SunPKCS11
ProviderConfig: Found SL Provider named XMLDSig
ProviderConfig: Found SL Provider named SunJGSS
ProviderConfig: Found SL Provider named SunSASL
Provider: JdkLDAP.putService(): JdkLDAP: CertStore.LDAP -> sun.security.provider.certpath.ldap.LDAPCertStore
  attributes: {ImplementedIn=Software, LDAPSchema=RFC2587}

ProviderConfig: Found SL Provider named JdkLDAP
ProviderConfig: Loaded provider JdkLDAP
ProviderConfig: Loading provider JdkSASL
ProviderConfig: Attempt to load JdkSASL using SL
ProviderConfig: Found SL Provider named JdkSASL
ProviderConfig: Loaded provider JdkSASL
ProviderConfig: Loading provider SunPKCS11
ProviderConfig: Attempt to load SunPKCS11 using SL
ProviderConfig: Found SL Provider named JdkSASL
ProviderConfig: Found SL Provider named SunPCSC
ProviderConfig: Found SL Provider named SunPKCS11
ProviderConfig: Loaded provider SunPKCS11
]
 exitValue = 0


/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/jdk/conf/security/java.security
------------------------------------------------------------------------------------
# Property to determine if this properties file was parsed and not overwritten:
java.security=applied
# ----------------------------
# Property to be overwritten by every properties file (master, extra or included):
last-file=java.security
# ----------------------------
include /home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/file0.properties


/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/extra.properties
------------------------------------------------------------------------------------
# Property to determine if this properties file was parsed and not overwritten:
extra.properties=applied
# ----------------------------
# Property to be overwritten by every properties file (master, extra or included):
last-file=extra.properties
# ----------------------------
include dir1/dir2/${props.none}${props.fileName}


/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/file0.properties
------------------------------------------------------------------------------------
# Property to determine if this properties file was parsed and not overwritten:
file0.properties=applied
# ----------------------------
# Property to be overwritten by every properties file (master, extra or included):
last-file=file0.properties
# ----------------------------


/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/file1.properties
------------------------------------------------------------------------------------
# Property to determine if this properties file was parsed and not overwritten:
file1.properties=applied
# ----------------------------
# Property to be overwritten by every properties file (master, extra or included):
last-file=file1.properties
# ----------------------------


/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/dir2/file2.properties
------------------------------------------------------------------------------------
# Property to determine if this properties file was parsed and not overwritten:
file2.properties=applied
# ----------------------------
# Property to be overwritten by every properties file (master, extra or included):
last-file=file2.properties
# ----------------------------
include=/home/fferrari/local_lab/dev/openjdk/repositories/public/java-security-includes/build/linux-x86_64-server-slowdebug/regression_a2dea487_ConfigFileTest/work/scratch/ConfigFileTest/properties/dir1/file1.properties

java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at Executor.run(ConfigFileTest.java:693)
	at ConfigFileTest.main(ConfigFileTest.java:94)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1570)
Caused by: java.lang.RuntimeException: 'last-file=file2.properties' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:242)
	at Executor.assertSuccess(ConfigFileTest.java:766)
	at ConfigFileTest.testIncludeBasic(ConfigFileTest.java:131)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 7 more

JavaTest Message: Test threw exception: java.lang.reflect.InvocationTargetException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.reflect.InvocationTargetException


test result: Failed. Execution failed: `main' threw exception: java.lang.reflect.InvocationTargetException


</details>

Reading bottom-up, we see:

* The exception that made the test fail: `RuntimeException: 'last-file=file2.properties' missing from stdout/stderr`
* A report of the `FilesManager` created files, where each file is generated with comments explaining the first two special properties meaning.
* The complete child JVM stdout and stderr, with logs from the property files processing (note how stdout prints `last-file: file1.properties` ?and stderr `properties: Initial security property: last-file=file1.properties`?, contrary to what the test was expecting)

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1809099854


From jjiang at openjdk.org  Tue Nov 14 09:06:06 2023
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 14 Nov 2023 09:06:06 GMT
Subject: RFR: 8320049: PKCS10 would not discard the cause when throw
 SignatureException on invalid key
Message-ID: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>

When throw SignatureException on invalid key, it may be better to contain the cause exception.

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

Commit messages:
 - 8320049: PKCS10 would not discard the cause when throw SignatureException on invalid key

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

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


From djelinski at openjdk.org  Tue Nov 14 09:56:38 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 Nov 2023 09:56:38 GMT
Subject: Integrated: 8318479: [jmh] the test security.CacheBench  failed for
 multiple threads run
In-Reply-To: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
References: <dPe53H3NiHLuWWRCYcWLHG3UFYWZHmnFHWDaWJb7iZo=.1d9bd3ec-cedc-41c3-a6eb-ca04657d2112@github.com>
Message-ID: <Z2p5lrTtLR0AoyVByIHnCC1pW-XDdTscLHLP4u3NvLg=.f028e6f1-5aa5-44f2-894b-670c52cb1d1d@github.com>

On Mon, 23 Oct 2023 16:23:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove the hardcoded maximum heap size.
> 
> Verified that the benchmark now passes with 100 threads given sufficient heap:
> 
> make test TEST=micro:CacheBench MICRO="OPTIONS=-t 100;JAVA_OPTIONS=-Xmx16g"

This pull request has now been integrated.

Changeset: 1535528c
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1535528cb119195b44244e8ee6bc0f913caa9270
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8318479: [jmh] the test security.CacheBench  failed for multiple threads run

Reviewed-by: redestad

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

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


From alanb at openjdk.org  Tue Nov 14 12:24:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Nov 2023 12:24:30 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
Message-ID: <DXJR3I2x9PeojuQ3QYQE-pZguDRQlCrg_eLvQaJIJwA=.a3ae7ebc-47c5-4e73-9dd6-6b07448b0832@github.com>

On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed more line breaks
>  - fixed line breaks

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 77:

> 75:  *
> 76:  * Whenever possible, {@linkplain ZipFile} should be used for parsing ZIP
> 77:  * archives since it correctly reads data from the central directory.

I think it's okay to extend the existing API note to say that the stream may contain ZIP file entries that are not are not named in the central directory.  I think I would replace the sentence "Additionally ..." with "Consequently, a ZipInputStream that reads from a ZIP file may read ZIP file entries that are not in the ZIP file's central directory". 

The sentence "This class might also fail to properly parse ZIP archives that have prepended data" will confuse readers as it hints of unreliability in scenarios and begs too many questions on where the data is prepended. So I think drop this unless you can come up with something better.

Replacing the sentence "ZipFile may be used ..." is okay but I don't think the proposed text works. The API note starts with text to say that a ZipOutputStream doesn't read the CEN so saying "correctly reads from the central directory" is very confusing. ZipInputStream is a JDK 1.1 era API, it is what it is and would be disruptive to deprecate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1392506679


From mullan at openjdk.org  Tue Nov 14 12:53:27 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 14 Nov 2023 12:53:27 GMT
Subject: RFR: 8318759: Add four DigiCert root certificates
In-Reply-To: <3dYap7SRuxGyo7B8f8kXuq_2GJ4RvfPsmEZtavYwKGk=.2ed017bb-df9e-4744-98f9-a32147bb3a55@github.com>
References: <3dYap7SRuxGyo7B8f8kXuq_2GJ4RvfPsmEZtavYwKGk=.2ed017bb-df9e-4744-98f9-a32147bb3a55@github.com>
Message-ID: <1ub-b73hx32AKKvLQ-3JuCkbd94bDzbrxQkSAt5wPNI=.e2a5415e-3a18-4bb4-895a-33776871aafa@github.com>

On Wed, 8 Nov 2023 22:41:14 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add 4 new TLS root certificates from Digicert, Inc. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8319243](https://bugs.openjdk.org/browse/JDK-8319243)

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16574#pullrequestreview-1729662145


From rhalade at openjdk.org  Tue Nov 14 17:32:43 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 14 Nov 2023 17:32:43 GMT
Subject: Integrated: 8318759: Add four DigiCert root certificates
In-Reply-To: <3dYap7SRuxGyo7B8f8kXuq_2GJ4RvfPsmEZtavYwKGk=.2ed017bb-df9e-4744-98f9-a32147bb3a55@github.com>
References: <3dYap7SRuxGyo7B8f8kXuq_2GJ4RvfPsmEZtavYwKGk=.2ed017bb-df9e-4744-98f9-a32147bb3a55@github.com>
Message-ID: <WctHbYDW1YQNN4Iq1rE0LoFmVt92m9Tg0wXho0QUMH8=.3a631080-007c-4306-8529-ca19e36cc270@github.com>

On Wed, 8 Nov 2023 22:41:14 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add 4 new TLS root certificates from Digicert, Inc. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8319243](https://bugs.openjdk.org/browse/JDK-8319243)

This pull request has now been integrated.

Changeset: 0ea58048
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ea58048f9b4cdaaa0470b2bcc03913fb3939453
Stats:     459 lines in 7 files changed: 456 ins; 0 del; 3 mod

8318759: Add four DigiCert root certificates

Reviewed-by: mullan

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

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


From rhalade at openjdk.org  Tue Nov 14 20:03:56 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 14 Nov 2023 20:03:56 GMT
Subject: RFR: 8319187: Add three eMudhra emSign roots
Message-ID: <4Mt4WHHwsnzZPdMuI6vMqwOpsqRonUwj0FxPvtzcHDk=.cf7246de-2478-4e58-9344-48931ac8219e@github.com>

This PR is to add three new TLS root certificates from eMudhra Technologies Limited. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.


The release-note is at [JDK-8320105](https://bugs.openjdk.org/browse/JDK-8320105)

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

Commit messages:
 - 8319187: Add three eMudhra emSign roots

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

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


From mbaesken at openjdk.org  Wed Nov 15 08:45:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 15 Nov 2023 08:45:35 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <OS7qTXfAW4RRmag_sHLK-4WXZeK_QsNpS8nDP0qQkwg=.a7b199f1-103e-4e85-8400-e0339c24b186@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

In the meantime,   https://bugs.openjdk.org/browse/JDK-8295159  was integrated.
There we restore on x86_64 and aarch the floating point environment  (fenv_t)  after loading libs in HS os::dll_load / dlopen_helper to avoid  'silent' manipulation of the fenv by 'bad' shared libs.
But unfortunately this does not work for  libs  not going through this coding (like the ones loaded from JDK c code).

 (And even if restoring in these additional cases is not wanted, we could at least *warn* about the change by a trace .)

Might be worth considering in context of this change .

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1812023112


From mullan at openjdk.org  Wed Nov 15 15:39:30 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Nov 2023 15:39:30 GMT
Subject: RFR: 8319187: Add three eMudhra emSign roots
In-Reply-To: <4Mt4WHHwsnzZPdMuI6vMqwOpsqRonUwj0FxPvtzcHDk=.cf7246de-2478-4e58-9344-48931ac8219e@github.com>
References: <4Mt4WHHwsnzZPdMuI6vMqwOpsqRonUwj0FxPvtzcHDk=.cf7246de-2478-4e58-9344-48931ac8219e@github.com>
Message-ID: <bK9Ma9x_HxoQn-O2tzrUpSmufVlhIArSc0CqY50mFaA=.71354e32-b55b-4a22-a72b-bc53539ce690@github.com>

On Tue, 14 Nov 2023 19:57:19 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add three new TLS root certificates from eMudhra Technologies Limited. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8320105](https://bugs.openjdk.org/browse/JDK-8320105)

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16663#pullrequestreview-1732317045


From weijun at openjdk.org  Wed Nov 15 16:10:19 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Nov 2023 16:10:19 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
Message-ID: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>

Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

Commit messages:
 - new class spec
 - more changes
 - initial change

Changes: https://git.openjdk.org/jdk/pull/16660/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16660&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4936767
  Stats: 505 lines in 11 files changed: 410 ins; 65 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/16660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16660/head:pull/16660

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


From rhalade at openjdk.org  Wed Nov 15 18:36:45 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 15 Nov 2023 18:36:45 GMT
Subject: Integrated: 8319187: Add three eMudhra emSign roots
In-Reply-To: <4Mt4WHHwsnzZPdMuI6vMqwOpsqRonUwj0FxPvtzcHDk=.cf7246de-2478-4e58-9344-48931ac8219e@github.com>
References: <4Mt4WHHwsnzZPdMuI6vMqwOpsqRonUwj0FxPvtzcHDk=.cf7246de-2478-4e58-9344-48931ac8219e@github.com>
Message-ID: <4sBwzAJHccEoiIKvUubiAyuzuLRPXRBYdZ_PDHZQeF4=.09ebd1bb-2509-4fd4-bfa2-4dc3ceaa838e@github.com>

On Tue, 14 Nov 2023 19:57:19 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add three new TLS root certificates from eMudhra Technologies Limited. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8320105](https://bugs.openjdk.org/browse/JDK-8320105)

This pull request has now been integrated.

Changeset: 0bda467f
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bda467f6e29c866c661e88a76a9fe3efc0a0d19
Stats:     305 lines in 6 files changed: 302 ins; 0 del; 3 mod

8319187: Add three eMudhra emSign roots

Reviewed-by: mullan

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

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


From mullan at openjdk.org  Wed Nov 15 18:58:30 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Nov 2023 18:58:30 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <u4P68JBJS9yCHqZZs_bw3GbGdYHU2o3lG5Con0Z22-Q=.985534eb-43b7-4fc8-8e66-4879e4aaa410@github.com>

On Tue, 14 Nov 2023 17:21:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

src/java.base/share/classes/java/security/MessageDigest.java line 436:

> 434:      *         {@code MessageDigestSpi} implementation for the
> 435:      *         specified algorithm and parameters
> 436:      *

Is there a reason why you didn't throw IAPE when params are bad?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1394650843


From duke at openjdk.org  Wed Nov 15 19:03:34 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 15 Nov 2023 19:03:34 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <JGExyTTwrGoBgz67bt2iFIzLPDv8khPmUpYFhoVgMH8=.0d300304-9cc9-4533-9b01-26cbd9667cd3@github.com>

On Tue, 14 Nov 2023 17:21:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

SHAKE is also an eXtensible Output Function, and Kyber is using it that way. In my preliminary Kyber implementation I just added a squeeze() method and initialized it with length 0  to signal that it is used as an XOF, not a digest. Have you considered this?

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

PR Comment: https://git.openjdk.org/jdk/pull/16660#issuecomment-1813093402


From prr at openjdk.org  Wed Nov 15 20:28:35 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 20:28:35 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <c7MhgTyLChABNJuYsisWJb8KBzu01TnSLwSeU0j1Ut0=.d942eefd-51eb-4854-83c6-d695d3d4dbf0@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

src/java.desktop/unix/native/common/awt/fontpath.c line 53:

> 51: /* for dlopen */
> 52: #include <macro_helper.h>
> 53: 

I have no idea why we would want to use some VM internal in the desktop module.
Please take the desktop module changes out of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15264#discussion_r1394756424


From weijun at openjdk.org  Wed Nov 15 20:49:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Nov 2023 20:49:30 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <u4P68JBJS9yCHqZZs_bw3GbGdYHU2o3lG5Con0Z22-Q=.985534eb-43b7-4fc8-8e66-4879e4aaa410@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <u4P68JBJS9yCHqZZs_bw3GbGdYHU2o3lG5Con0Z22-Q=.985534eb-43b7-4fc8-8e66-4879e4aaa410@github.com>
Message-ID: <hwEnkRyX-8ay2Ldj7TRmmdH-HlrSStPBMr3Y95Lt1Jk=.0cf01dfe-85fb-4e91-b4db-88b561026f05@github.com>

On Wed, 15 Nov 2023 18:56:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.
>
> src/java.base/share/classes/java/security/MessageDigest.java line 436:
> 
>> 434:      *         {@code MessageDigestSpi} implementation for the
>> 435:      *         specified algorithm and parameters
>> 436:      *
> 
> Is there a reason why you didn't throw IAPE when params are bad?

This is following the `SecureRandom` style where there are both `getInstance` methods that has or has not the parameters argument. If you think IAPE is better I can also throw it. `CertStore` does this way and it has a dedicated method to extract the cause of the NSAE thrown by `GetInstance.getInstance` and rethrow it. See https://github.com/openjdk/jdk/blob/9486969bd3cb084c89a7255de0c664c980d1e661/src/java.base/share/classes/java/security/cert/CertStore.java#L249

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1394778408


From weijun at openjdk.org  Wed Nov 15 20:54:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Nov 2023 20:54:30 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <__y40EiAD5MsMUZmOBWtzD9CWTJ6a9HxTvm9wtUE54U=.3af1a1a3-6788-4974-9d30-a553ab0a5cd7@github.com>

On Tue, 14 Nov 2023 17:21:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

There are multiple places where `MessageDigest` claims it has a fixed length digest output. We can discuss more on whether we can provide the XOF function inside `MessageDigest` or with a different class. This is definitely something worth doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16660#issuecomment-1813244596


From kdriver at openjdk.org  Wed Nov 15 21:42:30 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 15 Nov 2023 21:42:30 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <wr0RyfYkL96fO4dvfrY0LLmsdVkkpiENd1d3rRPCFSw=.11a21ffd-550a-4011-ad11-b8c6d828a96c@github.com>

On Tue, 14 Nov 2023 17:21:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

src/java.base/share/classes/sun/security/ec/ed/EdDSASignature.java line 31:

> 29: 
> 30: import java.io.ByteArrayOutputStream;
> 31: import java.security.*;

consider individual imports

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1394837699


From mullan at openjdk.org  Wed Nov 15 22:26:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Nov 2023 22:26:34 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <hwEnkRyX-8ay2Ldj7TRmmdH-HlrSStPBMr3Y95Lt1Jk=.0cf01dfe-85fb-4e91-b4db-88b561026f05@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <u4P68JBJS9yCHqZZs_bw3GbGdYHU2o3lG5Con0Z22-Q=.985534eb-43b7-4fc8-8e66-4879e4aaa410@github.com>
 <hwEnkRyX-8ay2Ldj7TRmmdH-HlrSStPBMr3Y95Lt1Jk=.0cf01dfe-85fb-4e91-b4db-88b561026f05@github.com>
Message-ID: <5phC1MNrDpV6QyVvsYdK9BqbM-xUt1yAjihk32rvOu4=.bc7e8a48-b98b-424e-acac-39db79863b41@github.com>

On Wed, 15 Nov 2023 20:46:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/MessageDigest.java line 436:
>> 
>>> 434:      *         {@code MessageDigestSpi} implementation for the
>>> 435:      *         specified algorithm and parameters
>>> 436:      *
>> 
>> Is there a reason why you didn't throw IAPE when params are bad?
>
> This is following the `SecureRandom` style where there are both `getInstance` methods that has or has not the parameters argument. If you think IAPE is better I can also throw it. `CertStore` does this way and it has a dedicated method to extract the cause of the NSAE thrown by `GetInstance.getInstance` and rethrow it. See https://github.com/openjdk/jdk/blob/9486969bd3cb084c89a7255de0c664c980d1e661/src/java.base/share/classes/java/security/cert/CertStore.java#L249

Hmm, interesting. I have a slight preference for the `CertStore` approach because it feels like the caller can more easily distinguish between the two cases but I could probably live with either. What do you prefer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1394903586


From jwaters at openjdk.org  Thu Nov 16 04:28:49 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Nov 2023 04:28:49 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
Message-ID: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>

I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, 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

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

Commit messages:
 - Actually resolve issues with goto labels in sspi

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

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


From jwaters at openjdk.org  Thu Nov 16 04:33:49 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Nov 2023 04:33:49 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v2]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <riFJRkfryzbt-_7gC77-u0C4wXh-Mrax5-9QKLmW_Tk=.af62edf9-144d-438e-9857-cd3f0761229d@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, 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

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

  Missed labels in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/8f336b00..acf96711

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

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

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


From jwaters at openjdk.org  Thu Nov 16 04:40:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Nov 2023 04:40:53 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, 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

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

  NULL to nullptr in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/acf96711..1e33e810

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

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

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


From weijun at openjdk.org  Thu Nov 16 13:47:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 13:47:56 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
Message-ID: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>

Code changes for HSS/LMS that's related to keytool and jarsigner:

1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

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

Commit messages:
 - test change
 - always DSA for new algorithms
 - the fix

Changes: https://git.openjdk.org/jdk/pull/14254/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14254&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302233
  Stats: 199 lines in 8 files changed: 83 ins; 85 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/14254.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14254/head:pull/14254

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


From weijun at openjdk.org  Thu Nov 16 13:47:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 13:47:57 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <Bw3_WtSqegxYl8iGHFWGRsw2R4XgGxZP_lYFWcp8jsk=.e7c28fc4-ac79-4bb6-84d1-e27d3fac4f35@github.com>

On Wed, 31 May 2023 22:38:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

Still alive.

please

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

PR Comment: https://git.openjdk.org/jdk/pull/14254#issuecomment-1710488569
PR Comment: https://git.openjdk.org/jdk/pull/14254#issuecomment-1791561991


From weijun at openjdk.org  Thu Nov 16 14:37:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 14:37:55 GMT
Subject: RFR: 8319124: Update XML Security for Java to 3.0.3
Message-ID: <4m8cqWXNw6z4x03UftD6RK0JWt9NrnBH9XOfHPbeGx4=.cc8699b3-b758-41a0-8b6e-273a36557fbf@github.com>

Update XMLDsig implementation to match Apache Santuario 3.0.3.

Changes include (significance in descending order):

- `SignatureMethod.java`: new signature method URIs defined
- `SignatureBaseRSA.java`: `SignatureBaseRSAPSS` and refactoring
- `JCEMapper.java`: use of `ThreadLocal`
- `DigestorOutputStream.java`: one synchronized method
- `XMLUtils.java`: renames, one new method not used anywhere, some log change
- `Init.java`: some refactoring
- `DOMSignatureMethod.java`: new MGF1 methods, some refactoring
- `DOMXMLSignatureFactory.java`: new signature methods
- `santuario.md`, `XMLDSigRI.java`: bump to 3.0.3
- `DOMXMLSignature.java`: some finals
- `NameSpaceSymbTable.java`: renames
- Base64.java: no longer final
- Others: reorder imports, add `@Override`, foreach, diamond operators

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

Commit messages:
 - initial change

Changes: https://git.openjdk.org/jdk/pull/16691/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319124
  Stats: 1568 lines in 130 files changed: 1150 ins; 231 del; 187 mod
  Patch: https://git.openjdk.org/jdk/pull/16691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16691/head:pull/16691

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


From weijun at openjdk.org  Thu Nov 16 14:55:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 14:55:51 GMT
Subject: RFR: 8320208: Update Public Suffix List to b5bf572
Message-ID: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>

Update `public_suffix_list.dat` to the latest.

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

Commit messages:
 - initial change

Changes: https://git.openjdk.org/jdk/pull/16692/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16692&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320208
  Stats: 3002 lines in 4 files changed: 1753 ins; 73 del; 1176 mod
  Patch: https://git.openjdk.org/jdk/pull/16692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16692/head:pull/16692

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


From mullan at openjdk.org  Thu Nov 16 15:20:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Nov 2023 15:20:34 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <yZch_cWmuDn6JohQCz4NboFD_XzTXRO5thJmEB19R4U=.d427336e-49cb-40ca-bc4d-f2cf8b11a469@github.com>

On Wed, 31 May 2023 22:38:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

src/java.base/share/classes/sun/security/util/KeyUtil.java line 411:

> 409:      * @throws NoSuchAlgorithmException if key is from an unknown configuration
> 410:      */
> 411:     public static String hashAlgFromHSS(PublicKey publicKey)

@ferakocz can you review this method? Thanks.

test/lib/jdk/test/lib/security/timestamp/TsaSigner.java line 1:

> 1: /*

Update copyright.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1395886589
PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1395813555


From mullan at openjdk.org  Thu Nov 16 15:49:37 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Nov 2023 15:49:37 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>

On Wed, 31 May 2023 22:38:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 872:

> 870:      */
> 871:     @Deprecated(since="16", forRemoval=true)
> 872:     public static byte[] generateSignedData(byte[] signature,

Are you sure you want to remove this as part of this change? If there was a reason this was deprecated for removal (perhaps some apps did use it even though they should not), then before removing it it probably makes sense to include it in a CSR, and maybe the RN too.

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 488:

> 486:      *                   directly. This makes difference for Ed448.
> 487:      */
> 488:     public static void algorithmsConformanceCheck(

Can this be private?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1395919143
PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1395933577


From mpowers at openjdk.org  Thu Nov 16 16:19:33 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 16 Nov 2023 16:19:33 GMT
Subject: RFR: 8320208: Update Public Suffix List to b5bf572
In-Reply-To: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>
References: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>
Message-ID: <3jOS26shUJqtKaMIj0JqvAsdANQ1nY6IqnuvMHAU8E0=.6548d0da-0232-4deb-ba2f-65ac76fad20c@github.com>

On Thu, 16 Nov 2023 14:50:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update `public_suffix_list.dat` to the latest.

Looks good to me. I never knew this existed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16692#issuecomment-1814778083


From weijun at openjdk.org  Thu Nov 16 16:19:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 16:19:35 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>
Message-ID: <uDcxqhuP4Z5BKRrFLGuBDOETiHqv5a_Sh6EZfxmrFMA=.b507aa69-fc19-4f46-ab56-fc14d77c5d2f@github.com>

On Thu, 16 Nov 2023 15:45:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Code changes for HSS/LMS that's related to keytool and jarsigner:
>> 
>> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
>> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
>> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file
>
> src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 488:
> 
>> 486:      *                   directly. This makes difference for Ed448.
>> 487:      */
>> 488:     public static void algorithmsConformanceCheck(
> 
> Can this be private?

Sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1395986419


From weijun at openjdk.org  Thu Nov 16 16:28:37 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 16:28:37 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>
Message-ID: <NV6s__I_ri8bCFo1JNrK6Mzg1reeKA48obpxIT_YTV0=.e192a25a-2916-4a5b-9ce2-e5e65d4721fb@github.com>

On Thu, 16 Nov 2023 15:36:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Code changes for HSS/LMS that's related to keytool and jarsigner:
>> 
>> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
>> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
>> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file
>
> src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 872:
> 
>> 870:      */
>> 871:     @Deprecated(since="16", forRemoval=true)
>> 872:     public static byte[] generateSignedData(byte[] signature,
> 
> Are you sure you want to remove this as part of this change? If there was a reason this was deprecated for removal (perhaps some apps did use it even though they should not), then before removing it it probably makes sense to include it in a CSR, and maybe the RN too.

This internal method was called by `TimestampedSigner` which was removed long ago when we removed the support for `ContentSigner` and `jarsigner -altsign`. It has been useless for some time and this is just a cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1395997766


From mullan at openjdk.org  Thu Nov 16 16:36:38 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Nov 2023 16:36:38 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <NV6s__I_ri8bCFo1JNrK6Mzg1reeKA48obpxIT_YTV0=.e192a25a-2916-4a5b-9ce2-e5e65d4721fb@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>
 <NV6s__I_ri8bCFo1JNrK6Mzg1reeKA48obpxIT_YTV0=.e192a25a-2916-4a5b-9ce2-e5e65d4721fb@github.com>
Message-ID: <fEAGM7l5hVFCN3BdDRMMZ0LlLVfBlCrfuxiiWQ7kgMg=.deb5830d-b75f-4dcc-81db-8325457f7ec9@github.com>

On Thu, 16 Nov 2023 16:25:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 872:
>> 
>>> 870:      */
>>> 871:     @Deprecated(since="16", forRemoval=true)
>>> 872:     public static byte[] generateSignedData(byte[] signature,
>> 
>> Are you sure you want to remove this as part of this change? If there was a reason this was deprecated for removal (perhaps some apps did use it even though they should not), then before removing it it probably makes sense to include it in a CSR, and maybe the RN too.
>
> This internal method was called by `TimestampedSigner` which was removed long ago when we removed the support for `ContentSigner` and `jarsigner -altsign`. It has been useless for some time and this is just a cleanup.

Ok, I see. It probably should have been removed as part of https://bugs.openjdk.org/browse/JDK-8303410. So I'm ok with the cleanup.

It probably makes sense to rename `newGenerateSignedData` to `generateSignedData` (since there is only one method now).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1396009553


From weijun at openjdk.org  Thu Nov 16 16:45:03 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 16:45:03 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v2]
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <u8peB7uAaMGyy-oaO7XwIUPHfuLIhm-xcU7S6TvmeNk=.8104bf1f-1cef-4eb1-b078-3f891f81f328@github.com>

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

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

 - small change on copyright year and method modifier
 - Merge branch 'master' into 8302233
 - test change
 - always DSA for new algorithms
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14254/files
  - new: https://git.openjdk.org/jdk/pull/14254/files/2864f5f5..e3b1a7c1

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

  Stats: 1086491 lines in 9725 files changed: 320140 ins; 622324 del; 144027 mod
  Patch: https://git.openjdk.org/jdk/pull/14254.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14254/head:pull/14254

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


From weijun at openjdk.org  Thu Nov 16 17:07:07 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 17:07:07 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v3]
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <io-gndu_tK3dOj3SkXDg_2wjMLCw3Bqa8B1N2kpOIx8=.58630cb8-fd42-43ae-82f2-8278c8406222@github.com>

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

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

  no need to say new

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14254/files
  - new: https://git.openjdk.org/jdk/pull/14254/files/e3b1a7c1..ff150140

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

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

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


From weijun at openjdk.org  Thu Nov 16 17:10:44 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 17:10:44 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v3]
In-Reply-To: <fEAGM7l5hVFCN3BdDRMMZ0LlLVfBlCrfuxiiWQ7kgMg=.deb5830d-b75f-4dcc-81db-8325457f7ec9@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <tz7B6xAn-KQALQ8xbVkyClavhBAI-MS9M8pxVZiEZXg=.dbd8201f-69e0-49c1-a9fd-767e9b86a07f@github.com>
 <NV6s__I_ri8bCFo1JNrK6Mzg1reeKA48obpxIT_YTV0=.e192a25a-2916-4a5b-9ce2-e5e65d4721fb@github.com>
 <fEAGM7l5hVFCN3BdDRMMZ0LlLVfBlCrfuxiiWQ7kgMg=.deb5830d-b75f-4dcc-81db-8325457f7ec9@github.com>
Message-ID: <21khNjj43x_Vl7QXZ-ZM_bi1YRk-am22QYlb_qJWm8E=.12e53866-9f90-409d-89e1-610ed0f03ded@github.com>

On Thu, 16 Nov 2023 16:33:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This internal method was called by `TimestampedSigner` which was removed long ago when we removed the support for `ContentSigner` and `jarsigner -altsign`. It has been useless for some time and this is just a cleanup.
>
> Ok, I see. It probably should have been removed as part of https://bugs.openjdk.org/browse/JDK-8303410. So I'm ok with the cleanup.
> 
> It probably makes sense to rename `newGenerateSignedData` to `generateSignedData` (since there is only one method now).

Good. I've done it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1396064310


From duke at openjdk.org  Thu Nov 16 18:22:46 2023
From: duke at openjdk.org (Ben Perez)
Date: Thu, 16 Nov 2023 18:22:46 GMT
Subject: RFR: 8317538: RSA have scalability issue for high vCPU numbers
 [v3]
In-Reply-To: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
References: <XHF5yoopw-BVe-4qsawzb90NxAhp6A39rk2L7U8mXsM=.85c1c32f-bff6-4925-bb69-d5099963ef2b@github.com>
Message-ID: <3wNMvFD2Obqy1QYNGZfXQxwFs3M_shgxh5RiPdLWat4=.ddf41d91-bb84-4d91-b844-ea1142ae6a28@github.com>

> Modified `getService` method to prevent caching of `ServiceKey`, which was negatively impacting multithreaded performance

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

  changed cache to use threadlocal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16403/files
  - new: https://git.openjdk.org/jdk/pull/16403/files/c33e1cd9..7ddc66eb

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

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

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


From mullan at openjdk.org  Thu Nov 16 18:28:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Nov 2023 18:28:34 GMT
Subject: RFR: 8319124: Update XML Security for Java to 3.0.3
In-Reply-To: <4m8cqWXNw6z4x03UftD6RK0JWt9NrnBH9XOfHPbeGx4=.cc8699b3-b758-41a0-8b6e-273a36557fbf@github.com>
References: <4m8cqWXNw6z4x03UftD6RK0JWt9NrnBH9XOfHPbeGx4=.cc8699b3-b758-41a0-8b6e-273a36557fbf@github.com>
Message-ID: <bx0bhMiaVs7Lce2WhKALwyT7xqPK70NVkW8L-ydZopo=.1104e809-76ee-4b0a-ab26-c429731d8efa@github.com>

On Thu, 16 Nov 2023 14:30:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update XMLDsig implementation to match Apache Santuario 3.0.3.
> 
> Changes include (significance in descending order):
> 
> - `SignatureMethod.java`: new signature method URIs defined
> - `SignatureBaseRSA.java`: `SignatureBaseRSAPSS` and refactoring
> - `JCEMapper.java`: use of `ThreadLocal`
> - `DigestorOutputStream.java`: one synchronized method
> - `XMLUtils.java`: renames, one new method not used anywhere, some log change
> - `Init.java`: some refactoring
> - `DOMSignatureMethod.java`: new MGF1 methods, some refactoring
> - `DOMXMLSignatureFactory.java`: new signature methods
> - `santuario.md`, `XMLDSigRI.java`: bump to 3.0.3
> - `DOMXMLSignature.java`: some finals
> - `NameSpaceSymbTable.java`: renames
> - Base64.java: no longer final
> - Others: reorder imports, add `@Override`, foreach, diamond operators

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16691#pullrequestreview-1735158199


From weijun at openjdk.org  Thu Nov 16 20:51:46 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 20:51:46 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137
Message-ID: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>

When blocksize is less than digest output length, call `keccak` more.

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

Commit messages:
 - initial change

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

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


From mpowers at openjdk.org  Thu Nov 16 22:46:36 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 16 Nov 2023 22:46:36 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137
In-Reply-To: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
Message-ID: <_RlJw9DnvyZZvv5Q7ECf6Myn0jSTQkQpAgtoOVRI1sc=.d1d18787-8044-4104-92e1-126e32b4f1a5@github.com>

On Thu, 16 Nov 2023 20:45:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> When blocksize is less than digest output length, call `keccak` more.

Looks good. I only found trivial things. A comment describing `squeezeOffset` would help.

src/java.base/share/classes/sun/security/provider/DigestBase.java line 144:

> 142:     }
> 143: 
> 144:         // compress complete blocks

Indentation problem.

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

> 100:     }
> 101: 
> 102:      void finishAbsorb() {

One extra space of indentation.

src/java.base/share/classes/sun/security/provider/SHAKE128.java line 39:

> 37:     // if this constructor is used to get an instance of the class, then, after the last update,
> 38:     // one can get the generated bytes using the squeezing methods
> 39:     // calling digest method will throw a ProviderException

These should be complete sentences capital letters and periods.

src/java.base/share/classes/sun/security/provider/SHAKE256.java line 32:

> 30: public final class SHAKE256 extends SHA3 {
> 31:     // d is the required number of output bytes
> 32:     // if this constructor is used with d > 0, the squeezing methods will throw a ProviderException

These should be complete sentences capital letters and periods.

src/java.base/share/classes/sun/security/provider/SHAKE256.java line 39:

> 37:     // if this constructor is used to get an instance of the class, then, after the last update,
> 38:     // one can get the generated bytes using the squeezing methods
> 39:     // calling a digest method will throw a ProviderException

These should be complete sentences capital letters and periods.

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

Marked as reviewed by mpowers (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16698#pullrequestreview-1735586966
PR Review Comment: https://git.openjdk.org/jdk/pull/16698#discussion_r1396448860
PR Review Comment: https://git.openjdk.org/jdk/pull/16698#discussion_r1396384245
PR Review Comment: https://git.openjdk.org/jdk/pull/16698#discussion_r1396421367
PR Review Comment: https://git.openjdk.org/jdk/pull/16698#discussion_r1396420740
PR Review Comment: https://git.openjdk.org/jdk/pull/16698#discussion_r1396387588


From anthony.scarpino at oracle.com  Thu Nov 16 22:47:27 2023
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 16 Nov 2023 14:47:27 -0800
Subject: JEP draft: PEM API (Preview)
Message-ID: <9567b12b-aef4-4ce0-a056-f0a287a657af@oracle.com>

Hi all,

We are proposing to add an API for PEM and a foundation for other crypto 
encoding.

The draft JEP is located at: https://openjdk.org/jeps/8300911

Feel free to comment here.

Thanks

Tony


From weijun at openjdk.org  Thu Nov 16 23:59:47 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Nov 2023 23:59:47 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v2]
In-Reply-To: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
Message-ID: <gjeTiej08vIBj5QjFQ0OugolLtrFCFFa-4SixKO2imI=.c369b2f9-18c7-493f-8b81-471a7f81624e@github.com>

> When blocksize is less than digest output length, call `keccak` more.

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

  fix wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16698/files
  - new: https://git.openjdk.org/jdk/pull/16698/files/26a6f118..1a27c6a6

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

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

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


From weijun at openjdk.org  Fri Nov 17 00:05:59 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 00:05:59 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v3]
In-Reply-To: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
Message-ID: <lrbEwPWjq9y9x3SzI-FTAamxZ2f9zg0VNcmrxynOSC0=.eb5e021c-9f2d-49c3-90fd-16b660526f2d@github.com>

> When blocksize is less than digest output length, call `keccak` more.

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

  add comment for squeezeOffset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16698/files
  - new: https://git.openjdk.org/jdk/pull/16698/files/1a27c6a6..4133fdc1

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

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

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


From ecki at zusammenkunft.net  Fri Nov 17 01:36:50 2023
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 17 Nov 2023 02:36:50 +0100 (CET)
Subject: JEP draft: PEM API (Preview)
In-Reply-To: <20231117022046.3C8BE660C0D@dd33810.kasserver.com>
References: <9567b12b-aef4-4ce0-a056-f0a287a657af@oracle.com><20231117022046.3C8BE660C0D@dd33810.kasserver.com>
Message-ID: <20231117013650.9D186660DD9@dd33810.kasserver.com>

Anthony Scarpino wrote on 16. Nov 2023 23:47 (GMT +01:00):
> Hi all,
> 
> We are proposing to add an API for PEM and a foundation for other crypto 
> encoding.

I like the modularity and that you do not try to squeeze it into the existing services.

I wonder if you should also allow to set comment or generally text headers when encoding and for decoding if you need access to the comment.

There are some variants like ?BEGIN PUBLiC SSH KEY? maybe the JEP should list the ones which are accepted. 

Does the encoder need to make the line configurable?

Should initial version already support PQC keys?

Gru?
Bernd
? 
https://bernd.eckenfels.net


From duke at openjdk.org  Fri Nov 17 05:30:44 2023
From: duke at openjdk.org (duke)
Date: Fri, 17 Nov 2023 05:30:44 GMT
Subject: Withdrawn: 8311532: Option to disable Krb5LoginModule::login method
In-Reply-To: <wpB5Hen8yxk3qZTagqFsFQjORcsqS4NUKx_6G1fm9S8=.a9f5e62a-056b-4524-bbf8-f78eccdb789e@github.com>
References: <wpB5Hen8yxk3qZTagqFsFQjORcsqS4NUKx_6G1fm9S8=.a9f5e62a-056b-4524-bbf8-f78eccdb789e@github.com>
Message-ID: <owUSDSMKr32VRUgoLMkfz3eW5WFvbI7W7837VIy9BlE=.147a4b59-5dd4-459d-93c9-311ec885583a@github.com>

On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS.
> 
> This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior

This pull request has been closed without being integrated.

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

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


From jwaters at openjdk.org  Fri Nov 17 09:24:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 09:24:30 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
Message-ID: <13ylNh_nZpezRClCzyQ3KW5kputZMoNlrCUD_6fBiYE=.13b01001-9186-4271-8d3e-7ad4669a0d03@github.com>

On Thu, 16 Nov 2023 04:40:53 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, 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NULL to nullptr in sspi.cpp

Anyone?

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816015761


From stuefe at openjdk.org  Fri Nov 17 13:52:29 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Nov 2023 13:52:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
Message-ID: <o51wnd0kSBPJIaDzLnbNMQtdFQ2hsR0KkKR1m7G85Gs=.8961d3a8-e7eb-453d-8061-6a526a5856d9@github.com>

On Thu, 16 Nov 2023 04:40:53 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, 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NULL to nullptr in sspi.cpp

Can you please describe the problem you are trying to solve, and why you think it is worth solving. You describe the thought process you went through while doing the patch and possibly some other, older patch. As it is, reading the PR text or the issue description is confusing and requires reviewers to dig through comment threads on older issues to parse it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816466351


From jwaters at openjdk.org  Fri Nov 17 14:06:32 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 14:06:32 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <o51wnd0kSBPJIaDzLnbNMQtdFQ2hsR0KkKR1m7G85Gs=.8961d3a8-e7eb-453d-8061-6a526a5856d9@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
 <o51wnd0kSBPJIaDzLnbNMQtdFQ2hsR0KkKR1m7G85Gs=.8961d3a8-e7eb-453d-8061-6a526a5856d9@github.com>
Message-ID: <rsaAUuhWgUQK6RfmbXlhs39aZ388tktNerolhcejZHc=.6b9f7a17-f0d1-4623-a428-580891abc8de@github.com>

On Fri, 17 Nov 2023 13:49:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Can you please describe the problem you are trying to solve, and why you think it is worth solving. You describe the thought process you went through while doing the patch and possibly some other, older patch. As it is, reading the PR text or the issue description is confusing and requires reviewers to dig through comment threads on older issues to parse it.

I've changed to description for both to (hopefully) be more descriptive and clear. Sorry for the hassle, I'm not particularly good with words

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816488476


From stuefe at openjdk.org  Fri Nov 17 14:16:31 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Nov 2023 14:16:31 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <rsaAUuhWgUQK6RfmbXlhs39aZ388tktNerolhcejZHc=.6b9f7a17-f0d1-4623-a428-580891abc8de@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
 <o51wnd0kSBPJIaDzLnbNMQtdFQ2hsR0KkKR1m7G85Gs=.8961d3a8-e7eb-453d-8061-6a526a5856d9@github.com>
 <rsaAUuhWgUQK6RfmbXlhs39aZ388tktNerolhcejZHc=.6b9f7a17-f0d1-4623-a428-580891abc8de@github.com>
Message-ID: <ItnLJ2ocVWkCPVGzrJw4fBWtRWBHUbAueV6TbNQs2pg=.cdfb0172-ccc5-4313-8dc8-bf9ed98281e9@github.com>

On Fri, 17 Nov 2023 14:04:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > Can you please describe the problem you are trying to solve, and why you think it is worth solving. You describe the thought process you went through while doing the patch and possibly some other, older patch. As it is, reading the PR text or the issue description is confusing and requires reviewers to dig through comment threads on older issues to parse it.
> 
> I've changed to description for both to (hopefully) be more descriptive and clear. Sorry for the hassle, I'm not particularly good with words

Somewhat better, but not by much, sorry :-)

This patch is work to review, since it touches security-relevant stuff and because mentally verifying that all the code paths you change are equivalent to what happened before is real work. It is probably more work than doing the patch.

Hence my question, what is the motivation, is there a bug that needs fixing? Or is it just that you dislike these gotos? Is it just to get Windows to build with GCC? Sorry, I did not follow your work, so I don't have a context.

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816504304


From jwaters at openjdk.org  Fri Nov 17 14:36:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 14:36:33 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <ItnLJ2ocVWkCPVGzrJw4fBWtRWBHUbAueV6TbNQs2pg=.cdfb0172-ccc5-4313-8dc8-bf9ed98281e9@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
 <o51wnd0kSBPJIaDzLnbNMQtdFQ2hsR0KkKR1m7G85Gs=.8961d3a8-e7eb-453d-8061-6a526a5856d9@github.com>
 <rsaAUuhWgUQK6RfmbXlhs39aZ388tktNerolhcejZHc=.6b9f7a17-f0d1-4623-a428-580891abc8de@github.com>
 <ItnLJ2ocVWkCPVGzrJw4fBWtRWBHUbAueV6TbNQs2pg=.cdfb0172-ccc5-4313-8dc8-bf9ed98281e9@github.com>
Message-ID: <ldEWabpXWU9eKJSmzOFoYEGBQsgJe4b9XlkRiNJYtDY=.288abfc9-a95a-498f-8793-7154d537dd38@github.com>

On Fri, 17 Nov 2023 14:13:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > Can you please describe the problem you are trying to solve, and why you think it is worth solving. You describe the thought process you went through while doing the patch and possibly some other, older patch. As it is, reading the PR text or the issue description is confusing and requires reviewers to dig through comment threads on older issues to parse it.
> > 
> > 
> > I've changed to description for both to (hopefully) be more descriptive and clear. Sorry for the hassle, I'm not particularly good with words
> 
> Somewhat better, but not by much, sorry :-)
> 
> This patch is work to review, since it touches security-relevant stuff and because mentally verifying that all the code paths you change are equivalent to what happened before is real work. It is probably more work than doing the patch.
> 
> Hence my question, what is the motivation, is there a bug that needs fixing? Or is it just that you dislike these gotos? Is it just to get Windows to build with GCC? Sorry, I did not follow your work, so I don't have a context.

This is a cleanup patch that follows the older one that enabled security to compile with permissive-, the problem with that one is that simply changing the locals to a split declaration and assignment is a bit of an ugly hack, since the locals then have undefined values when allocated. gcc already compiles fine with the old patch, this new one is not needed for either compiler (MSVC or gcc) to compile without errors. I felt like I had the responsibility to clean up what is essentially a hack just to get it to compile with permissive- on MSVC. This is also partially inspired by Phil's rejection of the old patch in https://github.com/openjdk/jdk/pull/15096 :/

I don't have anything against gotos, nor do I dislike them :)

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816538037


From weijun at openjdk.org  Fri Nov 17 15:05:32 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 15:05:32 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <5phC1MNrDpV6QyVvsYdK9BqbM-xUt1yAjihk32rvOu4=.bc7e8a48-b98b-424e-acac-39db79863b41@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <u4P68JBJS9yCHqZZs_bw3GbGdYHU2o3lG5Con0Z22-Q=.985534eb-43b7-4fc8-8e66-4879e4aaa410@github.com>
 <hwEnkRyX-8ay2Ldj7TRmmdH-HlrSStPBMr3Y95Lt1Jk=.0cf01dfe-85fb-4e91-b4db-88b561026f05@github.com>
 <5phC1MNrDpV6QyVvsYdK9BqbM-xUt1yAjihk32rvOu4=.bc7e8a48-b98b-424e-acac-39db79863b41@github.com>
Message-ID: <uG63oHKEgWZzE9gM6pExK8wyHjhLCBKpZ8U87qsjtV8=.64de2fd1-edc3-4284-9a45-ea66ff8a13eb@github.com>

On Wed, 15 Nov 2023 22:24:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is following the `SecureRandom` style where there are both `getInstance` methods that has or has not the parameters argument. If you think IAPE is better I can also throw it. `CertStore` does this way and it has a dedicated method to extract the cause of the NSAE thrown by `GetInstance.getInstance` and rethrow it. See https://github.com/openjdk/jdk/blob/9486969bd3cb084c89a7255de0c664c980d1e661/src/java.base/share/classes/java/security/cert/CertStore.java#L249
>
> Hmm, interesting. I have a slight preference for the `CertStore` approach because it feels like the caller can more easily distinguish between the two cases but I could probably live with either. What do you prefer?

OK, I'll switch to the `CertStore` style.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1397448813


From weijun at openjdk.org  Fri Nov 17 15:05:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 15:05:34 GMT
Subject: RFR: 4936767: Parameters for MessageDigest
In-Reply-To: <wr0RyfYkL96fO4dvfrY0LLmsdVkkpiENd1d3rRPCFSw=.11a21ffd-550a-4011-ad11-b8c6d828a96c@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <wr0RyfYkL96fO4dvfrY0LLmsdVkkpiENd1d3rRPCFSw=.11a21ffd-550a-4011-ad11-b8c6d828a96c@github.com>
Message-ID: <_fyYvfVv0oQqdolNw4L5M1LQFUfx7UzRF2vRfRqToYI=.b85d56d0-0246-45e6-8cd5-566cf4907f81@github.com>

On Wed, 15 Nov 2023 21:40:10 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.
>
> src/java.base/share/classes/sun/security/ec/ed/EdDSASignature.java line 31:
> 
>> 29: 
>> 30: import java.io.ByteArrayOutputStream;
>> 31: import java.security.*;
> 
> consider individual imports

OK. I'll tell IDEA to never combine them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1397449320


From weijun at openjdk.org  Fri Nov 17 15:28:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 15:28:53 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v2]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <Wx_mQfvtZyhiR4xDKSJnBklLk7GzSxzgzS1vNvcJego=.cb6abaa4-3a45-4776-bd40-95686b8f6058@github.com>

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

  throw iape

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/755d5d01..d01bf939

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

  Stats: 68 lines in 4 files changed: 44 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16660/head:pull/16660

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


From stuefe at openjdk.org  Fri Nov 17 15:47:29 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Nov 2023 15:47:29 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
Message-ID: <sJ6IgtFKt6bsYEGNcstwzoknGUAmDCeUPmoyCfoayZY=.515a26e8-2050-4082-8659-f562c8565043@github.com>

On Thu, 16 Nov 2023 04:40:53 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NULL to nullptr in sspi.cpp

> > > > Can you please describe the problem you are trying to solve, and why you think it is worth solving. You describe the thought process you went through while doing the patch and possibly some other, older patch. As it is, reading the PR text or the issue description is confusing and requires reviewers to dig through comment threads on older issues to parse it.
> > > 
> > > 
> > > I've changed to description for both to (hopefully) be more descriptive and clear. Sorry for the hassle, I'm not particularly good with words
> > 
> > 
> > Somewhat better, but not by much, sorry :-)
> > This patch is work to review, since it touches security-relevant stuff and because mentally verifying that all the code paths you change are equivalent to what happened before is real work. It is probably more work than doing the patch.
> > Hence my question, what is the motivation, is there a bug that needs fixing? Or is it just that you dislike these gotos? Is it just to get Windows to build with GCC? Sorry, I did not follow your work, so I don't have a context.
> 
> This is a cleanup patch that follows the older one that enabled security to compile with permissive-, the problem with that one is that simply changing the locals to a split declaration and assignment is a bit of an ugly hack, since the locals then have undefined values when allocated. gcc already compiles fine with the old patch, this new one is not needed for either compiler (MSVC or gcc) to compile without errors. I felt like I had the responsibility to clean up what is essentially a hack just to get it to compile with permissive- on MSVC. This is also partially inspired by Phil's rejection of the old patch in #15096 :/
> 
> I don't have anything against gotos, nor do I dislike them :)

Thank you for your explanation! I'll relegate to Phil for the actual review then; I was just curious about the patch since it touched security-related code.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816661606


From weijun at openjdk.org  Fri Nov 17 15:49:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 15:49:56 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v3]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <CAbwxT2iLKRNPzRS3KcWMl8f1If63tnsgkKmSQqbIfA=.a418464a-c936-4418-b2aa-389a987c595e@github.com>

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

  cite resources

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/d01bf939..1ae8ac97

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

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

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


From weijun at openjdk.org  Fri Nov 17 15:49:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 15:49:56 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v2]
In-Reply-To: <Wx_mQfvtZyhiR4xDKSJnBklLk7GzSxzgzS1vNvcJego=.cb6abaa4-3a45-4776-bd40-95686b8f6058@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <Wx_mQfvtZyhiR4xDKSJnBklLk7GzSxzgzS1vNvcJego=.cb6abaa4-3a45-4776-bd40-95686b8f6058@github.com>
Message-ID: <l2gGK5iF3on1fGwQ2lvBY9JdFXnPXqbRllcprc-MxbA=.bf69d00c-5e0f-49e5-bd94-46b6f3e2f79d@github.com>

On Fri, 17 Nov 2023 15:28:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   throw iape

New commits pushed. IAPE is thrown by `getInstance` if the parameters passed in is not accepted.

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

PR Comment: https://git.openjdk.org/jdk/pull/16660#issuecomment-1816664234


From jwaters at openjdk.org  Fri Nov 17 16:04:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 16:04:33 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <sJ6IgtFKt6bsYEGNcstwzoknGUAmDCeUPmoyCfoayZY=.515a26e8-2050-4082-8659-f562c8565043@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
 <sJ6IgtFKt6bsYEGNcstwzoknGUAmDCeUPmoyCfoayZY=.515a26e8-2050-4082-8659-f562c8565043@github.com>
Message-ID: <cl-JZWLJPMsYX4ibQIj5WrEf8hE0WgQjsSl291ftO3E=.99983d62-869a-487c-856b-f6430b4d0829@github.com>

On Fri, 17 Nov 2023 15:44:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > > Can you please describe the problem you are trying to solve, and why you think it is worth solving. You describe the thought process you went through while doing the patch and possibly some other, older patch. As it is, reading the PR text or the issue description is confusing and requires reviewers to dig through comment threads on older issues to parse it.
> > > > 
> > > > 
> > > > I've changed to description for both to (hopefully) be more descriptive and clear. Sorry for the hassle, I'm not particularly good with words
> > > 
> > > 
> > > Somewhat better, but not by much, sorry :-)
> > > This patch is work to review, since it touches security-relevant stuff and because mentally verifying that all the code paths you change are equivalent to what happened before is real work. It is probably more work than doing the patch.
> > > Hence my question, what is the motivation, is there a bug that needs fixing? Or is it just that you dislike these gotos? Is it just to get Windows to build with GCC? Sorry, I did not follow your work, so I don't have a context.
> > 
> > 
> > This is a cleanup patch that follows the older one that enabled security to compile with permissive-, the problem with that one is that simply changing the locals to a split declaration and assignment is a bit of an ugly hack, since the locals then have undefined values when allocated. gcc already compiles fine with the old patch, this new one is not needed for either compiler (MSVC or gcc) to compile without errors. I felt like I had the responsibility to clean up what is essentially a hack just to get it to compile with permissive- on MSVC. This is also partially inspired by Phil's rejection of the old patch in #15096 :/
> > I don't have anything against gotos, nor do I dislike them :)
> 
> Thank you for your explanation! I'll relegate to Phil for the actual review then; I was just curious about the patch since it touched security-related code.
> 
> Cheers, Thomas

I don't believe Phil does security reviews, that would be up to WeiJun and Valerie :P

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1816687562


From mullan at openjdk.org  Fri Nov 17 17:20:30 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 17 Nov 2023 17:20:30 GMT
Subject: RFR: 8320208: Update Public Suffix List to b5bf572
In-Reply-To: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>
References: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>
Message-ID: <N9CaKYM8O8QVwD2n38bxL88NaKx0B__AkeAO5Rbt6tk=.ab4e85ef-9490-4dbd-8156-6bad92f317d8@github.com>

On Thu, 16 Nov 2023 14:50:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update `public_suffix_list.dat` to the latest.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16692#pullrequestreview-1737519720


From kdriver at openjdk.org  Fri Nov 17 17:31:32 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 17 Nov 2023 17:31:32 GMT
Subject: RFR: JDK-8318105 [jmh] the test java.security.HSS failed with 2
 active threads
In-Reply-To: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>
References: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>
Message-ID: <ncLPZopu2PEdMRrM3e-ypb2OeXD4YGpJt4qyWpZBPLM=.2d3918ce-ea81-4ef0-9a4c-2a0d15fe0626@github.com>

On Tue, 31 Oct 2023 18:16:11 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

test/micro/org/openjdk/bench/java/security/HSS.java line 83:

> 81:     @Setup
> 82:     public void setup() throws Exception {
> 83:         p = Security.getProvider("SUN");

I assume this was just a "sanity check" to see whether it's an Oracle/Sun JDK? In which case, I understand removing it. However, if it has to do with the threading model and some kind of locking of the provider, you might want to add some more to your description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16435#discussion_r1397653017


From mpowers at openjdk.org  Fri Nov 17 17:39:32 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 17 Nov 2023 17:39:32 GMT
Subject: RFR: JDK-8318105 [jmh] the test java.security.HSS failed with 2
 active threads
In-Reply-To: <ncLPZopu2PEdMRrM3e-ypb2OeXD4YGpJt4qyWpZBPLM=.2d3918ce-ea81-4ef0-9a4c-2a0d15fe0626@github.com>
References: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>
 <ncLPZopu2PEdMRrM3e-ypb2OeXD4YGpJt4qyWpZBPLM=.2d3918ce-ea81-4ef0-9a4c-2a0d15fe0626@github.com>
Message-ID: <TgQ8zjtiCIMQ4358zU1PoB93D5vce3yRyJ7qw0pm-RQ=.5317ef24-dfc3-41d9-b0c0-13fea91d158f@github.com>

On Fri, 17 Nov 2023 17:28:40 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8318105
>
> test/micro/org/openjdk/bench/java/security/HSS.java line 83:
> 
>> 81:     @Setup
>> 82:     public void setup() throws Exception {
>> 83:         p = Security.getProvider("SUN");
> 
> I assume this was just a "sanity check" to see whether it's an Oracle/Sun JDK? In which case, I understand removing it. However, if it has to do with the threading model and some kind of locking of the provider, you might want to add some more to your description.

Yes, it was an unnecessary sanity check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16435#discussion_r1397660984


From anthony.scarpino at oracle.com  Fri Nov 17 19:50:58 2023
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 17 Nov 2023 11:50:58 -0800
Subject: JEP draft: PEM API (Preview)
In-Reply-To: <20231117013650.9D186660DD9@dd33810.kasserver.com>
References: <9567b12b-aef4-4ce0-a056-f0a287a657af@oracle.com>
 <20231117022046.3C8BE660C0D@dd33810.kasserver.com>
 <20231117013650.9D186660DD9@dd33810.kasserver.com>
Message-ID: <81c85df0-e4bb-46ac-9478-7a81ac7e1ce2@oracle.com>



On 11/16/23 5:36 PM, Bernd Eckenfels wrote:
> Anthony Scarpino wrote on 16. Nov 2023 23:47 (GMT +01:00):
>> Hi all,
>> 
>> We are proposing to add an API for PEM and a foundation for other
>> crypto encoding.
> 
> I like the modularity and that you do not try to squeeze it into the
> existing services.
> 
> I wonder if you should also allow to set comment or generally text
> headers when encoding and for decoding if you need access to the
> comment.
> 
> There are some variants like ?BEGIN PUBLiC SSH KEY? maybe the JEP
> should list the ones which are accepted
> 
> Does the encoder need to make the line configurable?


PEMEncoder/PEMDecoder support PKCS8 and X509, as those are the binary 
encodings the JDK JCE providers support.

Other encodings, like SSH, OpenSSL, or JOSE, would be implemented in a 
separate classes implementing Encoder<T> and Decoder<T>.  Those classes 
could parses the headers, footers, and binary encodings.

A single class parsing all encodings was too complicated.  Allowing 
developers to implement other Encoders/Decoders provides for 
customization and potentially contributions back to the JDK.

> Should initial version already support PQC keys?

It depends if PQC Key classes are availability by PEM integration.

Tony


From anthony.scarpino at oracle.com  Fri Nov 17 19:52:56 2023
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 17 Nov 2023 11:52:56 -0800
Subject: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <CACSnhuVo1=YFdKxomMQ5y-ECYHx2Wus_wXYthtJoa2XxR2vtYw@mail.gmail.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
 <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
 <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>
 <A6282C7A-270C-48B5-BA36-87A54D6FF2A0@oracle.com>
 <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com>
 <CACSnhuVo1=YFdKxomMQ5y-ECYHx2Wus_wXYthtJoa2XxR2vtYw@mail.gmail.com>
Message-ID: <dd3d0cbd-c8a4-49e3-bfa9-bf93b997d2d5@oracle.com>

As you may have seen, the PEM API draft is out: 
https://openjdk.org/jeps/8300911

Tony



On 10/18/23 3:00 AM, Karl Scheibelhofer wrote:
> Hi Sean,
> 
> Yes, I can help with this new PEM API.
> 
> Let me know, when there is something to review.
> 
> Best regards,
> 
> Karl
> 
> 
> On Tue, Oct 17, 2023, 19:12 Sean Mullan <sean.mullan at oracle.com 
> <mailto:sean.mullan at oracle.com>> wrote:
> 
>     Hi Karl,
> 
>     I discussed your proposal with some other colleagues.
> 
>     We generally feel a PEM KeyStore would be a useful addition to the
>     JDK. This would alleviate usability issues that many users encounter
>     when configuring and deploying applications that store keys or
>     certificates in PEM files.
> 
>     However, we would like to first make sure that your PEM KeyStore
>     implementation will work well with the PEM API that we will be
>     proposing soon. We think this is a perfect opportunity to ensure
>     they work well together and would appreciate your help in reviewing
>     and validating the API - would you be interested in helping out?
> 
>     Once that is done, we can discuss next steps.
> 
>     Thanks,
>     Sean
> 
> 
>>     On Oct 5, 2023, at 9:41 AM, Sean Mullan <sean.mullan at oracle.com
>>     <mailto:sean.mullan at oracle.com>> wrote:
>>
>>
>>
>>>     On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer
>>>     <karl.scheibelhofer at gmx.net <mailto:karl.scheibelhofer at gmx.net>>
>>>     wrote:
>>>
>>>     Hi Sean,
>>>
>>>     Yes, I had a look at the Contributing docs at the OpenJDK site
>>>     before. I also signed the OCA.
>>
>>     Great, thanks.
>>
>>>
>>>     Honestly, I thought there would be some more reaction on the
>>>     suggested PEM KeyStore. It would really be good to discuss the
>>>     topic with others. Is there anything we can do to get others in
>>>     sharing their thoughts on this?
>>
>>     I think there is a fair amount of interest in it, but reviewing
>>     something significant like this takes a bit of time, as I
>>     mentioned in my prior email. Also, if we do decide to accept the
>>     contribution, we want to make sure it works well with the PEM API
>>     that we are working on - we hope to have a draft of a JEP for that
>>     out in the next few weeks. So I think we probably need a few weeks
>>     to review your contribution.
>>
>>>
>>>     There is already a fair amount of documentation und unit tests.
>>>     See https://github.com/KarlScheibelhofer/java-crypto-tools/
>>>     <https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools/__;!!ACWV5N9M2RV99hQ!L4Oy66pyQcMu7F5jKCD98FvyWZGBlrWmmpnxhOkj2bAffn_KyL69pJh6Y36l9xIk-U4itzwJyPjubZxjk-SP2qN2C39SWwY$> .
>>
>>     Ok.
>>
>>     ?Sean
>>
>>>
>>>     Best regards,
>>>     Karl
>>>
>>>     On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mullan at oracle.com
>>>     <mailto:sean.mullan at oracle.com>> wrote:
>>>
>>>         Hi Karl,
>>>
>>>         The OpenJDK Developer?s Guide includes a helpful section on
>>>         Contributing to an OpenJDK Project [1]. I suggest you read
>>>         through that if you have not already. In particular, have you
>>>         signed the OCA? I don?t want to review your code/contribution
>>>         until that is done.
>>>
>>>         For this particular contribution, I don?t think there has
>>>         been enough discussion and evaluation from members of the
>>>         Security project. This would be a fairly major contribution.
>>>         Keep in mind that a contribution doesn?t mean the work ends
>>>         there.? There would need to be documentation, tests, and
>>>         ongoing support for the foreseeable future. We need to think
>>>         about these aspects every time we add a new feature, so there
>>>         needs to be a strong motivation for doing it.
>>>
>>>         Thanks,
>>>         Sean
>>>
>>>         [1]
>>>         https://openjdk.org/guide/#contributing-to-an-openjdk-project
>>>         <https://openjdk.org/guide/#contributing-to-an-openjdk-project>
>>>
>>>         > On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer
>>>         <karl.scheibelhofer at gmx.net
>>>         <mailto:karl.scheibelhofer at gmx.net>> wrote:
>>>         >
>>>         > Hi All,
>>>         >
>>>         > I would like to contribute my PEM KeyStore implementation
>>>         to the
>>>         > OpenJDK, including integration in the OpenJDK source and
>>>         creating a
>>>         > pull request.
>>>         > What is the recommended way to do this?
>>>         > Who can create a suitable ticket in OpenJDK to document the
>>>         > enhancement and to track the progress?
>>>         >
>>>         > What are the requirements for a pull request to get merged?
>>>         >
>>>         > Best regards
>>>         >
>>>         > Karl
>>>         >
>>>         > Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
>>>         > <karl.scheibelhofer at gmx.net
>>>         <mailto:karl.scheibelhofer at gmx.net>>:
>>>         >>
>>>         >> Hi? Tony!
>>>         >>
>>>         >> When the PEM API implementation becomes available it would
>>>         make sense
>>>         >> to use it inside the PEM Keystore implementation. It will
>>>         reduce the
>>>         >> code (the internal classes PemReader und PemWriter may become
>>>         >> obsolete), but it does not affect the functionality of the PEM
>>>         >> keystore. Users of the PEM Keystore won't experience a
>>>         difference.
>>>         >>
>>>         >> Let me know when there is something for the PEM API and I
>>>         will see if
>>>         >> I can assist.
>>>         >>
>>>         >> I would suggest starting with PEM Keystore now and not
>>>         wait for the
>>>         >> PEM API, because the time schedule for it seems vague. I
>>>         would try to
>>>         >> refactor my current PEM Keystore implementation to
>>>         integrate in the
>>>         >> OpenJDK sun.security.provider package. I do not expect any
>>>         API changes
>>>         >> or other compatibility issues with existing code. Then
>>>         consult this
>>>         >> group for feedback before creating a pull request.
>>>         >>
>>>         >> When the PEM API becomes available, rework the PEM Keystore
>>>         >> implementation to use it internally.
>>>         >>
>>>         >> What do you think?
>>>         >>
>>>         >> Best regards
>>>         >>
>>>         >>? Karl Scheibelhofer
>>>         >>
>>>         >> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
>>>         >> <anthony.scarpino at oracle.com
>>>         <mailto:anthony.scarpino at oracle.com>>:
>>>         >>>
>>>         >>> There are no doc links yet.
>>>         >>>
>>>         >>> Tony
>>>         >>>
>>>         >>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
>>>         >>>> Hi Tony,
>>>         >>>>
>>>         >>>> The motivation was mostly about reading PEM keys and
>>>         certificates
>>>         >>>> generated somewhere else. This is common practice in
>>>         enterprise
>>>         >>>> environments I work in. Because corporate key material
>>>         is subject to
>>>         >>>> centralized key management, including generation, backup
>>>         and rollover.
>>>         >>>> PEM is the format most software products can handle. For
>>>         Java
>>>         >>>> applications, having a PEM KeyStore would reduce the
>>>         often required
>>>         >>>> additional step of converting PEM key and certificate in
>>>         a Java
>>>         >>>> Keystore/PKCS#12.
>>>         >>>> Even truststores handling is easier with individual PEM
>>>         certificates
>>>         >>>> instead of a single PKCS#12 Truststore. Adding or
>>>         deleting a single
>>>         >>>> file instead of replacing the complete PKCS#12 store is
>>>         less error
>>>         >>>> prone and cleaner to track in version control. The
>>>         additional benefit
>>>         >>>> of a MAC in PKCS#12 adds little to no security in most
>>>         cases.
>>>         >>>> And being text based, PEM is more version control
>>>         friendly than binary PKCS#12.
>>>         >>>>
>>>         >>>> But to enable sound support of PEM, I also implemented
>>>         writing PEM
>>>         >>>> keys and certificates. This way, one can use the JDK
>>>         keytool to
>>>         >>>> generate key and certificate signing requests in PEM
>>>         format. Getting
>>>         >>>> the certificate from the CA in PEM, one can use PEM
>>>         throughout the
>>>         >>>> process.
>>>         >>>>
>>>         >>>> Do you have any links or documentation on the PEM API
>>>         JEP that you mentioned?
>>>         >>>>
>>>         >>>> Thank you for your feedback and best regards
>>>         >>>>
>>>         >>>>? ?Karl
>>>         >>>>
>>>         >>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
>>>         >>>> <anthony.scarpino at oracle.com
>>>         <mailto:anthony.scarpino at oracle.com>>:
>>>         >>>>>
>>>         >>>>> Hi Karl
>>>         >>>>>
>>>         >>>>> The keystore is interesting and may have some value. 
>>>         Was your use case
>>>         >>>>> mostly reading PEM keys and certificates generated
>>>         elsewhere for use
>>>         >>>>> with a particular application, maybe webservers?? Did
>>>         you see value in
>>>         >>>>> writing to this keystore from Java?
>>>         >>>>>
>>>         >>>>> On the topic of PEM, I hope before the end of the year
>>>         to have a PEM API
>>>         >>>>> JEP.? I would be interested in your API feedback from
>>>         your keystore
>>>         >>>>> experiences.? I think if this keystore contribution was
>>>         accepted, it
>>>         >>>>> should wait so it can use that API.
>>>         >>>>>
>>>         >>>>> thanks
>>>         >>>>>
>>>         >>>>> Tony
>>>         >>>>>
>>>         >>>>>
>>>         >>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
>>>         >>>>>> Hi,
>>>         >>>>>>
>>>         >>>>>> Working with Java and the JCA KeyStore for decades, I
>>>         came across
>>>         >>>>>> many situations where I thought it would be convenient
>>>         to be
>>>         >>>>>> able to load private keys and certificates in PEM
>>>         format directly
>>>         >>>>>> using the KeyStore API. Without the need to convert
>>>         them to PKCS#12/JKS.
>>>         >>>>>>
>>>         >>>>>> You can find my implementation of a PEM KeyStore in
>>>         >>>>>>
>>>         https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ <https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$> .
>>>         >>>>>>
>>>         >>>>>> I wondered if it would make sense to integrate such an
>>>         implementation
>>>         >>>>>> in one of the standard providers of OpenJDK - like the
>>>         SUN provider.
>>>         >>>>>> What do you think?
>>>         >>>>>>
>>>         >>>>>> Best regards
>>>         >>>>>>
>>>         >>>>>>? ? Karl
>>>
>>
> 


From kdriver at openjdk.org  Fri Nov 17 20:25:32 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 17 Nov 2023 20:25:32 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v3]
In-Reply-To: <CAbwxT2iLKRNPzRS3KcWMl8f1If63tnsgkKmSQqbIfA=.a418464a-c936-4418-b2aa-389a987c595e@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <CAbwxT2iLKRNPzRS3KcWMl8f1If63tnsgkKmSQqbIfA=.a418464a-c936-4418-b2aa-389a987c595e@github.com>
Message-ID: <3es3fslid_87R_xEHdXCdffp_ufd4wc9_5LO62t7LfY=.72fc8c60-42ff-487d-b74c-087c09e4258a@github.com>

On Fri, 17 Nov 2023 15:49:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cite resources

src/java.base/share/classes/sun/security/provider/SHAKE256.java line 27:

> 25: package sun.security.provider;
> 26: 
> 27: import java.security.*;

nitpick: here's another wildcard

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1397847238


From weijun at openjdk.org  Fri Nov 17 21:23:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 21:23:01 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v4]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <g9H8SW3epxqWBgKVkePQHsDDG9GGoZodp9LHNgy8_CU=.17e1a7d6-72f6-4df0-a1d7-9f14a9e6c284@github.com>

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

  full imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/1ae8ac97..520b6725

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

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

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


From weijun at openjdk.org  Fri Nov 17 21:23:03 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 21:23:03 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v3]
In-Reply-To: <3es3fslid_87R_xEHdXCdffp_ufd4wc9_5LO62t7LfY=.72fc8c60-42ff-487d-b74c-087c09e4258a@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <CAbwxT2iLKRNPzRS3KcWMl8f1If63tnsgkKmSQqbIfA=.a418464a-c936-4418-b2aa-389a987c595e@github.com>
 <3es3fslid_87R_xEHdXCdffp_ufd4wc9_5LO62t7LfY=.72fc8c60-42ff-487d-b74c-087c09e4258a@github.com>
Message-ID: <37TWSQF1TlNOLg56mGUZbEf4UnGboPkPJOELBzVoiWI=.1ac2f8a7-11d4-44d1-946b-a0a26f9b1208@github.com>

On Fri, 17 Nov 2023 20:22:49 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cite resources
>
> src/java.base/share/classes/sun/security/provider/SHAKE256.java line 27:
> 
>> 25: package sun.security.provider;
>> 26: 
>> 27: import java.security.*;
> 
> nitpick: here's another wildcard

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16660#discussion_r1397897966


From anthony.scarpino at oracle.com  Fri Nov 17 21:46:10 2023
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 17 Nov 2023 13:46:10 -0800
Subject: JEP draft: PEM API (Preview)
In-Reply-To: <20231117013650.9D186660DD9@dd33810.kasserver.com>
References: <9567b12b-aef4-4ce0-a056-f0a287a657af@oracle.com>
 <20231117022046.3C8BE660C0D@dd33810.kasserver.com>
 <20231117013650.9D186660DD9@dd33810.kasserver.com>
Message-ID: <ed741040-aeeb-42da-8126-fb866be23d6a@oracle.com>



On 11/16/23 5:36 PM, Bernd Eckenfels wrote:
> I wonder if you should also allow to set comment or generally text
> headers when encoding and for decoding if you need access to the
> comment.
I neglected to ask what you meant by setting or accessing a "comment". 
Are you talking about non-PEM data in a Reader or File? Or where you 
referring to the header/footer text?

thanks

Tony


From weijun at openjdk.org  Fri Nov 17 23:33:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Nov 2023 23:33:56 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v5]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <oSrTtxp6rS0QKZp7tpfNuc5432mv2NYtKauj7NALK-8=.28f77ea9-df02-479c-b76c-bb558bd6db0b@github.com>

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

  no len no params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/520b6725..4f11b85d

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

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

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


From abakhtin at openjdk.org  Mon Nov 20 06:59:47 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 20 Nov 2023 06:59:47 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore
Message-ID: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>

Please review the proposed fix.

The patch loads system root certificates from the MacOS Keychain with TrustSettings.
It allows to build a trusted certificate path using the MacOS Keychain store only.

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

Commit messages:
 - 8320362: Load anchor certificates from Keychain keystore

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

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


From weijun at openjdk.org  Mon Nov 20 13:52:29 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 13:52:29 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <zYSWfguP6KkoDgxwI4WS04wp_h4ZoKudRyxgQihipG0=.3e022794-332a-4b49-acce-2badc97abc30@github.com>

On Sat, 18 Nov 2023 02:41:05 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

How about putting these certs into a different keystore? Anyway, there needs a CSR and release note for this big change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1819099471


From weijun at openjdk.org  Mon Nov 20 13:57:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 13:57:58 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v4]
In-Reply-To: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
Message-ID: <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>

> When blocksize is less than digest output length, call `keccak` more.

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

  minimize code changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16698/files
  - new: https://git.openjdk.org/jdk/pull/16698/files/4133fdc1..80a6fe66

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

  Stats: 105 lines in 4 files changed: 1 ins; 95 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16698/head:pull/16698

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


From weijun at openjdk.org  Mon Nov 20 13:58:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 13:58:01 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v3]
In-Reply-To: <lrbEwPWjq9y9x3SzI-FTAamxZ2f9zg0VNcmrxynOSC0=.eb5e021c-9f2d-49c3-90fd-16b660526f2d@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
 <lrbEwPWjq9y9x3SzI-FTAamxZ2f9zg0VNcmrxynOSC0=.eb5e021c-9f2d-49c3-90fd-16b660526f2d@github.com>
Message-ID: <jHchsOwpn5U8J-TNL_HWUNAmgG53HrX99pvKmVAlMTs=.eb6e8008-03c1-4468-94a3-77ea6aaf5aa9@github.com>

On Fri, 17 Nov 2023 00:05:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When blocksize is less than digest output length, call `keccak` more.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment for squeezeOffset

New commit pushed. I've minimized the code changes for this bug fix. XOF functions are removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16698#issuecomment-1819107486


From ihse at openjdk.org  Mon Nov 20 14:42:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 20 Nov 2023 14:42:21 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v2]
In-Reply-To: <fMAtTRYBr8H2_RWEgp9ZLHsaRPNqHuSvLYIqYX7AsO0=.622cc669-9f30-47ec-ae4c-77f1368aaf21@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <8jiTNjfHN0ewSsSImcSX3I6pic1M8KUS4wOV3xUUksw=.98ee2221-7639-43d2-b298-9af5635e541a@github.com>
 <IPQlO3BIv_KP5MVI2VYrpyfjibP-W5y6jM4Rd_XQ3OY=.0a6378b4-d516-4696-9a10-8c1ca6d82e85@github.com>
 <fMAtTRYBr8H2_RWEgp9ZLHsaRPNqHuSvLYIqYX7AsO0=.622cc669-9f30-47ec-ae4c-77f1368aaf21@github.com>
Message-ID: <iSqip__mKmsHn0DLhDCfJa1d-N3tF8Bs8yyvqXZJV88=.b6fb8f9c-beed-4650-9a81-1092e9b338bd@github.com>

On Mon, 23 Oct 2023 11:43:06 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> I am not sure, but shouldn`t the change also adopt the documentation in test/jdk/sun/security/pkcs11/README
>
>> I am not sure, but shouldn`t the change also adopt the documentation in test/jdk/sun/security/pkcs11/README
> 
> Good catch!

@mpdonova Is there anything blocking the integration of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16294#issuecomment-1819191729


From mpowers at openjdk.org  Mon Nov 20 15:41:47 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 20 Nov 2023 15:41:47 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v4]
In-Reply-To: <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
 <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>
Message-ID: <hJ0wWo1QcIKOqzL-7RuiE_VudSfOsmIrfbDqCvtsHaY=.d98f7cf0-1031-4cd8-b51c-28166b382c9f@github.com>

On Mon, 20 Nov 2023 13:57:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When blocksize is less than digest output length, call `keccak` more.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minimize code changes

Nice!

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

PR Comment: https://git.openjdk.org/jdk/pull/16698#issuecomment-1819305134


From duke at openjdk.org  Mon Nov 20 16:22:54 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 20 Nov 2023 16:22:54 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v8]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <ez8dEoHm1xKpiAksk7lJ3yOacNCSuabeU8UQ0UPZTY8=.6ebd5425-6a69-412b-a17c-c284203f3ce6@github.com>

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

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

 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Use newStringLatin1NoRepl in UUID
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - update javadoc
 - clean newStringNoRepl1
 - clean newStringNoRepl1
 - Rename jla to JLA
 - ... and 1 more: https://git.openjdk.org/jdk/compare/40b5fa87...3898c8e5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/e92a877c..3898c8e5

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

  Stats: 678717 lines in 2808 files changed: 115107 ins; 487865 del; 75745 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

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


From mullan at openjdk.org  Mon Nov 20 16:52:05 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 20 Nov 2023 16:52:05 GMT
Subject: RFR: JDK-8320372:
 test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed
Message-ID: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>

Set the validity date to the notBefore date of the EE certs so that validation won't fail when the certs expire - there is only one cert in the path so this should be sufficient. I also removed the trust anchor from the CertPath as it isn't necessary to include that in the path.

Not sure if it is really necessary to complete before I integrate, but Mach5 in progress.

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

Commit messages:
 - Set validity date so that validation won't fail when cert expires

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

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


From weijun at openjdk.org  Mon Nov 20 17:07:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 17:07:12 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v6]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <KNeAdhitjqsUexYBc5qW7TH2H09cBcoZD46NcxaUjwg=.36dc743a-05f3-4e30-bd34-fb4b68d8746f@github.com>

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

 - more spec change, restruct SHAKE256.java
 - Revert "throw iape"
   
   This reverts commit d01bf93999d85081734f131873a94009d55ae364.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/4f11b85d..f8c18ed0

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

  Stats: 86 lines in 5 files changed: 11 ins; 35 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/16660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16660/head:pull/16660

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


From weijun at openjdk.org  Mon Nov 20 17:10:37 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 17:10:37 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v6]
In-Reply-To: <KNeAdhitjqsUexYBc5qW7TH2H09cBcoZD46NcxaUjwg=.36dc743a-05f3-4e30-bd34-fb4b68d8746f@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
 <KNeAdhitjqsUexYBc5qW7TH2H09cBcoZD46NcxaUjwg=.36dc743a-05f3-4e30-bd34-fb4b68d8746f@github.com>
Message-ID: <U_Bs5BprcuduuzEJ3GrFEa30mE5C5xT6poMeSTfeXm4=.2df5762e-e74c-4554-9fef-53c51ddd6724@github.com>

On Mon, 20 Nov 2023 17:07:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.
>
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - more spec change, restruct SHAKE256.java
>  - Revert "throw iape"
>    
>    This reverts commit d01bf93999d85081734f131873a94009d55ae364.

The IAPE change is reverted, only NSAE is thrown. This is consistent with `SecureRandom`, which is the only primitive in JCA that contains `getInstance` calls with and without parameters.

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

PR Comment: https://git.openjdk.org/jdk/pull/16660#issuecomment-1819476052


From alanb at openjdk.org  Mon Nov 20 17:13:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Nov 2023 17:13:15 GMT
Subject: RFR: JDK-8320372:
 test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed
In-Reply-To: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
References: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
Message-ID: <xhUSZriuFnQhuJ6g9PHzLt-VMe1VZouaF5eW2oVxnzU=.b4b2f41b-2ce5-4e0b-8be7-c3181cb782ad@github.com>

On Mon, 20 Nov 2023 16:43:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Set the validity date to the notBefore date of the EE certs so that validation won't fail when the certs expire - there is only one cert in the path so this should be sufficient. I also removed the trust anchor from the CertPath as it isn't necessary to include that in the path.
> 
> Not sure if it is really necessary to complete before I integrate, but Mach5 in progress.

Looks okay, I probably won't extend the `@bug` list as this is a test issue, the test hasn't been extended to cover other issues.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16744#pullrequestreview-1740315594


From mullan at openjdk.org  Mon Nov 20 17:21:00 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 20 Nov 2023 17:21:00 GMT
Subject: RFR: JDK-8320372:
 test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed
 [v2]
In-Reply-To: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
References: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
Message-ID: <_XjotjyXRvIIWnpqTxCzeAXrF4rbVKQurQ-yD5Qws6w=.ec760350-5cf7-40f1-8ea0-097d083bbe68@github.com>

> Set the validity date to the notBefore date of the EE certs so that validation won't fail when the certs expire - there is only one cert in the path so this should be sufficient. I also removed the trust anchor from the CertPath as it isn't necessary to include that in the path.
> 
> Not sure if it is really necessary to complete before I integrate, but Mach5 in progress.

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

  Remove bugid.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16744/files
  - new: https://git.openjdk.org/jdk/pull/16744/files/9a145902..11bdb998

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

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

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


From alanb at openjdk.org  Mon Nov 20 17:26:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Nov 2023 17:26:08 GMT
Subject: RFR: JDK-8320372:
 test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed
 [v2]
In-Reply-To: <_XjotjyXRvIIWnpqTxCzeAXrF4rbVKQurQ-yD5Qws6w=.ec760350-5cf7-40f1-8ea0-097d083bbe68@github.com>
References: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
 <_XjotjyXRvIIWnpqTxCzeAXrF4rbVKQurQ-yD5Qws6w=.ec760350-5cf7-40f1-8ea0-097d083bbe68@github.com>
Message-ID: <jD6VX18YQsP50SCu7l5HnvMoFGmAK2FtfnjOMmAuBbk=.4aaff507-03d0-4d57-ab87-1e764b9d1ae7@github.com>

On Mon, 20 Nov 2023 17:21:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Set the validity date to the notBefore date of the EE certs so that validation won't fail when the certs expire - there is only one cert in the path so this should be sufficient. I also removed the trust anchor from the CertPath as it isn't necessary to include that in the path.
>> 
>> Not sure if it is really necessary to complete before I integrate, but Mach5 in progress.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove bugid.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16744#pullrequestreview-1740338691


From mullan at openjdk.org  Mon Nov 20 17:50:35 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 20 Nov 2023 17:50:35 GMT
Subject: Integrated: JDK-8320372:
 test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed
In-Reply-To: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
References: <AdLyWzKNVSBT9rsa9Yf_YGodJSWvnQ8o8t7gFNvIOl4=.1b55cbd0-76fa-4d0e-9ce2-c0c456eab39e@github.com>
Message-ID: <mYDzflrP7w9R2OUhnUiRNNZaHEPShh9Ks62e5BG46CI=.b0b8211a-7be6-4a77-81ee-67a982d671f9@github.com>

On Mon, 20 Nov 2023 16:43:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Set the validity date to the notBefore date of the EE certs so that validation won't fail when the certs expire - there is only one cert in the path so this should be sufficient. I also removed the trust anchor from the CertPath as it isn't necessary to include that in the path.
> 
> Not sure if it is really necessary to complete before I integrate, but Mach5 in progress.

This pull request has now been integrated.

Changeset: a2c0fa6f
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2c0fa6f9ccefd3d1b088c51d0b8170cfb59a885
Stats:     10 lines in 1 file changed: 0 ins; 1 del; 9 mod

8320372: test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed

Reviewed-by: alanb

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

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


From weijun at openjdk.org  Mon Nov 20 19:23:24 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 19:23:24 GMT
Subject: Integrated: 8320208: Update Public Suffix List to b5bf572
In-Reply-To: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>
References: <Oni-nUbQHvabhBYwcePF5QhJWW0TMH9jfXsnUu_FsSY=.a5379103-6184-4203-9e8b-ae529d4cd26e@github.com>
Message-ID: <Aro9kM17XwnMv9WneNXI8Bp858Yt6sXw56n2IcCcCJs=.227d0621-9709-4f59-918f-fcf150685486@github.com>

On Thu, 16 Nov 2023 14:50:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update `public_suffix_list.dat` to the latest.

This pull request has now been integrated.

Changeset: 2b4e9914
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b4e99140a315d3da765b2edb031b38725a05f1c
Stats:     3002 lines in 4 files changed: 1753 ins; 73 del; 1176 mod

8320208: Update Public Suffix List to b5bf572

Reviewed-by: mullan

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

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


From valeriep at openjdk.org  Mon Nov 20 22:17:05 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 20 Nov 2023 22:17:05 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v4]
In-Reply-To: <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
 <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>
Message-ID: <Xgckfy_VvMjFsbtwFJ8XcDq3NcGq4VwLFaFGvWPi9U0=.d5794c2f-32ce-4d27-9c14-dc4f440b3623@github.com>

On Mon, 20 Nov 2023 13:57:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When blocksize is less than digest output length, call `keccak` more.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minimize code changes

Changes look fine. The synopsis should be updated as this is about SHAKE128? In addition, now that the digest output can be variable-length, it'd be good to update the comment for the `private void keccak() `method since the capacity c is not twice of digest length as in the case of SHA-3.

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

PR Comment: https://git.openjdk.org/jdk/pull/16698#issuecomment-1819889428


From weijun at openjdk.org  Mon Nov 20 22:39:06 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 22:39:06 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v4]
In-Reply-To: <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
 <81AmumREZ2J7ICCsf_ZofIIFln4_-Z3Qhe-C_GQPLeA=.8d2b7a1b-19f3-4844-b356-3929694c61d2@github.com>
Message-ID: <GSjZLJ5QBuXZ4MNcu9s6AlBTe1NlH7iIBc_9OYRQOLM=.fcf9cfbc-62db-4d51-b50e-055629c9e21b@github.com>

On Mon, 20 Nov 2023 13:57:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When blocksize is less than digest output length, call `keccak` more.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minimize code changes

OK, I will remove the ` = (digest length x 2)` words from `keccak()`. As for the synopsis, this bug was about the bug in SHAKE256, and I don?t know how to add SHAKE128 there. One solution is to remove `SHAKE128.java` at all from this code change, and I can add it into my other PR at [RFE 4936767: Parameters for MessageDigest](https://github.com/openjdk/jdk/pull/16660). How do you think of this?

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

PR Comment: https://git.openjdk.org/jdk/pull/16698#issuecomment-1819915372


From weijun at openjdk.org  Mon Nov 20 23:26:44 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 23:26:44 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v5]
In-Reply-To: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
Message-ID: <-yDcV_fFZ7n_6mmUzXNyfgLKBxhZs3Ebtlm0n4fsiFk=.4028fa26-abf6-43df-ab8c-bf4d9ea9d805@github.com>

> When blocksize is less than digest output length, call `keccak` more.

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

  update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16698/files
  - new: https://git.openjdk.org/jdk/pull/16698/files/80a6fe66..12c89941

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

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

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


From valeriep at openjdk.org  Mon Nov 20 23:28:07 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 20 Nov 2023 23:28:07 GMT
Subject: RFR: 8320192: SHAKE256 does not work correctly if n >= 137 [v5]
In-Reply-To: <-yDcV_fFZ7n_6mmUzXNyfgLKBxhZs3Ebtlm0n4fsiFk=.4028fa26-abf6-43df-ab8c-bf4d9ea9d805@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
 <-yDcV_fFZ7n_6mmUzXNyfgLKBxhZs3Ebtlm0n4fsiFk=.4028fa26-abf6-43df-ab8c-bf4d9ea9d805@github.com>
Message-ID: <IwB1tVRfGL4EsZwLMQ0XENuoSwOhjWiLkJsRJsEd-ns=.c9f7aaa9-4a4d-4c02-a44d-fc25f9956748@github.com>

On Mon, 20 Nov 2023 23:26:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When blocksize is less than digest output length, call `keccak` more.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment

Looks good to me. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16698#pullrequestreview-1740863619


From weijun at openjdk.org  Mon Nov 20 23:32:18 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 23:32:18 GMT
Subject: Integrated: 8320192: SHAKE256 does not work correctly if n >= 137
In-Reply-To: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
References: <T6O-mZkb3Ba_zfWPbmI6Nfp0xsxOBQ1m1A9px8iFPb8=.91548fa3-8c7d-42ec-8b89-b8d1233d8aa9@github.com>
Message-ID: <B54s3TMH-1ruuzFM2g9S2xeQWogl4ZK-tDAskbzxpuU=.a1159342-0154-40eb-9242-5b823ff82e7b@github.com>

On Thu, 16 Nov 2023 20:45:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> When blocksize is less than digest output length, call `keccak` more.

This pull request has now been integrated.

Changeset: fcb4df26
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcb4df26f18c7a10e4511f4be948c887f14ee093
Stats:     60 lines in 2 files changed: 57 ins; 0 del; 3 mod

8320192: SHAKE256 does not work correctly if n >= 137

Co-authored-by: Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Reviewed-by: mpowers, valeriep

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

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


From duke at openjdk.org  Mon Nov 20 23:38:42 2023
From: duke at openjdk.org (rebarbora-mckvak)
Date: Mon, 20 Nov 2023 23:38:42 GMT
Subject: RFR: 8313367: Local Computer store is opened with max. allowed
 permissions
Message-ID: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>

This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367

If the process does not have write permissions, the store is opened as read-only (instead of failing).

Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

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

Commit messages:
 - 8313367: Local Computer store is opened with max. allowed permissions

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

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


From weijun at openjdk.org  Mon Nov 20 23:50:29 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Nov 2023 23:50:29 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v7]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <Ikozk_feXW-DLtIqrpNSnQr79dc4OHN0h_CUszv0SXM=.482a45c3-353f-4b36-ae9c-8c6bb8664169@github.com>

> Add parameters to `MessageDigest` and introduce `SHAKE256-LEN` with an integer parameter.

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

 - SHAKE128-LEN, tests
 - Merge branch 'master' into 4936767
 - more spec change, restruct SHAKE256.java
 - Revert "throw iape"
   
   This reverts commit d01bf93999d85081734f131873a94009d55ae364.
 - no len no params
 - full imports
 - cite resources
 - throw iape
 - new class spec
 - more changes
 - ... and 1 more: https://git.openjdk.org/jdk/compare/af014756...711d6cae

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/f8c18ed0..711d6cae

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

  Stats: 631316 lines in 1197 files changed: 89045 ins; 478130 del; 64141 mod
  Patch: https://git.openjdk.org/jdk/pull/16660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16660/head:pull/16660

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


From valeriep at openjdk.org  Tue Nov 21 00:51:13 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 21 Nov 2023 00:51:13 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v4]
In-Reply-To: <Cb1fSpB5dyCr9dUDnH0_xn5qsOlC8CNeO851CAJ7kc4=.a5414197-af46-439d-ab2c-268a735bf507@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <Cb1fSpB5dyCr9dUDnH0_xn5qsOlC8CNeO851CAJ7kc4=.a5414197-af46-439d-ab2c-268a735bf507@github.com>
Message-ID: <iK-Kzqrb-6FzJZPeiZeeGBAIZ8Y7Z8hJKyMDNIPnldU=.2ea1aee2-8547-4b13-af0e-4bd3925c2a28@github.com>

On Tue, 24 Oct 2023 19:58:58 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed whitespace errors

doc/testing.html line 582:

> 580: correctly, the system property
> 581: <code>jdk.test.lib.artifacts.&lt;NAME&gt;</code> is required on Ubuntu
> 582: 18.04 to specify the alternative NSS lib directories. The

directory if allowing only single value.

doc/testing.html line 584:

> 582: 18.04 to specify the alternative NSS lib directories. The
> 583: <code>&lt;NAME&gt;</code> component should be replaced with the name
> 584: element of the appropriate<code>@Artfact</code> class. (See

typo: Artifact

doc/testing.md line 604:

> 602: on Ubuntu 18.04 with the default NSS version in the system. To run these tests
> 603: correctly, the system property `jdk.test.lib.artifacts.<NAME>` is required on
> 604: Ubuntu 18.04 to specify the alternative NSS lib directories. The `<NAME>`

If only single value is allowed for the system property, should it be "directory" instead of "directories"?

doc/testing.md line 605:

> 603: correctly, the system property `jdk.test.lib.artifacts.<NAME>` is required on
> 604: Ubuntu 18.04 to specify the alternative NSS lib directories. The `<NAME>`
> 605: component should be replaced with the name element of the appropriate`@Artfact`

typo: Artifact

test/jdk/sun/security/pkcs11/README line 10:

> 8: The system property, jdk.test.lib.artifacts.<NAME>, can specify an absolute path
> 9: to the local NSS library directory. The <NAME> component should be replaced with
> 10: the name element of the appropriate @Artfact class.

typo: Artifact

test/jdk/sun/security/pkcs11/README line 14:

> 12: 
> 13: 2. Pre-built NSS libraries from artifactory server
> 14: If the value of system property test.nss.lib.paths is not set, the tests will try

So, do we still support the "test.nss.lib.paths" system property? Or should the above comment be updated as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1399904586
PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1399904251
PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1399903808
PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1399902987
PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1399901453
PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1399902059


From jpai at openjdk.org  Tue Nov 21 06:19:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Nov 2023 06:19:23 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <FjTkazqYeW-1v3iMN5pZ1vd62TBPD-hG83LKCJDEp9I=.0fb8a2b6-1a69-4c7a-b18a-6d7e2b5b4d0a@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

This has now been addressed through https://github.com/openjdk/jdk/pull/16704

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

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1820304388


From mdonovan at openjdk.org  Tue Nov 21 12:36:24 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 21 Nov 2023 12:36:24 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v5]
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <5zUm1egOjX3ndUs6yOyoFf3Njx3obRoMnsw3TZU0jas=.e0f1f421-442f-4559-b05f-0624bc971409@github.com>

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

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

  updated documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16294/files
  - new: https://git.openjdk.org/jdk/pull/16294/files/8df921f6..46e39b2e

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

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

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


From mdonovan at openjdk.org  Tue Nov 21 12:36:27 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 21 Nov 2023 12:36:27 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v4]
In-Reply-To: <iK-Kzqrb-6FzJZPeiZeeGBAIZ8Y7Z8hJKyMDNIPnldU=.2ea1aee2-8547-4b13-af0e-4bd3925c2a28@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <Cb1fSpB5dyCr9dUDnH0_xn5qsOlC8CNeO851CAJ7kc4=.a5414197-af46-439d-ab2c-268a735bf507@github.com>
 <iK-Kzqrb-6FzJZPeiZeeGBAIZ8Y7Z8hJKyMDNIPnldU=.2ea1aee2-8547-4b13-af0e-4bd3925c2a28@github.com>
Message-ID: <5nW3pKo8aTh5L_Su5gtNiK1eRk952sEeZZRkOXYOzeE=.bd53e5fb-b9a0-4061-9b42-e83010bb4597@github.com>

On Tue, 21 Nov 2023 00:43:36 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed whitespace errors
>
> test/jdk/sun/security/pkcs11/README line 14:
> 
>> 12: 
>> 13: 2. Pre-built NSS libraries from artifactory server
>> 14: If the value of system property test.nss.lib.paths is not set, the tests will try
> 
> So, do we still support the "test.nss.lib.paths" system property? Or should the above comment be updated as well?

That property is no longer supported. I updated the comment appropriately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1400533255


From ihse at openjdk.org  Tue Nov 21 13:46:09 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 21 Nov 2023 13:46:09 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v5]
In-Reply-To: <5zUm1egOjX3ndUs6yOyoFf3Njx3obRoMnsw3TZU0jas=.e0f1f421-442f-4559-b05f-0624bc971409@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <5zUm1egOjX3ndUs6yOyoFf3Njx3obRoMnsw3TZU0jas=.e0f1f421-442f-4559-b05f-0624bc971409@github.com>
Message-ID: <hMdNrmpATjNTaX6pzU0JhWj7C4i4lz074YKirD3gNNY=.2ebb05b8-7102-4d15-9f37-d10d2e0911a1@github.com>

On Tue, 21 Nov 2023 12:36:24 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated documentation

doc/testing.md line 605:

> 603: correctly, the system property `jdk.test.lib.artifacts.<NAME>` is required on
> 604: Ubuntu 18.04 to specify the alternative NSS lib directory. The `<NAME>`
> 605: component should be replaced with the name element of the appropriate`@Artifact`

Space missing after "appropriate". Also please make sure you keep 80 char long lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1400621814


From mdonovan at openjdk.org  Tue Nov 21 13:55:29 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 21 Nov 2023 13:55:29 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v6]
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <zatCo1lBckROs80eF4qBFipdZnVs1oNEMkSYhGbIz5I=.1e5b137a-744e-45f5-a66e-cbbfe1d8666c@github.com>

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

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

  fixed spacing and line length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16294/files
  - new: https://git.openjdk.org/jdk/pull/16294/files/46e39b2e..038479a9

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

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

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


From ihse at openjdk.org  Tue Nov 21 14:37:27 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 21 Nov 2023 14:37:27 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v6]
In-Reply-To: <zatCo1lBckROs80eF4qBFipdZnVs1oNEMkSYhGbIz5I=.1e5b137a-744e-45f5-a66e-cbbfe1d8666c@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <zatCo1lBckROs80eF4qBFipdZnVs1oNEMkSYhGbIz5I=.1e5b137a-744e-45f5-a66e-cbbfe1d8666c@github.com>
Message-ID: <v1RGIzgfnQHs8Y6h6fkXs8kkGgBgn-EVPfJRmKRBhxY=.180875ce-298f-48da-b1e1-9989b88ec84d@github.com>

On Tue, 21 Nov 2023 13:55:29 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed spacing and line length

doc/testing.md line 605:

> 603: correctly, the system property `jdk.test.lib.artifacts.<NAME>` is required on
> 604: Ubuntu 18.04 to specify the alternative NSS lib directory. The `<NAME>`
> 605: component should be replaced with the name element of the appropriate 

Trailing whitespace

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16294#discussion_r1400694611


From mdonovan at openjdk.org  Tue Nov 21 14:47:39 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 21 Nov 2023 14:47:39 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v7]
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <S6r9HtMluyhHHJcs6a2dJ_0K0gmhKSJQ3bS_5Fp10EU=.ca049f19-ce96-4a2a-83dd-5412318611d0@github.com>

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

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

  removed trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16294/files
  - new: https://git.openjdk.org/jdk/pull/16294/files/038479a9..440ea3e5

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

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

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


From ihse at openjdk.org  Tue Nov 21 15:05:10 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 21 Nov 2023 15:05:10 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v7]
In-Reply-To: <S6r9HtMluyhHHJcs6a2dJ_0K0gmhKSJQ3bS_5Fp10EU=.ca049f19-ce96-4a2a-83dd-5412318611d0@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <S6r9HtMluyhHHJcs6a2dJ_0K0gmhKSJQ3bS_5Fp10EU=.ca049f19-ce96-4a2a-83dd-5412318611d0@github.com>
Message-ID: <rR-JRSPHo6dzBGo4QUiyBCPot1PznGuiguh_YZlpNOg=.6e801ab6-0b90-4b79-8d81-5386c5f9fc3f@github.com>

On Tue, 21 Nov 2023 14:47:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed trailing whitespace

This looks good from a build perspective now.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16294#pullrequestreview-1742243361


From weijun at openjdk.org  Tue Nov 21 17:49:25 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Nov 2023 17:49:25 GMT
Subject: Integrated: 8319124: Update XML Security for Java to 3.0.3
In-Reply-To: <4m8cqWXNw6z4x03UftD6RK0JWt9NrnBH9XOfHPbeGx4=.cc8699b3-b758-41a0-8b6e-273a36557fbf@github.com>
References: <4m8cqWXNw6z4x03UftD6RK0JWt9NrnBH9XOfHPbeGx4=.cc8699b3-b758-41a0-8b6e-273a36557fbf@github.com>
Message-ID: <BP12y_k66eAYs-QeqZceLlAmlM5g3n2PmVlBj4NSPjo=.48288fc8-46a8-4e6e-a98b-5019b34ebfa9@github.com>

On Thu, 16 Nov 2023 14:30:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update XMLDsig implementation to match Apache Santuario 3.0.3.
> 
> Changes include (significance in descending order):
> 
> - `SignatureMethod.java`: new signature method URIs defined
> - `SignatureBaseRSA.java`: `SignatureBaseRSAPSS` and refactoring
> - `JCEMapper.java`: use of `ThreadLocal`
> - `DigestorOutputStream.java`: one synchronized method
> - `XMLUtils.java`: renames, one new method not used anywhere, some log change
> - `Init.java`: some refactoring
> - `DOMSignatureMethod.java`: new MGF1 methods, some refactoring
> - `DOMXMLSignatureFactory.java`: new signature methods
> - `santuario.md`, `XMLDSigRI.java`: bump to 3.0.3
> - `DOMXMLSignature.java`: some finals
> - `NameSpaceSymbTable.java`: renames
> - Base64.java: no longer final
> - Others: reorder imports, add `@Override`, foreach, diamond operators

This pull request has now been integrated.

Changeset: 1c0bd81a
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c0bd81a10f97c752818163a573d5983c7e481ac
Stats:     1568 lines in 130 files changed: 1150 ins; 231 del; 187 mod

8319124: Update XML Security for Java to 3.0.3

Reviewed-by: mullan

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

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


From valeriep at openjdk.org  Tue Nov 21 23:40:07 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 21 Nov 2023 23:40:07 GMT
Subject: RFR: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and
 newer [v7]
In-Reply-To: <S6r9HtMluyhHHJcs6a2dJ_0K0gmhKSJQ3bS_5Fp10EU=.ca049f19-ce96-4a2a-83dd-5412318611d0@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
 <S6r9HtMluyhHHJcs6a2dJ_0K0gmhKSJQ3bS_5Fp10EU=.ca049f19-ce96-4a2a-83dd-5412318611d0@github.com>
Message-ID: <BPyhGmnFT-y76eQ4TEw6nULERsJ_1vL63ggUOIC8dtE=.1f76a687-a588-40e6-8438-f54e77249b2a@github.com>

On Tue, 21 Nov 2023 14:47:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Hello,
>> 
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed trailing whitespace

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16294#pullrequestreview-1743327412


From weijun at openjdk.org  Wed Nov 22 03:10:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Nov 2023 03:10:40 GMT
Subject: RFR: 4936767: Parameters for MessageDigest [v8]
In-Reply-To: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
References: <AsZ9NhLQvz-XTgIs9GCuuwm5hqtlKNkoM8KQ0ZrWL4M=.3f6a3c78-254d-4dfb-9d16-8b503443f141@github.com>
Message-ID: <VfUo4uWnBLfzs5FSgBxqrFhKKyBrdLewnzMvNx3-tYY=.831ce156-7a7c-4123-819a-802183dc1122@github.com>

> Add parameters to `MessageDigest` and introduce new `MessageDigest` algorithms 'SHAKE128-LEN` and `SHAKE256-LEN` with an integer parameter.

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

  useless imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16660/files
  - new: https://git.openjdk.org/jdk/pull/16660/files/711d6cae..0e80dea0

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

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

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


From jwaters at openjdk.org  Wed Nov 22 06:29:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Nov 2023 06:29:05 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
Message-ID: <0AVfU1tSqtOESB6zeQIG1x_OgpmijgNKhptfHh-TcDo=.541914fd-bf4e-407e-9f40-01973efca8c9@github.com>

On Thu, 16 Nov 2023 04:40:53 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NULL to nullptr in sspi.cpp

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1822184655


From mdonovan at openjdk.org  Wed Nov 22 13:04:20 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 22 Nov 2023 13:04:20 GMT
Subject: Integrated: 8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6
 and newer
In-Reply-To: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
References: <MA_jYMvigNNLo_PdXFfIHx8bjCWxveTX5zKcFHUftIo=.14283706-6955-4557-955f-8741acaf2dec@github.com>
Message-ID: <-l7DsV-PQo4hwOBsNCQeZd6Ibk56IKHRojPo18FzAa0=.35cff018-09d8-4aec-bb93-56fcacb34d53@github.com>

On Fri, 20 Oct 2023 19:18:47 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> Hello,
> 
> In this PR I removed NSS tests from the ProblemList and updated NssTest to use Sqlite databases. I also removed code in PKCS11Test.java that falls back to NSS libraries installed on the test system. The tests can still be run with different NSS libraries but they have to be specified by a system property. I updated `doc/testing.md` to reflect that change.
> 
> Thanks

This pull request has now been integrated.

Changeset: 6ce0ebb8
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ce0ebb858d3112f136e12d3ad595f805f6871a0
Stats:     121 lines in 7 files changed: 9 ins; 87 del; 25 mod

8295343: sun/security/pkcs11 tests fail on Linux RHEL 8.6 and newer

Reviewed-by: erikj, ihse, valeriep

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

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


From duke at openjdk.org  Wed Nov 22 22:26:08 2023
From: duke at openjdk.org (Yakov Shafranovich)
Date: Wed, 22 Nov 2023 22:26:08 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <DXJR3I2x9PeojuQ3QYQE-pZguDRQlCrg_eLvQaJIJwA=.a3ae7ebc-47c5-4e73-9dd6-6b07448b0832@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <DXJR3I2x9PeojuQ3QYQE-pZguDRQlCrg_eLvQaJIJwA=.a3ae7ebc-47c5-4e73-9dd6-6b07448b0832@github.com>
Message-ID: <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com>

On Tue, 14 Nov 2023 12:21:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed more line breaks
>>  - fixed line breaks
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 77:
> 
>> 75:  *
>> 76:  * Whenever possible, {@linkplain ZipFile} should be used for parsing ZIP
>> 77:  * archives since it correctly reads data from the central directory.
> 
> I think it's okay to extend the existing API note to say that the stream may contain ZIP file entries that are not are not named in the central directory.  I think I would replace the sentence "Additionally ..." with "Consequently, a ZipInputStream that reads from a ZIP file may read ZIP file entries that are not in the ZIP file's central directory". 
> 
> The sentence "This class might also fail to properly parse ZIP archives that have prepended data" will confuse readers as it hints of unreliability in scenarios and begs too many questions on where the data is prepended. So I think drop this unless you can come up with something better.
> 
> Replacing the sentence "ZipFile may be used ..." is okay but I don't think the proposed text works. The API note starts with text to say that a ZipInputStream doesn't read the CEN so saying "correctly reads from the central directory" is very confusing. ZipInputStream is a JDK 1.1 era API, it is what it is and would be disruptive to deprecate.

Thank you, I will work on this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1402764406


From ascarpino at openjdk.org  Thu Nov 23 01:11:26 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 23 Nov 2023 01:11:26 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
Message-ID: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>

Hi,

I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  

The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 

The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry

thanks

Tony

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

Commit messages:
 - set default keylength to cc20's
 - redo perf tests
 - cleanup some comments
 - Remove CC20 test after merge
 - Reduce testcases for GCM, middle set not necessary
 - combine buffer test
 - Mostly done
 - CC20 & GCM working
 - merge
 - initial and untested

Changes: https://git.openjdk.org/jdk/pull/16487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318756
  Stats: 2900 lines in 15 files changed: 1808 ins; 1050 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/16487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16487/head:pull/16487

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


From ascarpino at openjdk.org  Thu Nov 23 01:11:27 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 23 Nov 2023 01:11:27 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
Message-ID: <EMFt1KNdq3tI4ZyaGOyBAHzudYHKZdi0oXChROHUpqI=.4a1b06b2-1dec-4024-a906-31ec4d59285e@github.com>

On Fri, 3 Nov 2023 04:08:27 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  
> 
> The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 
> 
> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry
> 
> thanks
> 
> Tony

Noteworthy perf data (ops/sec)
<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:////Users/ascarpin/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm">
<link rel=File-List
href="file:////Users/ascarpin/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml">



</head>

<body link="#0563C1" vlink="#954F72">


Benchmark | dataMethod | dataSize | AEADBuffer | jdk-dev | ?Diff
-- | -- | -- | -- | -- | --
CC20P1305ByteBuffer.decrypt | direct | 1024 | 577804.81 | 549630.383 | 105.13%
CC20P1305ByteBuffer.decrypt | direct | 1500 | 424441.663 | 401452.037 | 105.73%
CC20P1305ByteBuffer.decrypt | direct | 4096 | 186333.196 | 152909.993 | 121.86%
CC20P1305ByteBuffer.decrypt | direct | 16384 | 49698.562 | 41966.387 | 118.42%
CC20P1305ByteBuffer.decrypt | heap | 1024 | 586145.31 | 514277.384 | 113.97%
CC20P1305ByteBuffer.decrypt | heap | 1500 | 429055.718 | 380859.773 | 112.65%
CC20P1305ByteBuffer.decrypt | heap | 4096 | 179807.069 | 179241.327 | 100.32%
CC20P1305ByteBuffer.decrypt | heap | 16384 | 51096.478 | 51097.68 | 100.00%
CC20P1305ByteBuffer.decryptMultiPart | direct | 1024 | 553804.884 | 506750.657 | 109.29%
CC20P1305ByteBuffer.decryptMultiPart | direct | 1500 | 399307.809 | 365691.011 | 109.19%
CC20P1305ByteBuffer.decryptMultiPart | direct | 4096 | 180940.646 | 165152.892 | 109.56%
CC20P1305ByteBuffer.decryptMultiPart | direct | 16384 | 49117.754 | 40808.57 | 120.36%
CC20P1305ByteBuffer.decryptMultiPart | heap | 1024 | 567976.828 | 539087.765 | 105.36%
CC20P1305ByteBuffer.decryptMultiPart | heap | 1500 | 415070.529 | 400061.343 | 103.75%
CC20P1305ByteBuffer.decryptMultiPart | heap | 4096 | 180878.684 | 178758.204 | 101.19%
CC20P1305ByteBuffer.decryptMultiPart | heap | 16384 | 48541.737 | 46645.72 | 104.06%
AESGCMByteBuffer.decrypt | heap | 1024 | 1826361.53 | 1796033.97 | 101.69%
AESGCMByteBuffer.decrypt | heap | 1500 | 1245406.42 | 1109318.44 | 112.27%
AESGCMByteBuffer.decrypt | heap | 4096 | 641359.437 | 617315.646 | 103.89%
AESGCMByteBuffer.decrypt | heap | 16384 | 247719.061 | 238448.044 | 103.89%
AESGCMByteBuffer.decryptMultiPart | direct | 1024 | 1574668.85 | 1483599.15 | 106.14%
AESGCMByteBuffer.decryptMultiPart | direct | 1500 | 1172906.6 | 1100561.62 | 106.57%
AESGCMByteBuffer.decryptMultiPart | direct | 4096 | 545868.754 | 513626.344 | 106.28%
AESGCMByteBuffer.decryptMultiPart | direct | 16384 | 170901.637 | 152173.375 | 112.31%
AESGCMByteBuffer.decryptMultiPart | heap | 1024 | 1889488.77 | 1759824.14 | 107.37%
AESGCMByteBuffer.decryptMultiPart | heap | 1500 | 1355897.08 | 1289243.83 | 105.17%
AESGCMByteBuffer.decryptMultiPart | heap | 4096 | 650425.638 | 622200.295 | 104.54%
AESGCMByteBuffer.decryptMultiPart | heap | 16384 | 235059.195 | 226745.378 | 103.67%

</body></html>

Memory reduction (bytes / op)
<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:////Users/ascarpin/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm">
<link rel=File-List
href="file:////Users/ascarpin/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml">

</head>

<body link="#0563C1" vlink="#954F72">

Benchmark | (dataMethod) | (dataSize) | AEADBuffer | jdk-dev | ?Reduction
-- | -- | -- | -- | -- | --
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | direct | 1024 | 3600.006 | 5704.006 | 36.89%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | direct | 1500 | 4080.008 | 6664.008 | 38.78%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | direct | 4096 | 6672.018 | 28280.022 | 76.41%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | direct | 16384 | 18960.069 | 102040.082 | 81.42%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | heap | 1024 | 2544.006 | 3608.007 | 29.49%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | heap | 1500 | 2544.008 | 3608.009 | 29.49%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | heap | 4096 | 2544.019 | 3608.019 | 29.49%
CC20P1305ByteBuffer.decrypt:gc.alloc.rate.norm | heap | 16384 | 2544.068 | 3608.068 | 29.49%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 1024 | 3688.006 | 9352.007 | 60.56%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 1500 | 4168.009 | 11032.009 | 62.22%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 4096 | 6760.019 | 24232.021 | 72.10%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 16384 | 19048.07 | 114344.084 | 83.34%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 1024 | 4200.006 | 6728.006 | 37.57%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 1500 | 4920.008 | 7208.008 | 31.74%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 4096 | 8808.019 | 13928.019 | 36.76%
CC20P1305ByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 16384 | 27240.071 | 44648.074 | 38.99%
CC20P1305Bench.decrypt:gc.alloc.rate.norm | ? | 1024 | 2544.006 | 3608.007 | 29.49%
CC20P1305Bench.decrypt:gc.alloc.rate.norm | ? | 1500 | 2544.008 | 3608.009 | 29.49%
CC20P1305Bench.decrypt:gc.alloc.rate.norm | ? | 4096 | 2544.02 | 3608.019 | 29.49%
CC20P1305Bench.decrypt:gc.alloc.rate.norm | ? | 16384 | 2544.067 | 3608.068 | 29.49%
CC20P1305Bench.decryptMultiPart:gc.alloc.rate.norm | ? | 1024 | 4200.006 | 6728.006 | 37.57%
CC20P1305Bench.decryptMultiPart:gc.alloc.rate.norm | ? | 1500 | 4920.008 | 7208.008 | 31.74%
CC20P1305Bench.decryptMultiPart:gc.alloc.rate.norm | ? | 4096 | 8808.019 | 13928.019 | 36.76%
CC20P1305Bench.decryptMultiPart:gc.alloc.rate.norm | ? | 16384 | 27240.07 | 44648.073 | 38.99%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 1024 | 3240.002 | 4248.002 | 23.73%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 1500 | 4344.003 | 5832.003 | 25.51%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 4096 | 6312.006 | 10392.007 | 39.26%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | direct | 16384 | 41704.021 | 58072.023 | 28.19%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 1024 | 1704.002 | 2184.002 | 21.98%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 1500 | 2040.003 | 2760.003 | 26.09%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 4096 | 3240.005 | 5256.006 | 38.36%
AESGCMByteBuffer.decryptMultiPart:gc.alloc.rate.norm | heap | 16384 | 9328.015 | 17488.016 | 46.66%
AESGCMBench.decryptMultiPart:gc.alloc.rate.norm | ? | 1024 | 1736.002 | 2216.002 | 21.66%
AESGCMBench.decryptMultiPart:gc.alloc.rate.norm | ? | 1500 | 2016.002 | 2848.002 | 29.21%
AESGCMBench.decryptMultiPart:gc.alloc.rate.norm | ? | 4096 | 3272.005 | 5288.005 | 38.12%
AESGCMBench.decryptMultiPart:gc.alloc.rate.norm | ? | 16384 | 9304.014 | 17464.015 | 46.72%

</body>

</html>

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

PR Comment: https://git.openjdk.org/jdk/pull/16487#issuecomment-1823710452


From jjiang at openjdk.org  Thu Nov 23 09:06:05 2023
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 23 Nov 2023 09:06:05 GMT
Subject: RFR: 8320049: PKCS10 would not discard the cause when throw
 SignatureException on invalid key
In-Reply-To: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
References: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
Message-ID: <apbuN62GgkHsPp7wkR1W2lJ9UYB2HONNNghp6h7xIaw=.78677816-d529-4a9e-b3f2-ee520b74f41f@github.com>

On Tue, 14 Nov 2023 08:59:30 GMT, John Jiang <jjiang at openjdk.org> wrote:

> When throw SignatureException on invalid key, it may be better to contain the cause exception.

Could this patch be reviewed?

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

PR Comment: https://git.openjdk.org/jdk/pull/16649#issuecomment-1824025129


From djelinski at openjdk.org  Thu Nov 23 12:27:21 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Nov 2023 12:27:21 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
Message-ID: <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>

On Fri, 3 Nov 2023 04:08:27 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  
> 
> The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 
> 
> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry
> 
> thanks
> 
> Tony

Thanks for doing this! A few comments in line.

src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 45:

> 43:      * Create an instance with no buffer
> 44:      */
> 45:     public AEADBufferedStream() {

Never used. And once you remove it, `buf` is never null

src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 55:

> 53: 
> 54:     public AEADBufferedStream(int len) {
> 55:         buf = new byte[len];

Suggestion:

        super(len);

otherwise buf will be initialized twice, once here, once in the base class constructor

src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 56:

> 54:     public AEADBufferedStream(int len) {
> 55:         buf = new byte[len];
> 56:         count = 0;

no need to zero-initialize, it's zero by default

src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 67:

> 65:      */
> 66:     @Override
> 67:     public synchronized byte[] toByteArray() {

remove this `synchronized`; the new `write` methods are not synchronized, so this does not add value.

src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 68:

> 66:     @Override
> 67:     public synchronized byte[] toByteArray() {
> 68:         if (buf.length > count) {

Can this ever happen? And if it can, would it be better to return the whole buffer and have the caller extract the necessary range?

src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 94:

> 92:         } else {
> 93:             if (buf.length < (count + len)) {
> 94:                 buf = Arrays.copyOf(buf, count + len);

this will copy a lot if the user performs many small writes, for example when decrypting with CipherInputStream; see `AESGCMCipherOutputStream` benchmark.

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

> 697:      * @throws ShortBufferException if the buffer {@code out} does not have
> 698:      *      enough space to hold the resulting data.
> 699:      */    @Override

Suggestion:

     */
    @Override

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

> 790: 
> 791:     /*
> 792:      * Optimized version of bufferCrypt from CipherSpi.java.  Direct

Can you document the optimizations done in this function?

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

> 842:                         total = engine.doFinal(inArray, inOfs, inLen, outArray, outOfs);
> 843:                     }
> 844:                 } catch (BadPaddingException | KeyException e) {

Preexisting, and probably out of scope for this PR, but we should expose the "Counter exhausted" exception in javax.crypto.Cipher

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

> 1425:             input.get(in);
> 1426:             byte[] out = new byte[in.length];
> 1427:             doUpdate(in, 0, in.length, out, out.length);

Suggestion:

            byte[] out = in;
            doUpdate(in, 0, in.length, out, 0);

I guess we need more test coverage here

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

> 1503:             byte[] in = new byte[input.remaining()];
> 1504:             input.get(in);
> 1505:             byte[] out = new byte[in.length];

Suggestion:

            byte[] out = in;

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

> 1514:             input.get(in);
> 1515:             byte[] out = new byte[in.length + TAG_LENGTH];
> 1516:             doFinal(in, 0, in.length, out, 0);

A bit more complex, but you can avoid one allocation here too; something like (untested):
Suggestion:

            int inLen = input.remaining();
            byte[] out = new byte[inLen + TAG_LENGTH];
            byte[] in = out;
            input.get(in, 0, inLen);
            doFinal(in, 0, inLen, out, 0);

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

> 1650:             int ctLen = getBufferedLength() + inLen;
> 1651:             if (ctLen == 0) {
> 1652:                 throw new AEADBadTagException("Tag mismatch");

Suggestion:

            if (ctLen < TAG_LENGTH) {
                throw new AEADBadTagException("Input too short - need tag");

test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 43:

> 41:     AlgorithmParameterSpec getNewSpec() {
> 42:         iv_index = (iv_index + 1) % IV_MODULO;
> 43:         return new GCMParameterSpec(96, iv, iv_index, 12);

Can you also change tag length to 128 bits? TLS uses 128, and 128-bit tag generates a slightly different flamegraph.

test/micro/org/openjdk/bench/javax/crypto/full/AESGCMByteBuffer.java line 44:

> 42:     AlgorithmParameterSpec getNewSpec() {
> 43:         iv_index = (iv_index + 1) % IV_MODULO;
> 44:         return new GCMParameterSpec(96, iv, iv_index, 12);

Also use 128-bit tag here.

test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java line 122:

> 120:     public void decrypt() throws Exception {
> 121:         decryptCipher.init(Cipher.DECRYPT_MODE, ks,
> 122:             encryptCipher.getParameters().

Consider using a different method to obtain parameter spec here; the flamegraph suggests that `getParameters` is responsible for up to 20% of the time spent in these benchmarks

test/micro/org/openjdk/bench/javax/crypto/small/AESGCMBench.java line 48:

> 46:     AlgorithmParameterSpec getNewSpec() {
> 47:         iv_index = (iv_index + 1) % IV_MODULO;
> 48:         return new GCMParameterSpec(96, iv, iv_index, 12);

Also use 128-bit tag here.

test/micro/org/openjdk/bench/javax/crypto/small/AESGCMByteBuffer.java line 48:

> 46:     AlgorithmParameterSpec getNewSpec() {
> 47:         iv_index = (iv_index + 1) % IV_MODULO;
> 48:         return new GCMParameterSpec(96, iv, iv_index, 12);

Also use 128-bit tag here.

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

Changes requested by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16487#pullrequestreview-1746152716
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403191252
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403308026
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403191602
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403193417
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403194450
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403196426
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403196854
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403224371
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403205814
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403238862
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403239235
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403244203
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403252213
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403271442
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403271853
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403303743
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403274634
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1403274860


From weijun at openjdk.org  Sat Nov 25 01:17:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 25 Nov 2023 01:17:30 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v4]
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <S5AWVEoC_Qh4sfSQKDX0_x7bf8Bb8qbdkxqryjEzF54=.3ee43214-210b-4ad1-9ab1-b61d9979a9fd@github.com>

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

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

  explain hashAlgFromHSS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14254/files
  - new: https://git.openjdk.org/jdk/pull/14254/files/ff150140..04a7a0b7

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

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

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


From weijun at openjdk.org  Mon Nov 27 14:09:42 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Nov 2023 14:09:42 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v5]
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <YApT0Ou-LqDpEAUSsLmUc2HCXfUbRWYaS9WKuQSgXm8=.86f0f0df-375c-4cf3-8015-14e122de3354@github.com>

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

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

  no need to talk about the limitation here

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14254/files
  - new: https://git.openjdk.org/jdk/pull/14254/files/04a7a0b7..fae4757a

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

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

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


From mdonovan at openjdk.org  Mon Nov 27 14:47:29 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 27 Nov 2023 14:47:29 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v2]
In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
Message-ID: <p0yT8Z9tiM3vmilig8s11iLXbpjX1UJihr7Lw0COgwU=.36de9641-3e55-4106-acba-9bdb88427668@github.com>

> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.

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

 - cleaned up MultipleLogins.java a little and added copyright date
 - Merge branch 'master' into pkcs11-ol79
 - Merge branch 'master' into pkcs11-ol79
 - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16547/files
  - new: https://git.openjdk.org/jdk/pull/16547/files/77eb3897..b20b8e3a

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

  Stats: 644321 lines in 1751 files changed: 98319 ins; 480546 del; 65456 mod
  Patch: https://git.openjdk.org/jdk/pull/16547.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16547/head:pull/16547

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


From mullan at openjdk.org  Mon Nov 27 18:51:09 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 27 Nov 2023 18:51:09 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v5]
In-Reply-To: <YApT0Ou-LqDpEAUSsLmUc2HCXfUbRWYaS9WKuQSgXm8=.86f0f0df-375c-4cf3-8015-14e122de3354@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <YApT0Ou-LqDpEAUSsLmUc2HCXfUbRWYaS9WKuQSgXm8=.86f0f0df-375c-4cf3-8015-14e122de3354@github.com>
Message-ID: <cQndY1tmnOt7tm5Q7rJzWjlGLw735FvBB0k4YoydMUo=.c4c4742a-d591-481d-bd06-4b32b5fc8720@github.com>

On Mon, 27 Nov 2023 14:09:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Code changes for HSS/LMS that's related to keytool and jarsigner:
>> 
>> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
>> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
>> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to talk about the limitation here

Looks good - one minor comment. However, I still would like @ferakocz to review the `KeyUtil.hashAlgFromHSS` method.

src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java line 190:

> 188:      * signature verification process actually does not require the
> 189:      * extension matches the key algorithm as long as it's one of
> 190:      * "RSA", "DSA", and "EC".

Some minor wording suggestions on second sentence: "This is safe because the signature verification process does not require the extension to match the key algorithm as long as it is "RSA", "DSA", or "EC."

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14254#pullrequestreview-1751025651
PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1406532964


From weijun at openjdk.org  Mon Nov 27 20:21:33 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Nov 2023 20:21:33 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v6]
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <LIl3wR28LxPV9BJz3uv1jnlvFBgzHb8RA-77PtPnXM4=.ba849064-fe7b-428c-a65e-9e0c6405d3b0@github.com>

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

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

  reword comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14254/files
  - new: https://git.openjdk.org/jdk/pull/14254/files/fae4757a..fd5473b4

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

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

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


From duke at openjdk.org  Mon Nov 27 21:51:21 2023
From: duke at openjdk.org (Ben Perez)
Date: Mon, 27 Nov 2023 21:51:21 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers
Message-ID: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>

Updated `X509CertSelector.java` and `SerialNumber.java` to use same debug printing format for X.509 serial numbers. The format in `SSLLogger.java` is slightly different but now uses the `toString` method in `SerialNumber.java` for better readability.

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8296787
 - Changed SSLLogger to print x509 serial number using toString method in SerialNumber.java
 - Standardized x509 serial number format for X509CertSelector and SerialNumber

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

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


From ascarpino at openjdk.org  Tue Nov 28 01:34:17 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 28 Nov 2023 01:34:17 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
 <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
Message-ID: <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>

On Thu, 23 Nov 2023 10:30:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  
>> 
>> The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 
>> 
>> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry
>> 
>> thanks
>> 
>> Tony
>
> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 45:
> 
>> 43:      * Create an instance with no buffer
>> 44:      */
>> 45:     public AEADBufferedStream() {
> 
> Never used. And once you remove it, `buf` is never null

Sure

> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 55:
> 
>> 53: 
>> 54:     public AEADBufferedStream(int len) {
>> 55:         buf = new byte[len];
> 
> Suggestion:
> 
>         super(len);
> 
> otherwise buf will be initialized twice, once here, once in the base class constructor

Yeah.. better memory performance too.

> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 56:
> 
>> 54:     public AEADBufferedStream(int len) {
>> 55:         buf = new byte[len];
>> 56:         count = 0;
> 
> no need to zero-initialize, it's zero by default

Yes

> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 67:
> 
>> 65:      */
>> 66:     @Override
>> 67:     public synchronized byte[] toByteArray() {
> 
> remove this `synchronized`; the new `write` methods are not synchronized, so this does not add value.

Interesting, I thought I was stuck with `synchronized` from the parent

> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 68:
> 
>> 66:     @Override
>> 67:     public synchronized byte[] toByteArray() {
>> 68:         if (buf.length > count) {
> 
> Can this ever happen? And if it can, would it be better to return the whole buffer and have the caller extract the necessary range?

Yes, because it can reuse the allocated buffer during encryption scenarios when multi-part ops send non-block size data.  For decryption, it should never happen.

> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 94:
> 
>> 92:         } else {
>> 93:             if (buf.length < (count + len)) {
>> 94:                 buf = Arrays.copyOf(buf, count + len);
> 
> this will copy a lot if the user performs many small writes, for example when decrypting with CipherInputStream; see `AESGCMCipherOutputStream` benchmark.

As I understand the `ByteArrayOutputStream` code, the `ArraysSupport.newLength()` will double the allocation each time.  So if the buffer is 1k size and it wants to add one more byte, the method will allocate 2k.
I agree that in my change, if you send one byte at a time, it will be doing a lot of allocating.  But I don't believe that is the general case.  If you have examples of apps doing small allocations, let me know and I can come up with a different scheme.  But at this point I thought it was a bitter risk more allocations in the less-likely situation, than unused allocation in what I see as a more common case.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 699:
> 
>> 697:      * @throws ShortBufferException if the buffer {@code out} does not have
>> 698:      *      enough space to hold the resulting data.
>> 699:      */    @Override
> 
> Suggestion:
> 
>      */
>     @Override

Yep

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 792:
> 
>> 790: 
>> 791:     /*
>> 792:      * Optimized version of bufferCrypt from CipherSpi.java.  Direct
> 
> Can you document the optimizations done in this function?

The second sentence says what the optimizations is.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 844:
> 
>> 842:                         total = engine.doFinal(inArray, inOfs, inLen, outArray, outOfs);
>> 843:                     }
>> 844:                 } catch (BadPaddingException | KeyException e) {
> 
> Preexisting, and probably out of scope for this PR, but we should expose the "Counter exhausted" exception in javax.crypto.Cipher; filed [JDK-8320743](https://bugs.openjdk.org/browse/JDK-8320743) for that

Certainly out of scope here.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 1427:
> 
>> 1425:             input.get(in);
>> 1426:             byte[] out = new byte[in.length];
>> 1427:             doUpdate(in, 0, in.length, out, out.length);
> 
> Suggestion:
> 
>             byte[] out = in;
>             doUpdate(in, 0, in.length, out, 0);
> 
> I guess we need more test coverage here

I don't see a testing issue there, but that's better memory usage.  I probably copied this code over from AES/GCM where it's blocksized data and `in` and `out` could have been different sizes.  But CC20 can use this optimization because it's a streaming cipher.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 1505:
> 
>> 1503:             byte[] in = new byte[input.remaining()];
>> 1504:             input.get(in);
>> 1505:             byte[] out = new byte[in.length];
> 
> Suggestion:
> 
>             byte[] out = in;

yep

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 1516:
> 
>> 1514:             input.get(in);
>> 1515:             byte[] out = new byte[in.length + TAG_LENGTH];
>> 1516:             doFinal(in, 0, in.length, out, 0);
> 
> A bit more complex, but you can avoid one allocation here too; something like (untested):
> Suggestion:
> 
>             int inLen = input.remaining();
>             byte[] out = new byte[inLen + TAG_LENGTH];
>             byte[] in = out;
>             input.get(in, 0, inLen);
>             doFinal(in, 0, inLen, out, 0);

I will have to check on this, I've run into `BufferUnderflowException` too many times with ByteBuffer to say for sure at this point.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 1652:
> 
>> 1650:             int ctLen = getBufferedLength() + inLen;
>> 1651:             if (ctLen == 0) {
>> 1652:                 throw new AEADBadTagException("Tag mismatch");
> 
> Suggestion:
> 
>             if (ctLen < TAG_LENGTH) {
>                 throw new AEADBadTagException("Input too short - need tag");

Yep

> test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 43:
> 
>> 41:     AlgorithmParameterSpec getNewSpec() {
>> 42:         iv_index = (iv_index + 1) % IV_MODULO;
>> 43:         return new GCMParameterSpec(96, iv, iv_index, 12);
> 
> Can you also change tag length to 128 bits? TLS uses 128, and 128-bit tag generates a slightly different flamegraph.

I'll see if I can do it cleanly. GCM spec defaults to 96bit and because CC20P1305 requires 96bit, it made the common code easier. I'm surprised you any differences which such a minor change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946509
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946538
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406968884
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946567
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946612
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946637
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946687
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946735
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406946776
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406947706
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406947296
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406953636
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406968978
PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1406968180


From djelinski at openjdk.org  Tue Nov 28 07:28:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 28 Nov 2023 07:28:10 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
 <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
 <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>
Message-ID: <lR8h_LR4nbn0fs1dY6fItLmrm3mCkT-KC1Q9CkxWqNA=.e2295b81-daf7-4bcc-8086-3ddd5c8da85c@github.com>

On Tue, 28 Nov 2023 00:51:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 1427:
>> 
>>> 1425:             input.get(in);
>>> 1426:             byte[] out = new byte[in.length];
>>> 1427:             doUpdate(in, 0, in.length, out, out.length);
>> 
>> Suggestion:
>> 
>>             byte[] out = in;
>>             doUpdate(in, 0, in.length, out, 0);
>> 
>> I guess we need more test coverage here
>
> I don't see a testing issue there, but that's better memory usage.  I probably copied this code over from AES/GCM where it's blocksized data and `in` and `out` could have been different sizes.  But CC20 can use this optimization because it's a streaming cipher.

I was talking about the second line:

doUpdate(in, 0, in.length, out, out.length);

this tells the doUpdate operation to start writing to `out` at `out.length`; that should have triggered an exception in testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1407327505


From djelinski at openjdk.org  Tue Nov 28 08:26:07 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 28 Nov 2023 08:26:07 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
 <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
 <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>
Message-ID: <yZVgr3W9E8_7ZzfJi_yCKBY8gIC-ejSiuV-68LT3oUM=.8dc89be0-4e32-415b-a153-68c959bf3bab@github.com>

On Tue, 28 Nov 2023 01:29:20 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 43:
>> 
>>> 41:     AlgorithmParameterSpec getNewSpec() {
>>> 42:         iv_index = (iv_index + 1) % IV_MODULO;
>>> 43:         return new GCMParameterSpec(96, iv, iv_index, 12);
>> 
>> Can you also change tag length to 128 bits? TLS uses 128, and 128-bit tag generates a slightly different flamegraph.
>
> I'll see if I can do it cleanly. GCM spec defaults to 96bit and because CC20P1305 requires 96bit, it made the common code easier. I'm surprised you any differences which such a minor change.

FWIW, here's the relevant part of the flamegraphs:
![image](https://github.com/openjdk/jdk/assets/30433125/3a37921b-55d8-4f04-9d70-1b7b4ff9b7e2)
As you can see, the 128-bit tag is using a different intrinsic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1407383930


From djelinski at openjdk.org  Tue Nov 28 08:43:07 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 28 Nov 2023 08:43:07 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
 <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
 <AxisVvU_JwBd0off_YRRae4il4TkmVsm5kw9Fq0JsxE=.e0461875-fb1d-4b25-932f-7feb34686f93@github.com>
Message-ID: <1UBq7CzhzKPLUPMakJ_ZnqQ_crpIyvfFoY9l1muFwS0=.ae895afb-e618-4c24-9001-68b0a01043a7@github.com>

On Tue, 28 Nov 2023 00:49:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 792:
>> 
>>> 790: 
>>> 791:     /*
>>> 792:      * Optimized version of bufferCrypt from CipherSpi.java.  Direct
>> 
>> Can you document the optimizations done in this function?
>
> The second sentence says what the optimizations is.

well I was under the impression that the bulk of the optimization comes from using modified `engineGetOutputSize` that does not allocate when isUpdate== true and decrypting. That's not documented anywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1407396658


From djelinski at openjdk.org  Tue Nov 28 08:43:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 28 Nov 2023 08:43:10 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
Message-ID: <4zYlNPZjxnquW5MvQbYuOjbx7r1I8eIdReNbtL0YeQw=.78cd7b9f-5a90-4bf8-b2f1-9c8373a7af07@github.com>

On Fri, 3 Nov 2023 04:08:27 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  
> 
> The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 
> 
> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry
> 
> thanks
> 
> Tony

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

> 857:                     try {
> 858:                         outArray = engineDoFinal(inArray, inOfs, inLen);
> 859:                     } catch (BadPaddingException e) {

Should we really be hiding the `BadPaddingException` here and in other places in this method? `AEADBadTagException` extends `BadPaddingException`, and I'm pretty sure we don't want to hide it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1407397841


From coffeys at openjdk.org  Tue Nov 28 10:56:08 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 28 Nov 2023 10:56:08 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers
In-Reply-To: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
Message-ID: <z0fguY86724Axnw_A6S3bbugXRR5OaB2okDlhs8TizA=.d76f527f-5460-439d-9ab6-3cf5853b564e@github.com>

On Mon, 27 Nov 2023 21:45:23 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated `X509CertSelector.java` and `SerialNumber.java` to use same debug printing format for X.509 serial numbers. The format in `SSLLogger.java` is slightly different but now uses the `toString` method in `SerialNumber.java` for better readability.

for clarity - can you include before and after examples of the serial numbers printed from each change ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16834#issuecomment-1829576106


From mdonovan at openjdk.org  Tue Nov 28 13:47:22 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Nov 2023 13:47:22 GMT
Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
 [v2]
In-Reply-To: <p0yT8Z9tiM3vmilig8s11iLXbpjX1UJihr7Lw0COgwU=.36de9641-3e55-4106-acba-9bdb88427668@github.com>
References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com>
 <p0yT8Z9tiM3vmilig8s11iLXbpjX1UJihr7Lw0COgwU=.36de9641-3e55-4106-acba-9bdb88427668@github.com>
Message-ID: <4VAssOgAXpYTtBiw3Q2Ysfyi6P6QnSn23eix3eJNn9s=.9cb05a0c-d487-4b27-bb34-e10d84631c8b@github.com>

On Mon, 27 Nov 2023 14:47:29 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I included logic to skip tests on Oracle Linux prior to version 8.  The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9.
>
> 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 four additional commits since the last revision:
> 
>  - cleaned up MultipleLogins.java a little and added copyright date
>  - Merge branch 'master' into pkcs11-ol79
>  - Merge branch 'master' into pkcs11-ol79
>  - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

Hello, I'm looking for a reviewer for this PR. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16547#issuecomment-1829875245


From mullan at openjdk.org  Tue Nov 28 13:53:49 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Nov 2023 13:53:49 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers
In-Reply-To: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
Message-ID: <aDFnWtzCeY-QHRxftM6ufnlME5MnGNXejgCGas2qBQc=.3510b7de-e393-4e38-8442-6ce9db00d16f@github.com>

On Mon, 27 Nov 2023 21:45:23 GMT, Ben Perez <duke at openjdk.org> wrote:

> Updated `X509CertSelector.java` and `SerialNumber.java` to use same debug printing format for X.509 serial numbers. The format in `SSLLogger.java` is slightly different but now uses the `toString` method in `SerialNumber.java` for better readability.

I would like us to use a consistent hex format where each byte is separated by a ":", so for example:

08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A

This is easier to visually parse and is a common format used by other X.509 certificate display tools.

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

PR Comment: https://git.openjdk.org/jdk/pull/16834#issuecomment-1829887459


From sean.mullan at oracle.com  Tue Nov 28 15:52:14 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 28 Nov 2023 15:52:14 +0000
Subject: JVM security properties warning
In-Reply-To: <ADAAA300-B5FF-47BC-985F-CCFCBE99E333@Amazon.com>
References: <ADAAA300-B5FF-47BC-985F-CCFCBE99E333@Amazon.com>
Message-ID: <EDCF0170-DDB2-450A-9680-930687D38F85@oracle.com>

This should be discussed on the security-dev list, so let?s discuss and followup there. Bcc-ing idk-dev.

?Sean

On Nov 27, 2023, at 5:30 PM, Capasso, Autumn <autumcap at amazon.com<mailto:autumcap at amazon.com>> wrote:


Hi my name is Autumn Capasso, I am an Software engineer for the Amazon Corretto team. I am purposing to a mechanism to warn developers about misconfigure Security properties by mistaking them for system properties. We have found that customers are often confused by security properties they think are System properties. Developers think their changing a System property and not only do they not get their desired effect. I created a JBS issues that I have included in this email.
https://bugs.openjdk.org/browse/JDK-8320559


Thank you,
Autumn Capasso

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

From autumcap at amazon.com  Tue Nov 28 19:23:38 2023
From: autumcap at amazon.com (Capasso, Autumn)
Date: Tue, 28 Nov 2023 19:23:38 +0000
Subject: JVM security properties warning 
Message-ID: <A77E58DA-1789-4CA2-B815-AC558B0D200E@contoso.com>


Hi my name is Autumn Capasso, I am an Software engineer for the Amazon Corretto team. I am purposing to a mechanism to warn developers about misconfigure Security properties by mistaking them for system properties. We have found that customers are often confused by security properties they think are System properties. Developers think their changing a System property and not only do they not get their desired effect. I created a JBS issues that I have included in this email.
https://bugs.openjdk.org/browse/JDK-8320559


Thank you,
Autumn Capasso


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231128/14cd2bef/attachment.htm>

From duke at openjdk.org  Tue Nov 28 20:07:22 2023
From: duke at openjdk.org (Ben Perez)
Date: Tue, 28 Nov 2023 20:07:22 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers [v2]
In-Reply-To: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
Message-ID: <3sAziknaQhHAeXjffDhefTTPpFtsAlO0i3p68ygxkFg=.8e07bc0c-c7a4-45c8-8afb-03a4516897ee@github.com>

> Updated `X509CertSelector.java` and `SerialNumber.java` to use same debug printing format for X.509 serial numbers. The format in `SSLLogger.java` is slightly different but now uses the `toString` method in `SerialNumber.java` for better readability.

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

  Changed serial number debug format to separate bytes with a colon

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16834/files
  - new: https://git.openjdk.org/jdk/pull/16834/files/0d5550ef..fc6ebd21

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

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

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


From ascarpino at openjdk.org  Tue Nov 28 20:33:10 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 28 Nov 2023 20:33:10 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
 <lEavu39-N91qlDBkzXjjv_S66N67QXt-nPSHIReeRG4=.bd3c5d69-29cc-4c08-9f28-62d4be16b3c0@github.com>
Message-ID: <MS1W25tHmjhwXiOk7DKfpqbbgy8Ig-R0FvAhhlu6Xtk=.bd0c9679-522e-4b58-a66c-d8dad3b79226@github.com>

On Thu, 23 Nov 2023 12:13:45 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  
>> 
>> The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 
>> 
>> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry
>> 
>> thanks
>> 
>> Tony
>
> test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java line 122:
> 
>> 120:     public void decrypt() throws Exception {
>> 121:         decryptCipher.init(Cipher.DECRYPT_MODE, ks,
>> 122:             encryptCipher.getParameters().
> 
> Consider using a different method to obtain parameter spec here; the flamegraph suggests that `getParameters` is responsible for up to 20% of the time spent in these benchmarks

Thanks for point that out.  I have decided to leave this as is.  There are optimizations that can be made to `getParameters` that I would like the benchmark to measure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1408383879


From mullan at openjdk.org  Tue Nov 28 21:07:05 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Nov 2023 21:07:05 GMT
Subject: RFR: 8320049: PKCS10 would not discard the cause when throw
 SignatureException on invalid key
In-Reply-To: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
References: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
Message-ID: <_NHpvUuHL-Iv2d_o6ln5fezA-l51V0w02Dcvhu_uhcY=.d0512f40-d7d5-405c-87ae-8303314e97e3@github.com>

On Tue, 14 Nov 2023 08:59:30 GMT, John Jiang <jjiang at openjdk.org> wrote:

> When throw SignatureException on invalid key, it may be better to contain the cause exception.

Looks fine to me, although I view this more as an Enhancement than a Bug.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16649#pullrequestreview-1753939304


From sean.mullan at oracle.com  Tue Nov 28 21:21:25 2023
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 28 Nov 2023 21:21:25 +0000
Subject: JVM security properties warning
In-Reply-To: <A77E58DA-1789-4CA2-B815-AC558B0D200E@contoso.com>
References: <A77E58DA-1789-4CA2-B815-AC558B0D200E@contoso.com>
Message-ID: <6E8F775E-C8FE-43C5-B6CB-818024FEC82A@oracle.com>

Thanks for your post about this topic. A comment was added to the bug report and I also agree with the concerns raised there. I don?t think it can be implemented as expected for the reasons in that comment. Also, warnings emitted to stderr are not done lightly and are typically only done for very significant reasons, such as use of a prominent deprecated API that is to be eventually removed. The best solution to this is to ensure that you have adequate tests to check that the property settings are enforced or configured as expected.

?Sean

On Nov 28, 2023, at 2:23 PM, Capasso, Autumn <autumcap at amazon.com<mailto:autumcap at amazon.com>> wrote:


Hi my name is Autumn Capasso, I am an Software engineer for the Amazon Corretto team. I am purposing to a mechanism to warn developers about misconfigure Security properties by mistaking them for system properties. We have found that customers are often confused by security properties they think are System properties. Developers think their changing a System property and not only do they not get their desired effect. I created a JBS issues that I have included in this email.
https://bugs.openjdk.org/browse/JDK-8320559


Thank you,
Autumn Capasso

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231128/67bf0de1/attachment.htm>

From mbalao at openjdk.org  Tue Nov 28 22:21:40 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 28 Nov 2023 22:21:40 GMT
Subject: RFR: 8315487: Security Providers Filter [v2]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <0QDh7oONGo90Kx11J-jlUsgq12JJ6SP989qvpdVN6jc=.7371792b-26e6-4270-9668-aa3ef7f608a8@github.com>

> 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...

Martin Balao 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 one additional commit since the last revision:

  8315487: Security Providers Filter
  
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/9b9350b9..ef6eafcf

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

  Stats: 853008 lines in 6797 files changed: 202450 ins; 527667 del; 122891 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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


From jjiang at openjdk.org  Tue Nov 28 23:55:16 2023
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 28 Nov 2023 23:55:16 GMT
Subject: RFR: 8320049: PKCS10 would not discard the cause when throw
 SignatureException on invalid key
In-Reply-To: <_NHpvUuHL-Iv2d_o6ln5fezA-l51V0w02Dcvhu_uhcY=.d0512f40-d7d5-405c-87ae-8303314e97e3@github.com>
References: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
 <_NHpvUuHL-Iv2d_o6ln5fezA-l51V0w02Dcvhu_uhcY=.d0512f40-d7d5-405c-87ae-8303314e97e3@github.com>
Message-ID: <6fN54BLWbQoc9MfBHvte5JzataG_lTa5ED_1OH2z-EM=.4398072a-0838-4b66-b4a4-d7f0d909d089@github.com>

On Tue, 28 Nov 2023 21:04:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> When throw SignatureException on invalid key, it may be better to contain the cause exception.
>
> Looks fine to me, although I view this more as an Enhancement than a Bug.

@seanjmullan 
Thanks for your review!

I just switched the JBS type to `Enhancement`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16649#issuecomment-1830960603


From jjiang at openjdk.org  Tue Nov 28 23:55:18 2023
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 28 Nov 2023 23:55:18 GMT
Subject: Integrated: 8320049: PKCS10 would not discard the cause when throw
 SignatureException on invalid key
In-Reply-To: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
References: <mdj0ll0Pcn00H7ngOWH0Tzb7ZQkRTK-a5SXCFEmx89I=.7c0884b2-8d8d-467a-bd16-910d9410363f@github.com>
Message-ID: <VyuqmdHvlpVxzfN0Xoq_qc1Jyon5vYJEBRjfxSr3ghc=.767ed5cb-36b9-41fe-ad8f-8ec9869e70fb@github.com>

On Tue, 14 Nov 2023 08:59:30 GMT, John Jiang <jjiang at openjdk.org> wrote:

> When throw SignatureException on invalid key, it may be better to contain the cause exception.

This pull request has now been integrated.

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

8320049: PKCS10 would not discard the cause when throw SignatureException on invalid key

Reviewed-by: mullan

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

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


From mullan at openjdk.org  Wed Nov 29 17:39:04 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 29 Nov 2023 17:39:04 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers
In-Reply-To: <z0fguY86724Axnw_A6S3bbugXRR5OaB2okDlhs8TizA=.d76f527f-5460-439d-9ab6-3cf5853b564e@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
 <z0fguY86724Axnw_A6S3bbugXRR5OaB2okDlhs8TizA=.d76f527f-5460-439d-9ab6-3cf5853b564e@github.com>
Message-ID: <6JfQAK6-0CPFrbzl_gbH1tAtCWBSBw57yb-5QV7hqZY=.082ca426-4288-4b13-bb67-cf6b003241e9@github.com>

On Tue, 28 Nov 2023 10:53:51 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> for clarity - can you include before and after examples of the serial numbers printed from each change ?

Yes, I think that would be useful. Also you will need to add a `noreg` label to the bug since you are not including a test (which I think is ok).

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

PR Comment: https://git.openjdk.org/jdk/pull/16834#issuecomment-1832399793


From mullan at openjdk.org  Wed Nov 29 17:44:03 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 29 Nov 2023 17:44:03 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers [v2]
In-Reply-To: <3sAziknaQhHAeXjffDhefTTPpFtsAlO0i3p68ygxkFg=.8e07bc0c-c7a4-45c8-8afb-03a4516897ee@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
 <3sAziknaQhHAeXjffDhefTTPpFtsAlO0i3p68ygxkFg=.8e07bc0c-c7a4-45c8-8afb-03a4516897ee@github.com>
Message-ID: <Ctjt8mlcNM23FK75ghYdgqgDZ5QW5PATh3lpFWUBBac=.c46b5a06-67bc-49ab-9318-82fc8116a582@github.com>

On Tue, 28 Nov 2023 20:07:22 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Updated `X509CertSelector.java` and `SerialNumber.java` to use same debug printing format for X.509 serial numbers. The format in `SSLLogger.java` is slightly different but now uses the `toString` method in `SerialNumber.java` for better readability.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed serial number debug format to separate bytes with a colon

Changes requested by mullan (Reviewer).

src/java.base/share/classes/sun/security/x509/SerialNumber.java line 104:

> 102:      */
> 103:     public String toString() { return "Serial number: " +
> 104:         serialNum.toString(16).toUpperCase().replaceAll("(?<=..)(..)", ":$1"); }

I am not sure that `replaceAll` expression is correct. When I tried it for `BigInteger("74984748")`, it emitted "47:82:d2c" when I think it should be "04:78:2D:2C". I would use the HexFormat class here (and in `X509CertSelector`), ex:

`HexFormat.ofDelimiter(":").withUpperCase().formatHex(xcert.getSerialNumber().toByteArray())`

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

PR Review: https://git.openjdk.org/jdk/pull/16834#pullrequestreview-1755850406
PR Review Comment: https://git.openjdk.org/jdk/pull/16834#discussion_r1409645221


From duke at openjdk.org  Wed Nov 29 19:12:20 2023
From: duke at openjdk.org (Ben Perez)
Date: Wed, 29 Nov 2023 19:12:20 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers [v3]
In-Reply-To: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
Message-ID: <-UjzRBob5dV1q-oyM4SBPRFN9tupVjjQVL1l4pf3Qzg=.e14e71ff-7ff2-4a4b-a68d-1bec257fbb1e@github.com>

> Updated `X509CertSelector.java` and `SerialNumber.java` to use same debug printing format for X.509 serial numbers. The format in `SSLLogger.java` is slightly different but now uses the `toString` method in `SerialNumber.java` for better readability.

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

  Changed serial number formatting method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16834/files
  - new: https://git.openjdk.org/jdk/pull/16834/files/fc6ebd21..1783ea3a

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

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

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


From ascarpino at openjdk.org  Wed Nov 29 19:47:11 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 29 Nov 2023 19:47:11 GMT
Subject: RFR: 8318756  Create better internal buffer for AEADs
In-Reply-To: <4zYlNPZjxnquW5MvQbYuOjbx7r1I8eIdReNbtL0YeQw=.78cd7b9f-5a90-4bf8-b2f1-9c8373a7af07@github.com>
References: <oG_arPQo7wTm0OvpgYpf2_F1uPJ3sIKIKHJuUVxZq1k=.804113f3-0633-4673-88dd-dd89dd267f0b@github.com>
 <4zYlNPZjxnquW5MvQbYuOjbx7r1I8eIdReNbtL0YeQw=.78cd7b9f-5a90-4bf8-b2f1-9c8373a7af07@github.com>
Message-ID: <I4G5IHM3T6v60Vn7uB6ypAghgmLAZlpv63PUzcJOvTE=.0048c8f4-376e-49fc-a6a4-12a0f60dbddf@github.com>

On Tue, 28 Nov 2023 08:35:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for a new internal buffer class called AEADBufferStream.  AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need.  
>> 
>> The changes greatest benefit is with decryption operations.  ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. 
>> 
>> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM.  16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305.  These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry
>> 
>> thanks
>> 
>> Tony
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 859:
> 
>> 857:                     try {
>> 858:                         outArray = engineDoFinal(inArray, inOfs, inLen);
>> 859:                     } catch (BadPaddingException e) {
> 
> Should we really be hiding the `BadPaddingException` here and in other places in this method? `AEADBadTagException` extends `BadPaddingException`, and I'm pretty sure we don't want to hide it.

CipherSpi:engineUpdate() only throws ShortBufferException.  That forces many exceptions into a ProviderException with extends RuntimeException.  The BadPaddingException doesn't matter because CC20 doesn't have padding.  AEADTagException should be specified and thrown, not wrapped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1409787566


From mullan at openjdk.org  Wed Nov 29 20:54:06 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 29 Nov 2023 20:54:06 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers [v3]
In-Reply-To: <-UjzRBob5dV1q-oyM4SBPRFN9tupVjjQVL1l4pf3Qzg=.e14e71ff-7ff2-4a4b-a68d-1bec257fbb1e@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
 <-UjzRBob5dV1q-oyM4SBPRFN9tupVjjQVL1l4pf3Qzg=.e14e71ff-7ff2-4a4b-a68d-1bec257fbb1e@github.com>
Message-ID: <yBnCdNGyBvCD6mvx3jKRD-tfbk4jvyy2LKz16tDtBSI=.effdfcc5-2739-4eaa-b5d8-986959c74e7f@github.com>

On Wed, 29 Nov 2023 19:12:20 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger`  to use same debug printing format for X.509 serial numbers. The changes are:
>> -  `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A`
>> - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A`
>> - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A`
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed serial number formatting method

src/java.base/share/classes/sun/security/x509/SerialNumber.java line 104:

> 102:      * Return the SerialNumber as user readable string.
> 103:      */
> 104:     public String toString() { return "Serial number: " +

Here I would keep "Serial number" as "SerialNumber" to maintain consistency with other X.509 `toString` methods which generally emit the name of the field using camel case format.

My only other comment is to whether it makes sense to move this into a utility method. I see `sun.security.util.Debug.toString` already does the same thing and uses `HexFormat` but in lower case. I think using lower case or upper case is not a big deal. So maybe just change all of these code instances to call `Debug.toString` to keep things consistent and reuse existing code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16834#discussion_r1409849893


From duke at openjdk.org  Wed Nov 29 21:13:30 2023
From: duke at openjdk.org (Ben Perez)
Date: Wed, 29 Nov 2023 21:13:30 GMT
Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial
 numbers [v4]
In-Reply-To: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
References: <mhVJNGI8x-7e2kGDJMwFsIs625bRkLKlgjdJNiS2O0M=.e34c6afc-0744-462a-80b6-f5ba535fcf1b@github.com>
Message-ID: <7dmiw9RTDc5m-PZwAUzphmEPyPHKKy71myIMFJACdF0=.2ff87b27-a583-414f-910d-863a26187926@github.com>

> Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger`  to use same debug printing format for X.509 serial numbers. The changes are:
> -  `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A`
> - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A`
> - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A`

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

  Replaced formatting function with Debug.toString. Changed toString method in SerialNumber to use camel case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16834/files
  - new: https://git.openjdk.org/jdk/pull/16834/files/1783ea3a..a5a733bb

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

  Stats: 9 lines in 3 files changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834

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


From jwaters at openjdk.org  Thu Nov 30 05:57:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 30 Nov 2023 05:57:04 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v3]
In-Reply-To: <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <SVa9PSE3J763B4H55RCwJ86BaqvPOtD8cyclLxuG7bs=.8df43ab7-d15a-4463-a414-6e0417321d19@github.com>
Message-ID: <vN6LUDzIVBgr9bZkZmiNj3zi2Vw34X6IKlVkLyK6Xkw=.86ce4d06-6b8c-4f7f-9641-aeb843bc4943@github.com>

On Thu, 16 Nov 2023 04:40:53 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NULL to nullptr in sspi.cpp

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1833151710


From mbalao at openjdk.org  Thu Nov 30 15:39:42 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 30 Nov 2023 15:39:42 GMT
Subject: RFR: 8315487: Security Providers Filter [v3]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <o0DO3tKKoax6WUpUB_9UXh4pFrYI7Z1LKu9BvvDPwuA=.0f4362bd-01f9-403e-80fa-5618e2008d79@github.com>

> 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...

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

  More clear text in invalid pattern exception.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/ef6eafcf..ea186c25

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

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

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


From duke at openjdk.org  Thu Nov 30 16:16:29 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 30 Nov 2023 16:16:29 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v6]
In-Reply-To: <LIl3wR28LxPV9BJz3uv1jnlvFBgzHb8RA-77PtPnXM4=.ba849064-fe7b-428c-a65e-9e0c6405d3b0@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <LIl3wR28LxPV9BJz3uv1jnlvFBgzHb8RA-77PtPnXM4=.ba849064-fe7b-428c-a65e-9e0c6405d3b0@github.com>
Message-ID: <7-UU5YZPUhwlA3HSxihL71QX_0DCcAHEt4uL5DF4EfI=.2de28091-7a48-47dc-b7f4-3461f6d577d7@github.com>

On Mon, 27 Nov 2023 20:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Code changes for HSS/LMS that's related to keytool and jarsigner:
>> 
>> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
>> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
>> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reword comment

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 526:

> 524:                 break;
> 525:             case "HSS/LMS":
> 526:                 // RFC 8708 requires the same hash algorithm used as in the HSS/LMS algorithm

Actually it is RFC 8554 that requires it, RFC 8708 just references RFC 8554

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1410904786


From weijun at openjdk.org  Thu Nov 30 16:25:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 30 Nov 2023 16:25:30 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v6]
In-Reply-To: <7-UU5YZPUhwlA3HSxihL71QX_0DCcAHEt4uL5DF4EfI=.2de28091-7a48-47dc-b7f4-3461f6d577d7@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <LIl3wR28LxPV9BJz3uv1jnlvFBgzHb8RA-77PtPnXM4=.ba849064-fe7b-428c-a65e-9e0c6405d3b0@github.com>
 <7-UU5YZPUhwlA3HSxihL71QX_0DCcAHEt4uL5DF4EfI=.2de28091-7a48-47dc-b7f4-3461f6d577d7@github.com>
Message-ID: <_Owp204plcZELFHU5YphlCjqJ9PP0nLRpaAq6sIsXdA=.b60e6bf7-1eb7-4589-ad08-fc530b96eca5@github.com>

On Thu, 30 Nov 2023 16:13:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reword comment
>
> src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 526:
> 
>> 524:                 break;
>> 525:             case "HSS/LMS":
>> 526:                 // RFC 8708 requires the same hash algorithm used as in the HSS/LMS algorithm
> 
> Actually it is RFC 8554 that requires it, RFC 8708 just references RFC 8554

I mean, RFC 8708 requires that the hash algorithm used by the HSS/LMS signature (which should be a single one used in every corner of HSS/LMS, as required by RFC 8554) should be the same as the `digestAlgorithm` in the CMS `SignerInfo` object. See RFC 8708 Section 5:
> digestAlgorithm MUST contain the one-way hash function used in the HSS/LMS tree. 

https://www.rfc-editor.org/rfc/rfc8708.html#name-signed-data-conventions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1410918418


From duke at openjdk.org  Thu Nov 30 16:32:21 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 30 Nov 2023 16:32:21 GMT
Subject: RFR: 8302233: HSS/LMS: keytool and jarsigner changes [v6]
In-Reply-To: <yZch_cWmuDn6JohQCz4NboFD_XzTXRO5thJmEB19R4U=.d427336e-49cb-40ca-bc4d-f2cf8b11a469@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
 <yZch_cWmuDn6JohQCz4NboFD_XzTXRO5thJmEB19R4U=.d427336e-49cb-40ca-bc4d-f2cf8b11a469@github.com>
Message-ID: <fV2aqc6tiLWYP7LQGcVcidrbPQUjImammJZn_h50ZLU=.287540bc-8ac7-4668-b356-4cfeba9b122c@github.com>

On Thu, 16 Nov 2023 15:17:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reword comment
>
> src/java.base/share/classes/sun/security/util/KeyUtil.java line 411:
> 
>> 409:      * @throws NoSuchAlgorithmException if key is from an unknown configuration
>> 410:      */
>> 411:     public static String hashAlgFromHSS(PublicKey publicKey)
> 
> @ferakocz can you review this method? Thanks.

Looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14254#discussion_r1410930739


From weijun at openjdk.org  Thu Nov 30 19:17:20 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 30 Nov 2023 19:17:20 GMT
Subject: Integrated: 8302233: HSS/LMS: keytool and jarsigner changes
In-Reply-To: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
References: <tN7Hq4zOcdXBaN6iWjZhcdgHeKMtReV4iPXQ60dnRLQ=.f65a8c52-3929-4210-8353-072df89f0e15@github.com>
Message-ID: <EmwFyTNaUGoCCy00zO35pxmKtjq3GXE8b8yWdbH_Khk=.a142fbae-3887-4060-8582-836358782fe7@github.com>

On Wed, 31 May 2023 22:38:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Code changes for HSS/LMS that's related to keytool and jarsigner:
> 
> 1. No need to add `-sigalg` for both tools when HSS/LMS key is involved, it can only be `HSS/LMS`.
> 2. The `digestAlgorithm` field in a PKCS7 `SignerInfo`. It must be the same as the hash algorithm used by the HSS/LMS key. This needs to be enforced both at signing and verification.
> 3. HSS/LMS reuses `.DSA` as the signature block file extension inside a signed JAR file

This pull request has now been integrated.

Changeset: 0a60b0f9
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7
Stats:     205 lines in 10 files changed: 87 ins; 85 del; 33 mod

8302233: HSS/LMS: keytool and jarsigner changes

Reviewed-by: mullan

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

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


From karl.scheibelhofer.75 at gmail.com  Wed Nov 29 15:23:00 2023
From: karl.scheibelhofer.75 at gmail.com (Karl Scheibelhofer)
Date: Wed, 29 Nov 2023 15:23:00 +0000
Subject: AW: [External] : Re: PEM KeyStore Implementation
In-Reply-To: <dd3d0cbd-c8a4-49e3-bfa9-bf93b997d2d5@oracle.com>
References: <CACSnhuU8Ew=8QYVvoHV_mR_S6PGDvo0M0SP9GXimUH+RVVFi+w@mail.gmail.com>
 <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com>
 <CACSnhuVRru41qq+xEbvXUwM1GQGWdQqizRQ3Q-KoD+qg+wJ=fw@mail.gmail.com>
 <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com>
 <CACSnhuUmf6V=1d-yE+E8L1FfqsRpzisyv80zQb10eqzhArkS_g@mail.gmail.com>
 <CACSnhuW-nO0mx6XcF75u00cQn6CwXySjw2L=XyouqqYjRPc2gQ@mail.gmail.com>
 <E7E25021-E8C7-43A3-8DED-969CFDEC436D@oracle.com>
 <CACSnhuVcsp6cessKJj73ZQnS3EXfwmcXDR6dbCZ4n1HdTzT6DQ@mail.gmail.com>
 <A6282C7A-270C-48B5-BA36-87A54D6FF2A0@oracle.com>
 <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com>
 <CACSnhuVo1=YFdKxomMQ5y-ECYHx2Wus_wXYthtJoa2XxR2vtYw@mail.gmail.com>
 <dd3d0cbd-c8a4-49e3-bfa9-bf93b997d2d5@oracle.com>
Message-ID: <DBBP194MB1068A236519B398E1168B090F383A@DBBP194MB1068.EURP194.PROD.OUTLOOK.COM>

Hi Tony!

I read the darft https://openjdk.org/jeps/8300911. It looks quite good to me.

To get a beffer feeling, I would like to use it. Is there a draft implememtation of this API?

I could give it a go with the draft version of PEM Keystore I did in KarlScheibelhofer/jdk at pem-keystore (github.com)<https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore>

regards, Karl
[https://opengraph.githubassets.com/1a7910123c5ab21478b7cd61d4db11394b996a812170b3720b77a293dbe159d7/KarlScheibelhofer/jdk]<https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore>
GitHub - KarlScheibelhofer/jdk at pem-keystore<https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore>
JDK main-line development https://openjdk.org/projects/jdk - GitHub - KarlScheibelhofer/jdk at pem-keystore
github.com

________________________________
Von: Anthony Scarpino <anthony.scarpino at oracle.com>
Gesendet: Freitag, 17. November 2023 20:52
An: Karl Scheibelhofer <karl.scheibelhofer at gmx.net>
Cc: security-dev at openjdk.org <security-dev at openjdk.org>
Betreff: Re: [External] : Re: PEM KeyStore Implementation

As you may have seen, the PEM API draft is out:
https://openjdk.org/jeps/8300911

Tony



On 10/18/23 3:00 AM, Karl Scheibelhofer wrote:
> Hi Sean,
>
> Yes, I can help with this new PEM API.
>
> Let me know, when there is something to review.
>
> Best regards,
>
> Karl
>
>
> On Tue, Oct 17, 2023, 19:12 Sean Mullan <sean.mullan at oracle.com
> <mailto:sean.mullan at oracle.com>> wrote:
>
>     Hi Karl,
>
>     I discussed your proposal with some other colleagues.
>
>     We generally feel a PEM KeyStore would be a useful addition to the
>     JDK. This would alleviate usability issues that many users encounter
>     when configuring and deploying applications that store keys or
>     certificates in PEM files.
>
>     However, we would like to first make sure that your PEM KeyStore
>     implementation will work well with the PEM API that we will be
>     proposing soon. We think this is a perfect opportunity to ensure
>     they work well together and would appreciate your help in reviewing
>     and validating the API - would you be interested in helping out?
>
>     Once that is done, we can discuss next steps.
>
>     Thanks,
>     Sean
>
>
>>     On Oct 5, 2023, at 9:41 AM, Sean Mullan <sean.mullan at oracle.com
>>     <mailto:sean.mullan at oracle.com>> wrote:
>>
>>
>>
>>>     On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer
>>>     <karl.scheibelhofer at gmx.net <mailto:karl.scheibelhofer at gmx.net>>
>>>     wrote:
>>>
>>>     Hi Sean,
>>>
>>>     Yes, I had a look at the Contributing docs at the OpenJDK site
>>>     before. I also signed the OCA.
>>
>>     Great, thanks.
>>
>>>
>>>     Honestly, I thought there would be some more reaction on the
>>>     suggested PEM KeyStore. It would really be good to discuss the
>>>     topic with others. Is there anything we can do to get others in
>>>     sharing their thoughts on this?
>>
>>     I think there is a fair amount of interest in it, but reviewing
>>     something significant like this takes a bit of time, as I
>>     mentioned in my prior email. Also, if we do decide to accept the
>>     contribution, we want to make sure it works well with the PEM API
>>     that we are working on - we hope to have a draft of a JEP for that
>>     out in the next few weeks. So I think we probably need a few weeks
>>     to review your contribution.
>>
>>>
>>>     There is already a fair amount of documentation und unit tests.
>>>     See https://github.com/KarlScheibelhofer/java-crypto-tools/
>>>     <https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools/__;!!ACWV5N9M2RV99hQ!L4Oy66pyQcMu7F5jKCD98FvyWZGBlrWmmpnxhOkj2bAffn_KyL69pJh6Y36l9xIk-U4itzwJyPjubZxjk-SP2qN2C39SWwY$> .
>>
>>     Ok.
>>
>>     ?Sean
>>
>>>
>>>     Best regards,
>>>     Karl
>>>
>>>     On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mullan at oracle.com
>>>     <mailto:sean.mullan at oracle.com>> wrote:
>>>
>>>         Hi Karl,
>>>
>>>         The OpenJDK Developer?s Guide includes a helpful section on
>>>         Contributing to an OpenJDK Project [1]. I suggest you read
>>>         through that if you have not already. In particular, have you
>>>         signed the OCA? I don?t want to review your code/contribution
>>>         until that is done.
>>>
>>>         For this particular contribution, I don?t think there has
>>>         been enough discussion and evaluation from members of the
>>>         Security project. This would be a fairly major contribution.
>>>         Keep in mind that a contribution doesn?t mean the work ends
>>>         there.  There would need to be documentation, tests, and
>>>         ongoing support for the foreseeable future. We need to think
>>>         about these aspects every time we add a new feature, so there
>>>         needs to be a strong motivation for doing it.
>>>
>>>         Thanks,
>>>         Sean
>>>
>>>         [1]
>>>         https://openjdk.org/guide/#contributing-to-an-openjdk-project
>>>         <https://openjdk.org/guide/#contributing-to-an-openjdk-project>
>>>
>>>         > On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer
>>>         <karl.scheibelhofer at gmx.net
>>>         <mailto:karl.scheibelhofer at gmx.net>> wrote:
>>>         >
>>>         > Hi All,
>>>         >
>>>         > I would like to contribute my PEM KeyStore implementation
>>>         to the
>>>         > OpenJDK, including integration in the OpenJDK source and
>>>         creating a
>>>         > pull request.
>>>         > What is the recommended way to do this?
>>>         > Who can create a suitable ticket in OpenJDK to document the
>>>         > enhancement and to track the progress?
>>>         >
>>>         > What are the requirements for a pull request to get merged?
>>>         >
>>>         > Best regards
>>>         >
>>>         > Karl
>>>         >
>>>         > Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer
>>>         > <karl.scheibelhofer at gmx.net
>>>         <mailto:karl.scheibelhofer at gmx.net>>:
>>>         >>
>>>         >> Hi  Tony!
>>>         >>
>>>         >> When the PEM API implementation becomes available it would
>>>         make sense
>>>         >> to use it inside the PEM Keystore implementation. It will
>>>         reduce the
>>>         >> code (the internal classes PemReader und PemWriter may become
>>>         >> obsolete), but it does not affect the functionality of the PEM
>>>         >> keystore. Users of the PEM Keystore won't experience a
>>>         difference.
>>>         >>
>>>         >> Let me know when there is something for the PEM API and I
>>>         will see if
>>>         >> I can assist.
>>>         >>
>>>         >> I would suggest starting with PEM Keystore now and not
>>>         wait for the
>>>         >> PEM API, because the time schedule for it seems vague. I
>>>         would try to
>>>         >> refactor my current PEM Keystore implementation to
>>>         integrate in the
>>>         >> OpenJDK sun.security.provider package. I do not expect any
>>>         API changes
>>>         >> or other compatibility issues with existing code. Then
>>>         consult this
>>>         >> group for feedback before creating a pull request.
>>>         >>
>>>         >> When the PEM API becomes available, rework the PEM Keystore
>>>         >> implementation to use it internally.
>>>         >>
>>>         >> What do you think?
>>>         >>
>>>         >> Best regards
>>>         >>
>>>         >>  Karl Scheibelhofer
>>>         >>
>>>         >> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino
>>>         >> <anthony.scarpino at oracle.com
>>>         <mailto:anthony.scarpino at oracle.com>>:
>>>         >>>
>>>         >>> There are no doc links yet.
>>>         >>>
>>>         >>> Tony
>>>         >>>
>>>         >>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote:
>>>         >>>> Hi Tony,
>>>         >>>>
>>>         >>>> The motivation was mostly about reading PEM keys and
>>>         certificates
>>>         >>>> generated somewhere else. This is common practice in
>>>         enterprise
>>>         >>>> environments I work in. Because corporate key material
>>>         is subject to
>>>         >>>> centralized key management, including generation, backup
>>>         and rollover.
>>>         >>>> PEM is the format most software products can handle. For
>>>         Java
>>>         >>>> applications, having a PEM KeyStore would reduce the
>>>         often required
>>>         >>>> additional step of converting PEM key and certificate in
>>>         a Java
>>>         >>>> Keystore/PKCS#12.
>>>         >>>> Even truststores handling is easier with individual PEM
>>>         certificates
>>>         >>>> instead of a single PKCS#12 Truststore. Adding or
>>>         deleting a single
>>>         >>>> file instead of replacing the complete PKCS#12 store is
>>>         less error
>>>         >>>> prone and cleaner to track in version control. The
>>>         additional benefit
>>>         >>>> of a MAC in PKCS#12 adds little to no security in most
>>>         cases.
>>>         >>>> And being text based, PEM is more version control
>>>         friendly than binary PKCS#12.
>>>         >>>>
>>>         >>>> But to enable sound support of PEM, I also implemented
>>>         writing PEM
>>>         >>>> keys and certificates. This way, one can use the JDK
>>>         keytool to
>>>         >>>> generate key and certificate signing requests in PEM
>>>         format. Getting
>>>         >>>> the certificate from the CA in PEM, one can use PEM
>>>         throughout the
>>>         >>>> process.
>>>         >>>>
>>>         >>>> Do you have any links or documentation on the PEM API
>>>         JEP that you mentioned?
>>>         >>>>
>>>         >>>> Thank you for your feedback and best regards
>>>         >>>>
>>>         >>>>   Karl
>>>         >>>>
>>>         >>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino
>>>         >>>> <anthony.scarpino at oracle.com
>>>         <mailto:anthony.scarpino at oracle.com>>:
>>>         >>>>>
>>>         >>>>> Hi Karl
>>>         >>>>>
>>>         >>>>> The keystore is interesting and may have some value.
>>>         Was your use case
>>>         >>>>> mostly reading PEM keys and certificates generated
>>>         elsewhere for use
>>>         >>>>> with a particular application, maybe webservers?  Did
>>>         you see value in
>>>         >>>>> writing to this keystore from Java?
>>>         >>>>>
>>>         >>>>> On the topic of PEM, I hope before the end of the year
>>>         to have a PEM API
>>>         >>>>> JEP.  I would be interested in your API feedback from
>>>         your keystore
>>>         >>>>> experiences.  I think if this keystore contribution was
>>>         accepted, it
>>>         >>>>> should wait so it can use that API.
>>>         >>>>>
>>>         >>>>> thanks
>>>         >>>>>
>>>         >>>>> Tony
>>>         >>>>>
>>>         >>>>>
>>>         >>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote:
>>>         >>>>>> Hi,
>>>         >>>>>>
>>>         >>>>>> Working with Java and the JCA KeyStore for decades, I
>>>         came across
>>>         >>>>>> many situations where I thought it would be convenient
>>>         to be
>>>         >>>>>> able to load private keys and certificates in PEM
>>>         format directly
>>>         >>>>>> using the KeyStore API. Without the need to convert
>>>         them to PKCS#12/JKS.
>>>         >>>>>>
>>>         >>>>>> You can find my implementation of a PEM KeyStore in
>>>         >>>>>>
>>>         https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ <https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$> .
>>>         >>>>>>
>>>         >>>>>> I wondered if it would make sense to integrate such an
>>>         implementation
>>>         >>>>>> in one of the standard providers of OpenJDK - like the
>>>         SUN provider.
>>>         >>>>>> What do you think?
>>>         >>>>>>
>>>         >>>>>> Best regards
>>>         >>>>>>
>>>         >>>>>>    Karl
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231129/3663074b/attachment.htm>